Ping. On Tue, May 29, 2012 at 6:00 PM, Richard Smith <[email protected]>wrote:
> On Tue, May 29, 2012 at 5:14 PM, Joerg Sonnenberger < > [email protected]> wrote: > >> On Tue, May 29, 2012 at 04:22:22PM -0700, Richard Smith wrote: >> > On Tue, May 29, 2012 at 2:08 PM, Joerg Sonnenberger < >> [email protected] >> > > wrote: >> > > 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. >> >> If you have one directory tree for them, at most one additional stat. >> > > I would still expect that to be more expensive than one strcmp. But I > think this is beside the point, since either way the cost is probably small > (and I've not measured it). > > >> Build system surgery should be minimal (add the -isystem >> $build/sys-includes entry and creating the directory). > > > Combine that with a distributed build system which has ingrained > assumptions about how the code is laid out, and doesn't expect to need to > make such directories and symlinks, and the cost is not minimal. > > >> The reason why I >> am a bit perplexed by such a tight coupling (#include with path relative >> to the project root for 3rd party libraries) is that it tends to >> conflict with the often desirable goal to re-use system libraries as >> much as possible and that the 3rd party libraries are normally not > > written for such an include style anyway. > > > Using system libraries is an explicit non-goal for many situations. For > instance, depending on system libraries makes it much harder to produce > binaries which work on a wide range of systems. > > Third party headers frequently include each other through relative paths > rather than by assuming they're installed somewhere on the include path. > Naturally there are exceptions to that, where the library would need some > massaging to work in such a layout, but (for instance) I don't believe any > of the third_party libraries in chromium needed special treatment. > > I don't believe the setup I'm describing is especially common, but I think > this is a good approach for dealing with it. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
