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

Maciej Stachowiak mjs at apple.com
Mon May 25 00:33:52 PDT 2009

On May 24, 2009, at 10:38 PM, Adam Barth wrote:

> On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>> I don't think it should be discounted. It might be helpful to  
>> clarify why
>> you think ifdefs are a bad solution.
> When I made changes that affect several ports, I try to be good WebKit
> citizen and update all the ports, but the situation we have today
> makes that a pain.  For example, consider the case of adding a method
> to ChromeClient.  I understand that I have to add the method to a
> bunch of port-specific subclasses, but theses classes are stored in
> slightly different locations (WebCoreSupport or WebKitSupport?), have
> different naming conventions (WebChromeClient or ChromeClientGtk?),
> and have different names spaces (using namespace WebCore or not?).
> All these issues combine to ensure that I've screwed it up, and I
> don't really have a way to test because I can't building the XYZ port.
> I just have to check in my change and pray.
> Anyway, that's my rant.  Are patches welcome for homogenizing some of
> these idiosyncrasies?

I would be in favor, though in general we leave the WebKit layer up to  
port owners. Maybe others would like to chime in.

I think one key step here will be to have a "try server" integrated  
with the buildbots, so that it's at least practical to test such  


More information about the webkit-dev mailing list