‘#include_next’ adds another level of ambiguity, in an attempt to resolve the ‘#include “config..h”’ problem, excepts it adds another one 😊
One question is whether those compilers+build systems would prefer to “normalize” those included headers.

-- Gaby

From: Tom Honermann <tom_at_[hidden]>
Sent: Wednesday, June 8, 2022 10:56 AM
To: Gabriel Dos Reis <gdr_at_[hidden]m>; Steve Downey <sdowney_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers

On 6/8/22 1:22 PM, Gabriel Dos Reis wrote:
[Steve]

  1. 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]><mailto:sdowney_at_gmail.com>
Sent: Wednesday, June 8, 2022 8:24 AM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]><mailto:sg15_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]><mailto:tom_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]><mailto: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]<mailto: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