[cfe-commits] [PATCH] Overriding system-header-ness based on #include path

[Richard Smith]

On Tue, May 29, 2012 at 2:08 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Tue, May 22, 2012 at 03:36:25PM -0700, Richard Smith wrote:
> > Hi,
> >
> > Some popular open-source projects have a code layout which looks
> something
> > like this:
> >
> > project/
> >   libs/
> >     some_third_party_lib/
> >     my_own_lib/
> >   foo/my_code/
> >   bar/my_code/
> >
> > ... with a single include path pointing at the root of the project. When
> > rolling out new warnings to such projects, warnings in the project's own
> > code should be fixed, and warnings in third-party headers should
> typically
> > be ignored. However, this is currently hard to achieve.
>
> Is that really common? Projects I'm familar with all have
> libs/foo/include that's added to the include path.


As an example, chromium uses this approach (where its "libs" is called
"third_party").


> I think you can get
> the same results with an additional include directory containing
> symlinks for the 3rd party libraries you don't care about. Which should
> be both faster and work for a bunch of other compilers as well.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120529/a94725b9/attachment.html>