On 6/8/22 13:55, Tom Honermann via SG15 wrote:
> On 6/8/22 1:22 PM, Gabriel Dos Reis wrote:
>>
>> [Steve]
>>
>> * However, at least on Unix-ey environments, the ability to
>> deliberately shadow headers is very important. That is, being able
>> to interpose the headers for a library, and the library itself, to
>> provide a newer version, or to do development on the library that
>> happens to be on the system already. This sort of environment is
>> somewhat less common on Windows, from what I remember and have
>> seen, unless they're deliberately imitating a unix file hierarchy.
>>
>> Actually, that need is really not that different from ability to
>> relocate. Shadowing/interposing can be achieved by specifying an
>> alternate header unit map.
>>
> Compilers that target these Unix-ey environments tend to support
> #include_next. I suppose that is a whole 'nother ball of wax to consider
> with respect to modules. If I remember correctly, support for
> #include_next depends on finding the including file in the include path
> search in order to know where to continue searching from (I'm not
> confident in my recollection though, so don't quote me on that).

It means you have to know which entry on the include path was used to
find the header you are in. Then only consider later entries in the
include path.

It doesn't mean 'find the current file on the include path, and then go
from there'. That would fail with a #include_next'd file that itself
#include_nexts something.

gcc and clang have some heuristics to replicate these semantics when
building header-units.

>
> Tom.
>
>> -- Gaby
>>
>> *From:* Steve Downey <sdowney_at_[hidden]>
>> *Sent:* Wednesday, June 8, 2022 8:24 AM
>> *To:* ISO C++ Tooling Study Group <sg15_at_[hidden]>
>> *Cc:* Tom Honermann <tom_at_[hidden]>; Gabriel Dos Reis
>> <gdr_at_[hidden]>
>> *Subject:* Re: [SG15] "logical name" of importable headers
>>
>> On Wed, Jun 8, 2022 at 12:43 AM Gabriel Dos Reis via SG15
>> <sg15_at_[hidden]> wrote:
>>
>> I have a few reservations:
>>
>> 1. Trying to resolve the header file before consulting the header
>> unit map to BMI involves poking the filesystem, which we have
>> empirically found to be performance bottleneck (one of the
>> reasons it is good to move away from the whole include path
>> story), even with SSD on “fast” filesystems. It is common to
>> have hundreds of ‘-I’ supplied by the build at scale, and the
>> one that is relevant is at the very end.
>>
>> Or the opposite problem with a very few -I paths with 100K files in
>> each of them. Mounted as NFS, of course.
>>
>> However, at least on Unix-ey environments, the ability to deliberately
>> shadow headers is very important. That is, being able to interpose the
>> headers for a library, and the library itself, to provide a newer
>> version, or to do development on the library that happens to be on the
>> system already. This sort of environment is somewhat less common on
>> Windows, from what I remember and have seen, unless they're
>> deliberately imitating a unix file hierarchy.
>>
>> 1.
>> 2. Resolving to absolute path defeats ability to relocate – I know
>> not every one here cares, but people in my user population do care
>> about ability to relocate BMIs. (we have done lot of shenanigans
>> with __FILE__ and friends, but it is better not to create the
>> problem in the first place).
>>
>> -- Gaby
>>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
Nathan Sidwell