Ping.<br><br><div class="gmail_quote">On Tue, May 29, 2012 at 6:00 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Tue, May 29, 2012 at 5:14 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Tue, May 29, 2012 at 04:22:22PM -0700, Richard Smith wrote:<br>
> On Tue, May 29, 2012 at 2:08 PM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a><br>
> > wrote:<br>
</div><div>> > I think you can get<br>
> > the same results with an additional include directory containing<br>
> > symlinks for the 3rd party libraries you don't care about. Which should<br>
> > be both faster and work for a bunch of other compilers as well.<br>
><br>
><br>
> Adding an additional directory to search on each #include sounds like it<br>
> would be a lot slower than adding a string comparison. Additionally, this<br>
> would require significant build system surgery for existing projects.<br>
<br>
</div>If you have one directory tree for them, at most one additional stat.<br></blockquote><div><br></div></div><div>I would still expect that to be more expensive than one strcmp. But I think this is beside the point, since either way the cost is probably small (and I've not measured it).</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Build system surgery should be minimal (add the -isystem<br>
$build/sys-includes entry and creating the directory).</blockquote><div><br></div></div><div>Combine that with a distributed build system which has ingrained assumptions about how the code is laid out, and doesn't expect to need to make such directories and symlinks, and the cost is not minimal.</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The reason why I<br>
am a bit perplexed by such a tight coupling (#include with path relative<br>
to the project root for 3rd party libraries) is that it tends to<br>
conflict with the often desirable goal to re-use system libraries as<br>
much as possible and that the 3rd party libraries are normally not</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
written for such an include style anyway.</blockquote><div><br></div></div><div><div>Using system libraries is an explicit non-goal for many situations. For instance, depending on system libraries makes it much harder to produce binaries which work on a wide range of systems.</div>

</div><div><br></div><div>Third party headers frequently include each other through relative paths rather than by assuming they're installed somewhere on the include path. Naturally there are exceptions to that, where the library would need some massaging to work in such a layout, but (for instance) I don't believe any of the third_party libraries in chromium needed special treatment.</div>

<div><br></div><div>I don't believe the setup I'm describing is especially common, but I think this is a good approach for dealing with it.</div></div>
</blockquote></div><br>