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).

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
>