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

[Jarred Nicholls]

On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia <jesus at webkit.org>wrote:

> 2013/3/26 Ryosuke Niwa <rniwa at webkit.org>:
> > 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>
> >> 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.
> >
> >
> > That'll make me sad because then Xcode will then find both
> > WebCore/dom/Node.h and JavaScriptCode/dfg/Node.h when I type Node.h.
> >
> > Unfortunately, we can't name Node.h in WebCore/dom DOMNode.h because
> > DOMNode.h already exists for Objective C bindings.
>
>
> IMHO, we should be favoring code readability instead of a tool's feature.
>
> +1 for full paths.
>
> -jesus
>
>
My sentiment exactly.  And I agree with Dirk and Filip, seeing full paths
improves (my) hackability and clearly shows layer dependencies (and
violations).  I'd say that it would also help people understand where
certain headers live (educational) and to know which header specifically is
being included at compile time rather than it being a guessing game.  This
is just my opinion, but its rendered through experience working in both
chromium code and webkit code.  Having a few files named the same hasn't at
all effected my ability to find the right file (Sublime Text 2), though I
understand that argument.  In fact I'm forced to learn the difference and
distinguish the locations between similarly named files in the code base;
I've found it very helpful.

Jarred


>
> >
> > - R. Niwa
> >
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> _______________________________________________
> 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/6a59ae39/attachment-0001.html>