Re: MAC_OS_X_VERSION macros

[Richard Frith-Macdonald]

On 1 Jul 2013, at 08:34, Wolfgang Lux <address@hidden> wrote:

> Richard Frith-Macdonald wrote:
> 
>> On 30 Jun 2013, at 16:22, Richard Frith-Macdonald <address@hidden> wrote:
>> 
>>> 
>>> 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.
>> 
>> But, after sleeping on it and thinking some more, I tried another approach 
>> ... simply to convert the 4 digit Apple version number to a 6 digit GNUstep 
>> version number by multiplying by 100.
>> This should mean we can adopt smething like ivan's idea above without 
>> breaking any existing stuff in GNUstep, because we can import the apple 
>> versions and just have a single macro convert them to the format we 
>> currently use.
>> Are there problems I haven't spotted with this?
> 
> Yes. The value of MAC_OS_X_VERSION_10_1 on Mac OS X is 1010. Multiplying that 
> by 100 gives 101000 and not 100100. As this value is even greater than 100700 
> (i.e,. MAC_OS_X_VERSION_10_7) your idea is likely to yield wrong results.
> On the other hand, something more complicated like (version)/10*100 + 
> (version)%10*10 would work.

Thanks ... I didn't know they did the version number like that (I try to avoid 
looking at Apple codedirectly, even public headers, in case of copyright 
issues) ... I changed to use your conversion expression.

> But then I don't see any difference to my hack of undefining all those 
> macros. But maybe it's just too early in the morning.

Ah, I guess the difference is non-obvious.

If we have a macro to alter the version at the point of use (rather than 
redefining the macro), we can use the Apple variants directly on an OSX system 
... which means if someone includes Apple headers later on in the code, those 
headers will see the Apple version numbers and won't be broken by strange 
GNUstep versions.  At the same time, and existing GNUstep code will continue to 
work without alteration on all other operating systems, because there we will 
still have the  support for the 6 digit version numbers working.

So, this is very similar to your original idea (which I liked), but with an 
improvement in OSX compatibility where people include system headers *after* 
the GNUstep headers.