On Tue, May 29, 2012 at 2:08 PM, Joerg Sonnenberger <[email protected] > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
