<div class="gmail_quote">On Tue, May 29, 2012 at 2:08 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 class="im">On Tue, May 22, 2012 at 03:36:25PM -0700, Richard Smith wrote:<br>
> Hi,<br>
><br>
> Some popular open-source projects have a code layout which looks something<br>
> like this:<br>
><br>
> project/<br>
>   libs/<br>
>     some_third_party_lib/<br>
>     my_own_lib/<br>
>   foo/my_code/<br>
>   bar/my_code/<br>
><br>
> ... with a single include path pointing at the root of the project. When<br>
> rolling out new warnings to such projects, warnings in the project's own<br>
> code should be fixed, and warnings in third-party headers should typically<br>
> be ignored. However, this is currently hard to achieve.<br>
<br>
</div>Is that really common? Projects I'm familar with all have<br>
libs/foo/include that's added to the include path.</blockquote><div><br></div><div>As an example, chromium uses this approach (where its "libs" is called "third_party").</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>Adding an additional directory to search on each #include sounds like it would be a lot slower than adding a string comparison. Additionally, this would require significant build system surgery for existing projects.</div>
</div>