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

Filip Pizlo fpizlo at apple.com
Tue Mar 26 13:53:08 PDT 2013

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> 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 "WebCore/platform/graphics/Font.h".
> 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 JavaScriptCore/dfg/DFGNode.h.  So we duplicate the namespacing of 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, then we could just rename it to JavaScriptCore/dfg/Node.h.  That would make me happy.


> -- Dirk 
> _______________________________________________
> 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/20130326/e928f90d/attachment.html>

More information about the webkit-dev mailing list