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

Filip Pizlo fpizlo at apple.com
Wed Mar 27 00:48:22 PDT 2013


On Mar 26, 2013, at 5:51 PM, Benjamin Poulain <benjamin at webkit.org> wrote:

> 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 idea.
> 
> If such a change comes with the appropriate tooling for moving/renaming files, I am not opposed to it.

I think a script to do a project-global search-and-replace of <foo/Bar.h> with <fizz/Buzz.h> would do the trick.

> 
> Benjamin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130327/26632d6f/attachment.html>


More information about the webkit-dev mailing list