[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2009-05-25 7:33:52
Message-ID: 72659F34-CC77-4676-BBF2-C3A45322238E () apple ! com
[Download RAW message or body]


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

> On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak <mjs@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  
patches.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]