[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
patches.
Regards,
Maciej
More information about the webkit-dev
mailing list