error: expected a platform name, e.g., 'macosx'

[Ryan Schmidt]

On Sep 22, 2012, at 05:04, Joshua Root wrote:

> On 2012-9-22 19:51 , Ryan Schmidt wrote:
>> The system headers use availability macros, and at least on Mountain Lion their definitions include the word "macosx", e.g. "availability(macosx,introduced=10.5)". The problem occurs when a software package defines its own preprocessor symbol called "macosx". This might take the form of a "#define macosx" inserted into a confdefs.h file by a configure script, or a hand-written Makefile specifying "-Dmacosx". The four projects we recently fixed used this symbol to include code meant only for use on OS X, and for that use case, custom defines aren't necessary because there's already a define available for that purpose on OS X: "__APPLE__". So the fix is to remove the custom "macosx" preprocessor symbol from the project, and to change any "macosx" checks in the source files to checks for "__APPLE__" instead.
> 
> It should technically be (__APPLE__ && __MACH__).

Yes I think you're right. But as far as I could tell, __APPLE__ and __MACH__ are both defined on both OS X and iOS, and the only case where __APPLE__ is defined and __MACH__ is not is on Classic Mac OS, and there isn't a lot of software that's in MacPorts that also compiles on Classic Mac OS, so in most cases the distinction doesn't matter.


> However, testing for
> these is officially frowned upon. Whenever possible, upstream should
> really test for specific ways in which platforms are known to differ
> (presence of particular headers or libs, behaviour of particular
> functions, etc.), not test for specific platforms.

Absolutely, but it's outside the scope of MacPorts maintainers' responsibilities to rearchitect upstream code in such a way. If upstream code is already written with preprocessor defines to detect OS X, then it's our simplest course of action to replace the problematic "macosx" symbol with an already-existing Apple-provided symbol that does the same thing.

We could also advise upstream to rewrite their code to no longer test for platforms, but that's more difficult for them to do and we shouldn't let such a request derail the simpler fix.