Re: MAC_OS_X_VERSION macros

[Ivan Vučica]

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