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 <[email protected]> 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 <[email protected]> 写道： > > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
