[webkit-dev] Compiling WebKit up to 25% faster in Windows?

Benjamin Poulain benjamin at webkit.org
Tue Mar 26 17:51:38 PDT 2013

On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell <bratell at opera.com> wrote:

> Den 2013-03-26 21:29:32 skrev Benjamin Poulain <benjamin at webkit.org>:
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke <dpranke at chromium.org> wrote
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options), that would be (IMO) a big
>>> win. It sounds like Daniel & co. have already done the big bang
>>> conversion.
>> I think using full path would be a serious hit regarding hackability.
>> I would rather spend some time tweaking my compiler to cache each
>> directory
>> content than waste time finding where is every single header I need to
>> include.
> I guess you mean that it will be more job moving files around, but that is
> a rather rare operation, while reading an include directive and wondering
> what it's part of is rather common (both for compilers, tools and humans).

My personal issue with full path is I don't think of the code base in term
of files but in terms of classes.
I don't care where the files are, it is a detail.

The problem of moving file is also obvious.
There is already a huge cost associated with moving and renaming files (all
the build systems). It is to the point that people will prefer leaving
broken name rather than renaming headers. By having full path, you would
increase that cost further, making refactoring even harder.

> I like the paths as a tool to indicate "module" dependencies. You can more
> easily see that a file depends on foo and bar (but not on fie) if you see:

> #include "foo/object.h"
> #include "foo/thing.h"
> #include "bar/stuff.h"
> That will tell you useful things, and avoid making layering violations by
> accident.

I don't understand this argument.

We already have WTF, WebCore, WebKit and we use them as prefix when
including headers.
The last problem is platform. But it should be fixed by moving it outside
WebCore, not by changing everything else.

I think is already silly to have wtf/text as a weird exception.

But I realize it's a question of style and as such there is not a right and
> a wrong, unless there are other factors. And here we have the seemingly
> heavy compilation time cost for it which I think is a strong argument
> against delegating the task of finding the header files to the compiler.

Hackabilty is a project goal. Compile time is not.
If the change means people are afraid to move/rename files, it is a bad

If such a change comes with the appropriate tooling for moving/renaming
files, I am not opposed to it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130326/686536f8/attachment.html>

More information about the webkit-dev mailing list