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 <frankrehwin...@gmail.com> 写道:

> 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   100000
>     #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_MACOSX)
>     #if OS_API_VERSION(GS_API_OSSPEC, GS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_2, GS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_4, GS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_4, OS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_5, GS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_6, GS_API_LATEST)
>     #if OS_API_VERSION(MAC_OS_X_VERSION_10_7, GS_API_LATEST)
> 
> 
> Here are the unique definitions for the symbols used in the GNUstep calls to
> OS_API_VERSION(), listed in order of there constant values.
> 
> *** GS_API_NONE
> ./Headers/GNUstepBase/GSVersionMacros.h:#define       GS_API_NONE          0
> 
> *** GS_API_OSSPEC
> ./Headers/GNUstepBase/GSVersionMacros.h:#define       GS_API_OSSPEC    10000
> ./Tools/AGSHtml.m:#define     GS_API_OSSPEC   10000
> 
> *** GS_API_OPENSTEP
> ./Headers/GNUstepBase/GSVersionMacros.h:#define       GS_API_OPENSTEP  40000
> ./Tools/AGSHtml.m:#define     GS_API_OPENSTEP 40000
> 
> *** GS_API_MACOSX
> ./Headers/GNUstepBase/GSVersionMacros.h:#define       GS_API_MACOSX   100000
> ./Tools/AGSHtml.m:#define     GS_API_MACOSX   100000
> (Could change this to MAC_OS_X_VERSION_10_0 to make it more readable but 
> probably that's getting carried away.)
> 
> *** GS_API_LATEST
> ./Headers/GNUstepBase/GSVersionMacros.h:#define       GS_API_LATEST   999999
> 
> ***** And four symbols used a handful of times that look in error.
> 
> *** OS_API_LATEST - only appears in Foundation/NSZone.h
> (no definition found - perhaps typo in Foundation/NSZone.h - 
> could change OS_... to GS_...)
> 
> *** GSAPI_MACOSX - only appears in Foundation/NSUserDefaults.h
> (no definition found - perhaps typos in Foundation/NSUserDefaults.h - could
> change GSAPI_... to GS_API_...)
> 
> *** GSAPI_NONE - also only appears in Foundation/NSUserDefaults.h
> (no definition found - perhaps typo in Foundation/NSUserDefaults.h - could
> change GSAPI_... to GS_API_...)
> 
> *** HS_API_LATEST - only used in Headers/Foundation/NSPortNameServer.h
> (no definition found - probably a typo of GS_API_LATEST)
> 
> Should the GNUstep-base macros be based on four digit OS X version numbers or 
> six digit?
> If left as six digits, should the lines that use symbols like 
> MAC_OS_X_VERSION_10_7
> be changed to use the hard coded numbers like 100700?  To avoid any possible 
> ambiguity
> later on from the four digit symbols appearing in the Apple headers?
> 
> Thanks,
> -Frank
> 
> _______________________________________________
> 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

Reply via email to