[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Richard Frith-Macdonald
Subject: Re: MAC_OS_X_VERSION macros
Date: Sun, 30 Jun 2013 16:22:30 +0100

On 26 Jun 2013, at 10:33, Wolfgang Lux <address@hidden> wrote:

> Ivan Vučica wrote:
>> How about:
>> #ifdef __APPLE__
>> #include <WhateverHeaderDefinesMacOSXVersionMacros.h>
>> #else
>> // GNUstep's definitions
>> #endif
>> This would only be helpful if OS X's macro definitions exist in a standalone 
>> header, by themselves. However, it sounds better than undefining, avoiding 
>> inclusion, or renaming or removing the macros.
> That would indeed be better. However, to do that we first need to fix all 
> places where the numeric values of the version macros are used. This, of 
> course, should be done anyway, and my code is just meant as a workaround 
> (call it a hack) until this is done.

I'm not sure exactly what the consequences of all this are, as I don't build 
gnustep (apart from the testsuite) on OSX, and don't use Apple's version macros.
But the GNUstep ones are based around the major, minor, and subminor version 
number stuff, and if I understand correctly, OSX uses completely different 
numeric values ... so the above idea of including one or the other makes no 
sense unless we change everything in GNUstep versioning to copy OSX exactly (ie 
change the headers, and the documentation generation code, and makefiles  etc).

Now, there may be some sufficviently good reason to change everything, but if 
so, I don't think anyone's bothered explaining it.  So I think your first 
solution (checking for OSX macros and undefining/redefining them if necessary) 
is probably the best ... its a straightforward, localised change and as far as 
I cvan see the only downside would be that if you include, on OSX, a header 
which depends on the OSX macro versions, after including a GNUstep header, it 
could cause some confusion.  However, the simple fix to that would be to 
include such headers before including GNUstep headers.

In short, I like your fist solution.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]