Ping. On Tue, May 22, 2012 at 3:36 PM, Richard Smith <[email protected]>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. > > Richard >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
