[webkit-dev] Reg. New File Inclusion Style for Webkit

Ryosuke Niwa rniwa at webkit.org
Sun Dec 4 11:39:49 PST 2011


I don't think we want to do this. We move files around quite often, and
specifying relative path will make it harder to do so as Peter pointed out.

- Ryosuke

On Sun, Dec 4, 2011 at 2:02 AM, Arunprasad Rajkumar
<ararunprasad at gmail.com>wrote:

> yes, this will yield a good results for build time. I would like to get
> more comments from other developers regarding this.
>
>
> On 21 November 2011 06:24, Peter Kasting <pkasting at google.com> wrote:
>
>> On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar <
>> ararunprasad at gmail.com> wrote:
>>
>>> Why don't we follow chrome style of file inclusions rather than the
>>> usual.
>>>
>>> For example,
>>> *#include "WebCore/Page/Chrome.h"*
>>>
>>> This will be more convient way of representing the inclusion. Hope it
>>> will avoid long compiler inclusion paths and file namespace issues.
>>
>>
>> Here are some pros and cons I can think of:
>>
>> Pros:
>> * If used pervasively, would allow us to greatly trim the compiler
>> include search paths, possibly providing a noticeable build speedup (I have
>> no estimated numbers).
>> * Makes it slightly more obvious to a reader what, precisely, is being
>> depended upon; might make it easier to notice layering violations.
>>
>> Cons:
>> * Would require us to convert the existing codebase (possibly easy with
>> the help of a script, but would at least result in touching all the files)
>> * Generates more "change noise" when a header is moved around
>> * Could pose problems for ports that need to supply particular headers
>> from some override directory instead of the "typical" spot.  (I'm being
>> vague here because I think this is probably a real issue but I don't
>> actually know the details of enough ports' build setups to be clear.)
>>
>> I would prefer the full-path style myself, especially if there is really
>> a build-time win, but I strongly suspect that a lot of folks would see the
>> benefit here as not worth the cost.
>>
>>  PK
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111204/de9bd5e4/attachment.html>


More information about the webkit-dev mailing list