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

[Maciej Stachowiak]

On Mar 26, 2013, at 2:34 PM, Jarred Nicholls <jarred at webkit.org> wrote:

> 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.

I realize that this is partly a matter of taste, and I do not feel too strongly. But I prefer being able to include headers by the short name without the include path. To me, listing the path feels like visual noise and doesn't aid my understanding. But I realize others may feel differently.

I also dislike having files with the same name, whether or not you include them by full path. If you do that, then you need to disambiguate to even talk about a file. 

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130326/765c9051/attachment.html>