<div class="gmail_quote">On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar <span dir="ltr"><<a href="mailto:ararunprasad@gmail.com">ararunprasad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Why don't we follow chrome style of file inclusions rather than the usual.<br><br>For example,<br><b style="color:rgb(0,153,0)">#include "WebCore/Page/Chrome.h"</b><br><br>This will be more convient way of representing the inclusion. Hope it will avoid long compiler inclusion paths and file namespace issues.</blockquote>
<div><br></div><div>Here are some pros and cons I can think of:</div><div><br></div><div>Pros:<br>* 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).</div>
<div>* Makes it slightly more obvious to a reader what, precisely, is being depended upon; might make it easier to notice layering violations.</div><div><br></div><div>Cons:</div><div>* 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)</div>
<div>* Generates more "change noise" when a header is moved around</div><div>* 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.)</div>
<div><br></div><div>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.</div><div><br></div>
<div>PK</div></div>