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

Nico Weber thakis at chromium.org
Tue May 29 17:28:36 PDT 2012


On Tue, May 29, 2012 at 2:47 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 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.

(While chromium does use this layout, we don't need this flag. We've
managed to fix warnings in our libraries in the various upstreams so
far. So maybe we're not the best motivating example for this.)

>
> 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.
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>




More information about the cfe-commits mailing list