[webkit-dev] BUILDING_ON_TIGER/LEOPARD macros

Kevin Ollivier kevino at theolliviers.com
Sun Mar 15 10:24:24 PDT 2009

Hi Mark,

Thanks for the detailed explanation! I just landed a fix based on your  
suggestions. It built okay with both the wx and Apple ports, but if it  
causes anyone trouble, please let me know!



On Mar 14, 2009, at 7:31 PM, Mark Rowe wrote:

> 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  
> 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:
> #endif
> I hope this clears things up.  Let me know if you have any questions!
> - Mark

More information about the webkit-dev mailing list