[webkit-dev] Proposal for a new way to handle porting #ifdefs
mjs at apple.com
Tue May 5 08:16:43 PDT 2009
On May 4, 2009, at 7:45 PM, George Staikos wrote:
> I really like this and it goes in the direction that I was hoping
> for as well. Hopefully we can get the WINCE port merged upstream
> before we make this change. :-)
> Some comments I have:
> 1) In some cases some things apply to more than one OS so we have:
> #if OS(x) || OS(y) || OS(z) ...
> I think we should use:
> #if OS(x,y,z)
I think using the "||" operator is more clear, except perhaps in cases
where there is a well-defined OS family, such as the Unix-like family
of operating systems, or the Windows family. In that case, the OS
family should get is own macro.
> 1b) WINCE actually includes plenty of WIN but in some cases does
> things differently. How to make this distinction without lots of &&
> and ||?
Perhaps we need another basic OS macro besides WINCE and WIN, which
would refer to only full/desktop versions of Windows. Or maybe WIN
should mean desktop Windows, and some new macro could represent the
facilities that are common to Windows and Windows CE. Then it's just a
matter of using the right ifdefs in the right place.
> 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that
> are not necessarily platform specific but specific to our browsers.
> I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't
> like filling the code with these but we all do it, including MAC.
> MAC tends to win the default right now. I'm not sure how best to
> handle this yet but I foresee a big mess if we aren't careful.
The idea in my proposal is that catchalls like PLATFORM(CHROMIUM),
PLATFORM(MAC) and PLATFORM(TORCHMOBILE) would all be phased out, and
replaced with macros that describe specific policy decisions. Anyone
could make a PortFoo.h header that makes their preferred set of policy
choices, but in the code itself the macros would say how and why
something is different, rather than who chose to make it different.
This may take time for ports that made heavy use of catchall macros,
since in some cases it may be necessary to reverse-engineer the
original intent of a port variation, or it may not even have been
clearly thought out why particular things should be different. It took
us some time to get rid of the older APPLE_CHANGES macro that we used
to apply to almost any change we made.
> Again, fully support these changes and perhaps some more too. Just
> give us a bit of time to find the right way to merge the WINCE stuff
> in first please!
I wouldn't expect us to start changing things next week, but since
generally I've heard support for these changes, I would expect in a
month or two at most we'll likely start on deploying them. Most likely
we will come up with a system that allows gradual migration. At some
point, we'll likely require new code to use new-style macros only and
not the old PLATFORM stuff.
More information about the webkit-dev