[webkit-dev] Proposal for a new way to handle porting #ifdefs

[Maciej Stachowiak]

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.

Regards,
Maciej