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

[Richard Smith]

On Tue, May 29, 2012 at 5:14 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> 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 <
> joerg at britannica.bec.de
> > > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120529/4a98e6b5/attachment.html>