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

[Richard Smith]

Ping.

On Tue, May 29, 2012 at 6:00 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> 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/20120605/ff5709a1/attachment.html>