[webkit-dev] Compiling WebKit up to 25% faster in Windows?
rniwa at webkit.org
Tue Mar 26 14:08:55 PDT 2013
On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> On 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>
>> 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 :).
> I'm with Dirk on this. Full path would help hackability for me.
> I don't use an IDE, so I'll be typing more. But I spend more time reading
> code than typing code.
> Also we have a lot of stupid in header file naming right now. For example
> the DFG calls the JSC::DFG::Node header "DFGNode.h", and puts it in
> JSC::DFG::Node in both the filename and the directory name. Ridiculous!
> If we had a discipline to always include using paths relative to Source,
> me happy.
That'll make me sad because then Xcode will then find both
Unfortunately, we can't name Node.h in WebCore/dom DOMNode.h because
DOMNode.h already exists for Objective C bindings.
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev