[Webkit-unassigned] [Bug 30526] Supporting multiple OS X versions in one binary

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 19 23:41:55 PDT 2009


--- Comment #5 from Kevin Ollivier <kevino at theolliviers.com>  2009-10-19 23:41:55 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (From update of attachment 41439 [details] [details] [details])
> > > It may appear to work but it will have subtle bugs as *all* of the code wrapped
> > > with these macros was written with the assumption that the code within these
> > > blocks was targeted for the specific OS version.  When building in the manner
> > > you mention it will be running on a different version of the OS and may not
> > > behave as expected.  A number of aspects of the code would likely need to be
> > > updated to determine the underlying OS version at runtime and to react
> > > accordingly.
> > > 
> > > It also doesn’t make sense to switch a single use of BUILDING_ON_TIGER and
> > > BUILDING_ON_LEOPARD to using availability macros.  If we’re going to make this
> > > change it needs to be done in a more consistent manner.
> > 
> > Okay, after doing a grep what I'm seeing is that a vast majority of the use of
> > these macros are in Mac port sources or code blocks, which won't use this
> > support anyway, at least not in the short term. Perhaps that somewhat explains
> > why the change didn't seem so problematic for the wx port.
> Many of them are Mac-only, yes.  ICU is a significant case that is not specific
> to the Mac version of WebKit, but where the behavior can differ significantly
> from Tiger’s version to SnowLeopard.  We handle this with compile-time checks.
> > So, how about this? We create a SUPPORTS_<CAT> or <CAT>_COMPATIBLE (where CAT
> > is release name) type of define that corresponds to MIN_REQUIRED for non-Mac
> > ports but for Mac (or any port that wants to keep the existing behavior) will
> > simply be defined to  BUILDING_ON_<CAT> for compatibility. The only other thing
> > this would probably require is to add weakly defined symbol checks to allow to
> > use the newer API when running on a newer release, but since wx doesn't use
> > much of the Mac port's Cocoa, CF or CG code,  nor presumably would Qt or GTK, I
> > suspect this would actually only need to be done in a few spots.
> I can’t easily follow what you’re suggesting here.

I'm basically suggesting we add defines such as SUPPORTS_TIGER which would be
set as follows

#elif PLATFORM(DARWIN) && defined(MAC_OS_X_VERSION_10_4)
                && MAC_OS_X_MIN_REQUIRED == MAC_OS_X_VERSION_10_4
#define SUPPORTS_TIGER // can be true even under Leopard or Snow Leopard

Then say we have the following example code block somewhere in common code:

... 10.4 compatible code ...
... 10.5 compatible code ...
... 10.6 compatible code ...

It would change to:

... 10.4 compatible code ...
... 10.5 compatible code ...
... 10.6 compatible code ...

So the Apple/Mac port would compile this code exactly the same as it does
today, because there SUPPORTS_TIGER is only true when BUILDING_ON_TIGER is
true, but ports like wx would compile the 10.4 codepath even under 10.5 or 10.6
so long as 10.4 support was set as the min required system. Does this make
things clearer?

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list