On May 22, 2012, at 3:36 PM, 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.
>
> The natural way to suppress warnings from third-party headers would be to
> treat them as system headers, but we only have two ways to achieve this:
> -isystem (which doesn't work for this file layout), and #pragma system_header
> (which requires updating *all* the third_party headers). Neither of these
> seems to be a good solution to the problem.
>
> The attached patch addresses this by adding two command-line arguments:
> -isystem-prefix FOO/ treats all #include "FOO/..." directives as including a
> system header, and -ino-system-prefix FOO/BAR/ treats all #include
> "FOO/BAR/..." directives as not including a system header. The
> latest-specified argument wins, and the overrides only apply to files which
> are found relative to a header search path (and not ones which are found
> relative to the current file, or by absolute path).
>
> Is this OK for mainline Clang? The implementation is currently not optimized
> for the case of large numbers of such arguments -- we can deal with that
> later if it becomes an issue.
We had run into precisely this problem at the framework level and (fairly
recently) added a framework-only hack that allows a framework's headers to be
treated as system headers. It was a kludge; your solution seems somewhat more
general.
I was a little surprised to see that it's based on the style of include
(<Foo/>) rather than on a particular subdirectory. Was that a specific design
decision or was it a more expedient implementation approach?
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
