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

Arunprasad Rajkumar ararunprasad at gmail.com
Sun Dec 4 02:02:08 PST 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111204/8d7310d3/attachment.html>


More information about the webkit-dev mailing list