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. Regards, Ivan Vučica via phone On 26. 6. 2013., at 10:40, Wolfgang Lux <[email protected]> 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 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? > > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
