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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30526





--- 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

#if PLATFORM(MAC)
#if BUILDING_ON_TIGER
#define SUPPORTS_TIGER // for Apple port, SUPPORTS_TIGER == BUILDING_ON_TIGER
#endif
#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
#endif

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

#if BUILDING_ON_TIGER
... 10.4 compatible code ...
#elif BUILDING_ON_LEOPARD
... 10.5 compatible code ...
#else
... 10.6 compatible code ...
#endif

It would change to:

#if SUPPORTS_TIGER
... 10.4 compatible code ...
#elif SUPPORTS_LEOPARD
... 10.5 compatible code ...
#else
... 10.6 compatible code ...
#endif

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.