Re: MAC_OS_X_VERSION macros

[Eric Wasylishen]

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   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 */

#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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 写道：

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
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev

_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev