[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: error: expected a platform name, e.g., 'macosx'
From:       Ryan Schmidt <ryandesign () macports ! org>
Date:       2012-09-22 10:17:34
Message-ID: C08D4AB5-9EB3-4613-BEA0-E280E94AD193 () macports ! org
[Download RAW message or body]


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.


_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev


[prev in list] [next in list] [prev in thread] [next in thread]