[webkit-dev] Compiling WebKit up to 25% faster in Windows?
jamesr at google.com
Tue Mar 26 13:47:26 PDT 2013
Also keep in mind that currently different build systems hack the include
path up to have the same #include point to different headers depending on
the build configuration, so the path expansion for a given #include will
not be the same for all ports. It's basically a very non-obvious way to do
#if PLATFORM() guards at include sites without looking like it. For
instance there are 7 different versions of AuthenticationChallenge.h but
only one #include statement in ResourceLoader.cpp.
$ find Source/WebCore -name "*.h" -printf "%f\n" | wc -l
$ find Source/WebCore -name "*.h" -printf "%f\n" | sort | uniq | wc -l
On Tue, Mar 26, 2013 at 1:40 PM, Dirk Pranke <dpranke at chromium.org> wrote:
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain <benjamin at webkit.org>wrote:
>> 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.
> Interesting. I have the exact opposite experience, having to paw around to
> figure out where "Font.h" actually lives rather than just seeing
> At any rate, to be clear, I would be in favor of that change but I'm not
> expecting it to happen :).
> -- Dirk
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev