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

[Chandler Carruth]

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?


We've run into it in several contexts, Chrome not the least among them.

Clearly this is common enough for us to care about it and write the patch,
and we're hoping to minimize the impact on the rest of Clang.


> Projects I'm familar with all have
> libs/foo/include that's added to the include path. 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.
>

Just to be clear, we're primarily focused on optimizing the user experience
for Clang warnings. Our recommendation is usually to simply disable the
warnings from other compilers that are problematic, and this has worked
quite well.

Put another way, the codebases in question are compiling cleanly and
without warnings today. The goal is to be able to turn on more of Clang's
warnings by default, and turn on new warnings easily without having to mop
up other libraries' header files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120529/45e7278e/attachment.html>