It is my impression GNUstep doesn't even build on OS X10.8, so for a few years it hasn't been used for building on OS X the same code that builds on other OSes nor for building code that was first built for Cocoa? I've only tried while having objc2 prebuilt on my mac so maybe I wasn't following an established build and install recipe. Anyway, having the GS code use the wrong length for the MAC OS version identifier seems wrong. And adding more header code to work around this will just make it harder to maintain and debug.
I think the first step would be to fix the length to conform to the six digits that Apple uses. Then at least the code has a chance to work again on OS X. A second, later step, could be to evaluate the need for GS headers to define the MAC_OS_X symbols. It seems odd that it does now, but it sounds like a call that someone with experience with GS and who is still actively maintaining GS for MAC should make. On Wed, Jun 26, 2013 at 5:33 AM, Wolfgang Lux <[email protected]>wrote: > Ivan Vučica wrote: > > > 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. > > That would indeed be better. However, to do that we first need to fix all > places where the numeric values of the version macros are used. This, of > course, should be done anyway, and my code is just meant as a workaround > (call it a hack) until this is done. > > 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
