[webkit-dev] BUILDING_ON_TIGER/LEOPARD macros

[Mark Rowe]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2413 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090314/0f17aa30/attachment.bin>