On 2009-03-14, at 10:49, Kevin Ollivier wrote:
Hi all,I'm seeing some strangeness with the OS X availability macros. First, it looks like BUILDING_ON_TIGER and BUILDING_ON_LEOPARD are defined in JavaScriptCorePrefix.h, which AFAICT is only used by the Apple XCode projects, yet the use of these macros are often inside PLATFORM(DARWIN) rather than PLATFORM(MAC) checks, meaning other ports building on Mac will need them too. Second, even after I tried moving them to Platform.h, the MAX_ALLOWED <= MAC_OS_X_VERSION_10_5 check doesn't work for me, because apparently MAX_ALLOWED is defined to the actual latest release on my machine (1056) rather than (1050), and so the check doesn't pass and so it sets things up as if I'm running something post-Leopard, which I only wish I were doing... ;-) Checking MAX_ALLOWED <= 1056 does get things going right again.
The use of the BUILDING_ON macros inside PLATFORM(DARWIN) blocks may all be recent additions. I introduced one such use earlier this week, and I believe Darin may have done so as well. I'm not sure whether there were any instances of this prior to those two changes. Moving the macro definitions in to wtf/Platform.h so that they can be used by other ports building on Mac OS X seems reasonable to me, but we may need to tweak them slightly to work with ports that aren't aware of the SDK and deployment target mechanisms that Mac OS X's compiler toolchain provides.
For some background: the way these macros are intended to function is that MAC_OS_X_VERSION_MIN_REQUIRED indicates the minimum version of the operating system that the binary will run on, while MAC_OS_X_VERSION_MAX_ALLOWED indicates the maximum version of the operating system that you intend to take advantage of. Symbols introduced in OS versions between MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will be weak-linked, and symbols introduced after MAC_OS_X_VERSION_MAX_ALLOWED will be unavailable for use.
When building via Xcode these values are typically derived from two configuration settings: the SDK that your project is targeting (corresponding to GCCs -isysroot argument), and the deployment target (-mmacosx-version-min). If you build against the MacOSX10.5 SDK with a deployment target of 10.4 you will see that MAC_OS_X_VERSION_MIN_REQUIRED is set to 1040 and MAC_OS_X_VERSION_MAX_ALLOWED is set to 1050.
If you don't build against an SDK or specify a deployment target then both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will default to your current Mac OS X version (eg, 1056), and the compiler happily let you use functionality that would prevent your application from running on previous versions of Mac OS X.
The Mac build of WebKit explicitly sets a deployment target equal to the major version of the Mac OS X version that you are on. This results in both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED being set to the major component of the Mac OS X version (eg, 1050).
Since the wxWidgets build of WebKit doesn't build against an SDK or explicitly set a deployment target, it is seeing MAC_OS_X_VERSION_MAX_ALLOWED set to 1056 where the Mac build sees 1050. This is why the checks that set BUILDING_ON_LEOPARD aren't working for you.
I think we could rephrase the checks to accommodate building without an SDK and deployment target. Something like the following should do the trick:
#if !defined(MAC_OS_X_VERSION_10_5) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_5
#define BUILDING_ON_TIGER 1#if !defined(MAC_OS_X_VERSION_10_6) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_6
#define BUILDING_ON_LEOPARD 1 #endif I hope this clears things up. Let me know if you have any questions! - Mark
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
