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

[Jesus Sanchez-Palencia]

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


>
> - R. Niwa
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>