Re: MAC_OS_X_VERSION macros
On 1 Jul 2013, at 09:16, Richard Frith-Macdonald
wrote:
> 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.
Note that Apple doesn't actually use these macros for much anymore. They have
a clang flag that specifies the target OS X / iOS version and this is used in
all of the header checks. This allows a single precompiled header to work for
all deployment targets (which is nice) and also allows the compiler to provide
more helpful error messages.
I'd like to generalise this to be a -fframework-version={framework
name}-{version} so that you can use something like
__attribute__((framework_available(gnustep,1.7, 1.9)) to specify something that
is only available when compiled for GNUstep 1.7 to 1.9 (for example).
David
-- Sent from my PDP-11
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
On 1 Jul 2013, at 08:34, Wolfgang Lux wrote: > Richard Frith-Macdonald wrote: > >> On 30 Jun 2013, at 16:22, Richard Frith-Macdonald >> wrote: >> >>> >>> On 26 Jun 2013, at 10:33, Wolfgang Lux wrote: >>> Ivan Vučica wrote: > How about: > > #ifdef __APPLE__ > #include > #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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
Richard Frith-Macdonald wrote: > On 30 Jun 2013, at 16:22, Richard Frith-Macdonald > wrote: > >> >> On 26 Jun 2013, at 10:33, Wolfgang Lux wrote: >> >>> Ivan Vučica wrote: >>> How about: #ifdef __APPLE__ #include #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. 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. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
On 30 Jun 2013, at 16:22, Richard Frith-Macdonald wrote: > > On 26 Jun 2013, at 10:33, Wolfgang Lux wrote: > >> Ivan Vučica wrote: >> >>> How about: >>> >>> #ifdef __APPLE__ >>> #include >>> #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? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
On 26 Jun 2013, at 10:33, Wolfgang Lux wrote: > Ivan Vučica wrote: > >> How about: >> >> #ifdef __APPLE__ >> #include >> #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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
It is my impression GNUstep doesn't even build on OS X10.8, so for a few years it hasn't been used for building on OS X the same code that builds on other OSes nor for building code that was first built for Cocoa? I've only tried while having objc2 prebuilt on my mac so maybe I wasn't following an established build and install recipe. Anyway, having the GS code use the wrong length for the MAC OS version identifier seems wrong. And adding more header code to work around this will just make it harder to maintain and debug. I think the first step would be to fix the length to conform to the six digits that Apple uses. Then at least the code has a chance to work again on OS X. A second, later step, could be to evaluate the need for GS headers to define the MAC_OS_X symbols. It seems odd that it does now, but it sounds like a call that someone with experience with GS and who is still actively maintaining GS for MAC should make. On Wed, Jun 26, 2013 at 5:33 AM, Wolfgang Lux wrote: > Ivan Vučica wrote: > > > How about: > > > > #ifdef __APPLE__ > > #include > > #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. > > Wolfgang > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
Ivan Vučica wrote: > How about: > > #ifdef __APPLE__ > #include > #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. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
How about:
#ifdef __APPLE__
#include
#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.
Regards,
Ivan Vučica
via phone
On 26. 6. 2013., at 10:40, Wolfgang Lux wrote:
> Hi Eric,
>
>> Hi Frank,
>> Thanks for bringing this up - it's indeed a nasty problem (although
>> hopefully pretty easy to fix :)
>>
>> A year or two ago I was working on updating macports patches for building
>> GNUstep on OS X 10.6/10.7, and ran in to an instance of this here:
>> https://github.com/ericwa/gnustep-macports-fixes/blob/master/gnustep/gnustep-back/files/patch-CairoFaceInfo.h
>> I forget the details but I think I was working around GNUstep pulling in OS
>> X's MAC_OS_X_VERSION_MAX_ALLOWED.
>>
>>
>> My take on it is, we (GNUstep) should avoid using symbols that Apple is
>> shipping in their availability macros, since the availability macros on OS X
>> are included in standard C headers (e.g. /usr/include/stdlib.h).
>>
>>
>> I'd propose modifying this section of
>> base/Headers/GNUstepBase/GSVersionMacros.h:
>>
>> /*
>> * For MacOS-X compatibility, we define the MacOS-X version constants and
>> * we allow MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED
>> * instead of GS_OPENSTEP_V
>> */
>>
>> #ifndef MAC_OS_X_VERSION_10_0
>> #define MAC_OS_X_VERSION_10_0 10
>> #define MAC_OS_X_VERSION_10_1 100100
>> #define MAC_OS_X_VERSION_10_2 100200
>> #define MAC_OS_X_VERSION_10_3 100300
>> #define MAC_OS_X_VERSION_10_4 100400
>> #define MAC_OS_X_VERSION_10_5 100500
>> #define MAC_OS_X_VERSION_10_6 100600
>> #endif /* MAC_OS_X_VERSION_10_0 */
>>
>> #ifndef GS_OPENSTEP_V
>> #ifdef MAC_OS_X_VERSION_MIN_ALLOWED
>> #define GS_OPENSTEP_V MAC_OS_X_VERSION_MIN_ALLOWED
>> #else
>> #ifdef MAC_OS_X_VERSION_MAX_ALLOWED
>> #define GS_OPENSTEP_V MAC_OS_X_VERSION_MAX_ALLOWED
>> #endif /* MAC_OS_X_VERSION_MAX_ALLOWED */
>> #endif /* MAC_OS_X_VERSION_MIN_ALLOWED */
>> #endif /* GS_OPENSTEP_V */
>>
>> We could rename the MAC_OS_X_VERSION_* to GS_OS_X_VERSION_*, and eliminate
>> the section below that makes MAC_OS_X_VERSION_MIN_ALLOWED or
>> MAC_OS_X_VERSION_MAX_ALLOWED an alias for GS_OPENSTEP_V.
>>
>> Maybe someone who has more background on the history of these macros in GS
>> can chime in?
>
> I'm not fully familiar with the history of these macros, but part of the
> reason for them being there is that some people (including myself) write code
> that depends on the OS X version and they use the MAC_OS_X_VERSION macros to
> conditionally compile parts of the program depending on the target. Renaming
> those macros to GS_OS_X_VERSION will break all such version checks when
> porting such code to GNUstep.
>
> At present, I'm using the following workaround in GSVersionMacros.h (before
> the section you quoted) to compile GNUstep on OS X:
>
> #if defined(__APPLE__) && defined(GNUSTEP) && MAC_OS_X_VERSION_10_0 == 1000
> /* Workaround for the incompatible version numbering scheme used by Apple
> * FIXME undefining MAC_OS_X_VERSION_{MIN_REQUIRED,MAX_ALLOWED} probably
> * is not a good idea. However, keep these defined can cause compile errors
> * when we use tests like OS_API_VERSION(GS_API_NONE, GS_API_NONE).
> */
> #undefMAC_OS_X_VERSION_10_0
> #undefMAC_OS_X_VERSION_10_1
> #undefMAC_OS_X_VERSION_10_2
> #undefMAC_OS_X_VERSION_10_3
> #undefMAC_OS_X_VERSION_10_4
> #undefMAC_OS_X_VERSION_10_5
> #undefMAC_OS_X_VERSION_10_6
> #undefMAC_OS_X_VERSION_10_7
> #undef MAC_OS_X_VERSION_MIN_REQUIRED
> #undef MAC_OS_X_VERSION_MAX_ALLOWED
> #endif
>
> I did not commit this change because I never got around to testing whether
> this works correctly when compiling the base additions on OS X (i.e., with
> the apple-apple-apple combo) and because I wasn't aware that there would be
> sufficient interest for this outside my home :-)
>
> Wolfgang
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
Hi Eric,
> Hi Frank,
> Thanks for bringing this up - it's indeed a nasty problem (although hopefully
> pretty easy to fix :)
>
> A year or two ago I was working on updating macports patches for building
> GNUstep on OS X 10.6/10.7, and ran in to an instance of this here:
> https://github.com/ericwa/gnustep-macports-fixes/blob/master/gnustep/gnustep-back/files/patch-CairoFaceInfo.h
> I forget the details but I think I was working around GNUstep pulling in OS
> X's MAC_OS_X_VERSION_MAX_ALLOWED.
>
>
> My take on it is, we (GNUstep) should avoid using symbols that Apple is
> shipping in their availability macros, since the availability macros on OS X
> are included in standard C headers (e.g. /usr/include/stdlib.h).
>
>
> I'd propose modifying this section of
> base/Headers/GNUstepBase/GSVersionMacros.h:
>
> /*
> * For MacOS-X compatibility, we define the MacOS-X version constants and
> * we allow MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED
> * instead of GS_OPENSTEP_V
> */
>
> #ifndef MAC_OS_X_VERSION_10_0
> #define MAC_OS_X_VERSION_10_0 10
> #define MAC_OS_X_VERSION_10_1 100100
> #define MAC_OS_X_VERSION_10_2 100200
> #define MAC_OS_X_VERSION_10_3 100300
> #define MAC_OS_X_VERSION_10_4 100400
> #define MAC_OS_X_VERSION_10_5 100500
> #define MAC_OS_X_VERSION_10_6 100600
> #endif /* MAC_OS_X_VERSION_10_0 */
>
> #ifndef GS_OPENSTEP_V
> #ifdef MAC_OS_X_VERSION_MIN_ALLOWED
> #define GS_OPENSTEP_V MAC_OS_X_VERSION_MIN_ALLOWED
> #else
> #ifdef MAC_OS_X_VERSION_MAX_ALLOWED
> #define GS_OPENSTEP_V MAC_OS_X_VERSION_MAX_ALLOWED
> #endif /* MAC_OS_X_VERSION_MAX_ALLOWED */
> #endif /* MAC_OS_X_VERSION_MIN_ALLOWED */
> #endif /* GS_OPENSTEP_V */
>
> We could rename the MAC_OS_X_VERSION_* to GS_OS_X_VERSION_*, and eliminate
> the section below that makes MAC_OS_X_VERSION_MIN_ALLOWED or
> MAC_OS_X_VERSION_MAX_ALLOWED an alias for GS_OPENSTEP_V.
>
> Maybe someone who has more background on the history of these macros in GS
> can chime in?
I'm not fully familiar with the history of these macros, but part of the reason
for them being there is that some people (including myself) write code that
depends on the OS X version and they use the MAC_OS_X_VERSION macros to
conditionally compile parts of the program depending on the target. Renaming
those macros to GS_OS_X_VERSION will break all such version checks when porting
such code to GNUstep.
At present, I'm using the following workaround in GSVersionMacros.h (before the
section you quoted) to compile GNUstep on OS X:
#if defined(__APPLE__) && defined(GNUSTEP) && MAC_OS_X_VERSION_10_0 == 1000
/* Workaround for the incompatible version numbering scheme used by Apple
* FIXME undefining MAC_OS_X_VERSION_{MIN_REQUIRED,MAX_ALLOWED} probably
* is not a good idea. However, keep these defined can cause compile errors
* when we use tests like OS_API_VERSION(GS_API_NONE, GS_API_NONE).
*/
#undef MAC_OS_X_VERSION_10_0
#undef MAC_OS_X_VERSION_10_1
#undef MAC_OS_X_VERSION_10_2
#undef MAC_OS_X_VERSION_10_3
#undef MAC_OS_X_VERSION_10_4
#undef MAC_OS_X_VERSION_10_5
#undef MAC_OS_X_VERSION_10_6
#undef MAC_OS_X_VERSION_10_7
#undef MAC_OS_X_VERSION_MIN_REQUIRED
#undef MAC_OS_X_VERSION_MAX_ALLOWED
#endif
I did not commit this change because I never got around to testing whether this
works correctly when compiling the base additions on OS X (i.e., with the
apple-apple-apple combo) and because I wasn't aware that there would be
sufficient interest for this outside my home :-)
Wolfgang
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: MAC_OS_X_VERSION macros
Hi Frank, Thanks for bringing this up - it's indeed a nasty problem (although hopefully pretty easy to fix :) A year or two ago I was working on updating macports patches for building GNUstep on OS X 10.6/10.7, and ran in to an instance of this here: https://github.com/ericwa/gnustep-macports-fixes/blob/master/gnustep/gnustep-back/files/patch-CairoFaceInfo.h I forget the details but I think I was working around GNUstep pulling in OS X's MAC_OS_X_VERSION_MAX_ALLOWED. My take on it is, we (GNUstep) should avoid using symbols that Apple is shipping in their availability macros, since the availability macros on OS X are included in standard C headers (e.g. /usr/include/stdlib.h). I'd propose modifying this section of base/Headers/GNUstepBase/GSVersionMacros.h: /* * For MacOS-X compatibility, we define the MacOS-X version constants and * we allow MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED * instead of GS_OPENSTEP_V */ #ifndef MAC_OS_X_VERSION_10_0 #define MAC_OS_X_VERSION_10_0 10 #define MAC_OS_X_VERSION_10_1 100100 #define MAC_OS_X_VERSION_10_2 100200 #define MAC_OS_X_VERSION_10_3 100300 #define MAC_OS_X_VERSION_10_4 100400 #define MAC_OS_X_VERSION_10_5 100500 #define MAC_OS_X_VERSION_10_6 100600 #endif /* MAC_OS_X_VERSION_10_0 */ #ifndef GS_OPENSTEP_V #ifdef MAC_OS_X_VERSION_MIN_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MIN_ALLOWED #else #ifdef MAC_OS_X_VERSION_MAX_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MAX_ALLOWED #endif /* MAC_OS_X_VERSION_MAX_ALLOWED */ #endif /* MAC_OS_X_VERSION_MIN_ALLOWED */ #endif /* GS_OPENSTEP_V */ We could rename the MAC_OS_X_VERSION_* to GS_OS_X_VERSION_*, and eliminate the section below that makes MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED an alias for GS_OPENSTEP_V. Maybe someone who has more background on the history of these macros in GS can chime in? Eric On 2013-06-03, at 6:06 PM, Frank Rehwinkel wrote: > I think the build is currently broken on OS X 10.8 and I think there are > typos so I was just asking for experienced advice what path to take to fix > it. I guess it's also possible it is not broken for other people on their > 10.8 systems but if that's the case, I'd like to hear about it. > > Thanks, > -Frank > > > On Mon, Jun 3, 2013 at 6:00 PM, Maxthon Chan wrote: > Don't panic, as Apple will switch back in no more than 2 years - when they > reached OS X 10.10 (OS X 10.9 is pretty much confirmed in this year's WWDC - > I am a paid iOS developer so I have access to these "Apple Prerelease" > information. Or maybe at that time there will be no more OS X, and the new OS > is called iOS 11 all across desktop and mobile devices). > > 在 2013-6-4，上午5:55，Frank Rehwinkel 写道： > >> I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are >> similar but not identical to Apple's and by what appear >> to be typos in some of their use. >> >> The system headers in my OS X 10.8 system define four digit version numbers >> but >> GNUstep is built on six digit version numbers. Also Apple's documentation >> gives an example of using a four digit number, 1050, to represent the 10.5 >> version of OS X. >> >> http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 >> >> Was Apple's version number once six digits or was it always four and GNUstep >> needed/wanted to use six? At the moment, the test for OS X version is broken >> because the four digit value is being picked up from the system header (1080) >> and it works out to be less than an old version number because fewer digits >> are >> being used (100500 in the first case I tracked down). >> >> The simplest fix would seem to be to stick with six digits for GNUstep-base >> but fix >> the one header that was responsible for pulling in a value of 1080 as the >> current >> max value. We could hardcode a current max value of 100800. >> >> Also it appears there are some symbols being tested against that aren't even >> declared in the headers. They appear to be typos because they are so similar >> to valid symbols. >> >> And it appears GNUstep-base hasn't been updated for OS X since 10.6 or 10.7. >> The >> file GNUstepBase/GSVersionMacros.h defines these constants, among others. >> There are no constants that would map to 10.7 or 10.8, but NSCalender.h does >> use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the moment. >> >> GNUstepBase/GSVersionMacros.h: >> #ifndef MAC_OS_X_VERSION_10_0 >> #define MAC_OS_X_VERS
Re: MAC_OS_X_VERSION macros
I think the build is currently broken on OS X 10.8 and I think there are typos so I was just asking for experienced advice what path to take to fix it. I guess it's also possible it is not broken for other people on their 10.8 systems but if that's the case, I'd like to hear about it. Thanks, -Frank On Mon, Jun 3, 2013 at 6:00 PM, Maxthon Chan wrote: > Don't panic, as Apple will switch back in no more than 2 years - when they > reached OS X 10.10 (OS X 10.9 is pretty much confirmed in this year's WWDC > - I am a paid iOS developer so I have access to these "Apple Prerelease" > information. Or maybe at that time there will be no more OS X, and the new > OS is called iOS 11 all across desktop and mobile devices). > > 在 2013-6-4，上午5:55，Frank Rehwinkel 写道： > > I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are > similar but not identical to Apple's and by what appear > to be typos in some of their use. > > The system headers in my OS X 10.8 system define four digit version > numbers but > GNUstep is built on six digit version numbers. Also Apple's documentation > gives an example of using a four digit number, 1050, to represent the 10.5 > version of OS X. > > > http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 > > Was Apple's version number once six digits or was it always four and > GNUstep > needed/wanted to use six? At the moment, the test for OS X version is > broken > because the four digit value is being picked up from the system header > (1080) > and it works out to be less than an old version number because fewer > digits are > being used (100500 in the first case I tracked down). > > The simplest fix would seem to be to stick with six digits for > GNUstep-base but fix > the one header that was responsible for pulling in a value of 1080 as the > current > max value. We could hardcode a current max value of 100800. > > Also it appears there are some symbols being tested against that aren't > even > declared in the headers. They appear to be typos because they are so > similar > to valid symbols. > > And it appears GNUstep-base hasn't been updated for OS X since 10.6 or > 10.7. The > file GNUstepBase/GSVersionMacros.h defines these constants, among others. > There are no constants that would map to 10.7 or 10.8, but NSCalender.h > does > use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the > moment. > > GNUstepBase/GSVersionMacros.h: > #ifndef MAC_OS_X_VERSION_10_0 > #define MAC_OS_X_VERSION_10_0 10 > #define MAC_OS_X_VERSION_10_1 100100 > #define MAC_OS_X_VERSION_10_2 100200 > #define MAC_OS_X_VERSION_10_3 100300 > #define MAC_OS_X_VERSION_10_4 100400 > #define MAC_OS_X_VERSION_10_5 100500 > #define MAC_OS_X_VERSION_10_6 100600 > #endif /* MAC_OS_X_VERSION_10_0 */ > > Note: these symbols are defined in /usr/include/AvailabilityMacros.h. I > can't > imagine Apple switched from a six digit scheme to a four digit scheme > without > changing the symbol names because their own documentation advises using > hardcoded numbers instead of symbol names. But I also can't imagine > GNUstep > would have used the same symbol names in a different manor. It would have > been > just as easy to use a different symbol name pattern to represent GNUstep's > version of the OS version. I can't find a reference to such a change > happening > so maybe GNUstep code was always doing its own thing. > > /usr/include/AvailabilityMacros.h: > /* > * Set up standard Mac OS X versions > */ > #define MAC_OS_X_VERSION_10_0 1000 > #define MAC_OS_X_VERSION_10_1 1010 > #define MAC_OS_X_VERSION_10_2 1020 > #define MAC_OS_X_VERSION_10_3 1030 > #define MAC_OS_X_VERSION_10_4 1040 > #define MAC_OS_X_VERSION_10_5 1050 > #define MAC_OS_X_VERSION_10_6 1060 > #define MAC_OS_X_VERSION_10_7 1070 > #define MAC_OS_X_VERSION_10_8 1080 > > The place where this bites us now when building for OS X is that Apple's > symbol, MAC_OS_X_VERSION_MAX_ALLOWED, gets pulled in from a system header, > AvailabilityInternal.h and is used to test against the six digit values. > > /usr/include/AvailabilityInternal.h:#define > __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_8 > > But Apple defines __MAC_10_8 like this: > > /usr/include/Availability.h:#define __MAC_10_8 1080 > > And defining it as 1080 instead of 100800 breaks the assumptions in the > GNUstep-base code. Examples: > > NSPointerFunctions.h:
Re: MAC_OS_X_VERSION macros
Don't panic, as Apple will switch back in no more than 2 years - when they reached OS X 10.10 (OS X 10.9 is pretty much confirmed in this year's WWDC - I am a paid iOS developer so I have access to these "Apple Prerelease" information. Or maybe at that time there will be no more OS X, and the new OS is called iOS 11 all across desktop and mobile devices). 在 2013-6-4，上午5:55，Frank Rehwinkel 写道： > I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are > similar but not identical to Apple's and by what appear > to be typos in some of their use. > > The system headers in my OS X 10.8 system define four digit version numbers > but > GNUstep is built on six digit version numbers. Also Apple's documentation > gives an example of using a four digit number, 1050, to represent the 10.5 > version of OS X. > > http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 > > Was Apple's version number once six digits or was it always four and GNUstep > needed/wanted to use six? At the moment, the test for OS X version is broken > because the four digit value is being picked up from the system header (1080) > and it works out to be less than an old version number because fewer digits > are > being used (100500 in the first case I tracked down). > > The simplest fix would seem to be to stick with six digits for GNUstep-base > but fix > the one header that was responsible for pulling in a value of 1080 as the > current > max value. We could hardcode a current max value of 100800. > > Also it appears there are some symbols being tested against that aren't even > declared in the headers. They appear to be typos because they are so similar > to valid symbols. > > And it appears GNUstep-base hasn't been updated for OS X since 10.6 or 10.7. > The > file GNUstepBase/GSVersionMacros.h defines these constants, among others. > There are no constants that would map to 10.7 or 10.8, but NSCalender.h does > use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the moment. > > GNUstepBase/GSVersionMacros.h: > #ifndef MAC_OS_X_VERSION_10_0 > #define MAC_OS_X_VERSION_10_0 10 > #define MAC_OS_X_VERSION_10_1 100100 > #define MAC_OS_X_VERSION_10_2 100200 > #define MAC_OS_X_VERSION_10_3 100300 > #define MAC_OS_X_VERSION_10_4 100400 > #define MAC_OS_X_VERSION_10_5 100500 > #define MAC_OS_X_VERSION_10_6 100600 > #endif /* MAC_OS_X_VERSION_10_0 */ > > Note: these symbols are defined in /usr/include/AvailabilityMacros.h. I can't > imagine Apple switched from a six digit scheme to a four digit scheme without > changing the symbol names because their own documentation advises using > hardcoded numbers instead of symbol names. But I also can't imagine GNUstep > would have used the same symbol names in a different manor. It would have > been > just as easy to use a different symbol name pattern to represent GNUstep's > version of the OS version. I can't find a reference to such a change > happening > so maybe GNUstep code was always doing its own thing. > > /usr/include/AvailabilityMacros.h: > /* > * Set up standard Mac OS X versions > */ > #define MAC_OS_X_VERSION_10_0 1000 > #define MAC_OS_X_VERSION_10_1 1010 > #define MAC_OS_X_VERSION_10_2 1020 > #define MAC_OS_X_VERSION_10_3 1030 > #define MAC_OS_X_VERSION_10_4 1040 > #define MAC_OS_X_VERSION_10_5 1050 > #define MAC_OS_X_VERSION_10_6 1060 > #define MAC_OS_X_VERSION_10_7 1070 > #define MAC_OS_X_VERSION_10_8 1080 > > The place where this bites us now when building for OS X is that Apple's > symbol, MAC_OS_X_VERSION_MAX_ALLOWED, gets pulled in from a system header, > AvailabilityInternal.h and is used to test against the six digit values. > > /usr/include/AvailabilityInternal.h:#define > __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_8 > > But Apple defines __MAC_10_8 like this: > > /usr/include/Availability.h:#define __MAC_10_8 1080 > > And defining it as 1080 instead of 100800 breaks the assumptions in the > GNUstep-base code. Examples: > > NSPointerFunctions.h: #if OS_API_VERSION(100500, GS_API_LATEST) > > 100500 would be less than 100800 but it is not less than 1080, so code that > should be expanded by the preprocessor is not, and the build fails. > > All these OS X version checks in the code could be changed from the hardcoded > numbers like the example above in NSPointerFunctions.h to use symbol names if > we wanted to support some systems where the digits were f
MAC_OS_X_VERSION macros
I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are similar but not identical to Apple's and by what appear to be typos in some of their use. The system headers in my OS X 10.8 system define four digit version numbers but GNUstep is built on six digit version numbers. Also Apple's documentation gives an example of using a four digit number, 1050, to represent the 10.5 version of OS X. http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 Was Apple's version number once six digits or was it always four and GNUstep needed/wanted to use six? At the moment, the test for OS X version is broken because the four digit value is being picked up from the system header (1080) and it works out to be less than an old version number because fewer digits are being used (100500 in the first case I tracked down). The simplest fix would seem to be to stick with six digits for GNUstep-base but fix the one header that was responsible for pulling in a value of 1080 as the current max value. We could hardcode a current max value of 100800. Also it appears there are some symbols being tested against that aren't even declared in the headers. They appear to be typos because they are so similar to valid symbols. And it appears GNUstep-base hasn't been updated for OS X since 10.6 or 10.7. The file GNUstepBase/GSVersionMacros.h defines these constants, among others. There are no constants that would map to 10.7 or 10.8, but NSCalender.h does use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the moment. GNUstepBase/GSVersionMacros.h: #ifndef MAC_OS_X_VERSION_10_0 #define MAC_OS_X_VERSION_10_0 10 #define MAC_OS_X_VERSION_10_1 100100 #define MAC_OS_X_VERSION_10_2 100200 #define MAC_OS_X_VERSION_10_3 100300 #define MAC_OS_X_VERSION_10_4 100400 #define MAC_OS_X_VERSION_10_5 100500 #define MAC_OS_X_VERSION_10_6 100600 #endif /* MAC_OS_X_VERSION_10_0 */ Note: these symbols are defined in /usr/include/AvailabilityMacros.h. I can't imagine Apple switched from a six digit scheme to a four digit scheme without changing the symbol names because their own documentation advises using hardcoded numbers instead of symbol names. But I also can't imagine GNUstep would have used the same symbol names in a different manor. It would have been just as easy to use a different symbol name pattern to represent GNUstep's version of the OS version. I can't find a reference to such a change happening so maybe GNUstep code was always doing its own thing. /usr/include/AvailabilityMacros.h: /* * Set up standard Mac OS X versions */ #define MAC_OS_X_VERSION_10_0 1000 #define MAC_OS_X_VERSION_10_1 1010 #define MAC_OS_X_VERSION_10_2 1020 #define MAC_OS_X_VERSION_10_3 1030 #define MAC_OS_X_VERSION_10_4 1040 #define MAC_OS_X_VERSION_10_5 1050 #define MAC_OS_X_VERSION_10_6 1060 #define MAC_OS_X_VERSION_10_7 1070 #define MAC_OS_X_VERSION_10_8 1080 The place where this bites us now when building for OS X is that Apple's symbol, MAC_OS_X_VERSION_MAX_ALLOWED, gets pulled in from a system header, AvailabilityInternal.h and is used to test against the six digit values. /usr/include/AvailabilityInternal.h:#define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_8 But Apple defines __MAC_10_8 like this: /usr/include/Availability.h:#define __MAC_10_8 1080 And defining it as 1080 instead of 100800 breaks the assumptions in the GNUstep-base code. Examples: NSPointerFunctions.h: #if OS_API_VERSION(100500, GS_API_LATEST) 100500 would be less than 100800 but it is not less than 1080, so code that should be expanded by the preprocessor is not, and the build fails. All these OS X version checks in the code could be changed from the hardcoded numbers like the example above in NSPointerFunctions.h to use symbol names if we wanted to support some systems where the digits were four and others where they were six. But that would mess up anyone who had defined the current symbol in their build script. Grep'ing through the -base code for OS_API_VERSION, there are over 300 uses of the macro, but only 20 unique forms really: #if OS_API_VERSION(100200, GS_API_LATEST) #if OS_API_VERSION(100300, GS_API_LATEST) #if OS_API_VERSION(100400, GS_API_LATEST) #if OS_API_VERSION(100500, GS_API_LATEST) #if OS_API_VERSION(100600, GS_API_LATEST) #if OS_API_VERSION(100700, GS_API_LATEST) #if OS_API_VERSION(GSAPI_MACOSX, GS_API_LATEST) #if OS_API_VERSION(GSAPI_NONE, GSAPI_NONE) #if OS_API_VERSION(GS_API_MACOSX, GS_API_LATEST) #if OS_API_VERSION(GS_API_MACOSX, HS_API_LATEST) #if OS_API_VERSION(GS_API_NONE, GS_API_LATEST) #if OS_API_VERSION(GS_API_NONE, GS_API_NONE) #if OS_API_VERSION(GS_API_OPENSTEP, GS_API_MAC
