* There's the annoying mechanical problem of where to put the resulting pre-compiled header unit.

Yup.

I hope all compilers provide options to specify the output path of the resulting BMI, and that build systems have their own “intermediary” build artifacts directory that they can use to “mirror” the path to the included file.
MSVC also output the full path of the header file found when asked to build a header unit. The intent is to allow automated “header unit map” by the build system.


  * With modules you can dump everything in one place because module names must be unique, and it's straightforward to write dependencies from the primary module interface to the bmi to the importers of the module.

Correct.
Though we should also support the case of “BMI archive” where a bunch of BMIs are put in a single archive and one directs the compiler to find the BMIs in that single file.
Whatever we do, I suspect we would end up with some lite version of “module map”.

-- Gaby

From: Steve Downey <sdowney_at_[hidden]>
Sent: Friday, June 3, 2022 8:25 AM
To: Ben Boeckel <ben.boeckel_at_[hidden]e.com>
Cc: ISO C++ Tooling Study Group <sg15_at_[hidden]p.org>; Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers



On Fri, Jun 3, 2022 at 10:51 AM Ben Boeckel <ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>> wrote:
On Thu, Jun 02, 2022 at 23:06:56 -0400, Steve Downey wrote:
> The case of "config.h" being an importable header, and different across
> translation units in the same build has to be supported.
> ```import "config.h" ``` has to handle collisions, as does the rewritten
> form for #include for "known to be importable". This may mean compilers
> have to stat include paths before concluding about import translation, and
> we have to distinguish absolute paths for the cached effective bmi. I don't
> think we can require uniqueness as we do for module names.

This is…fine. It's no worse than separate `config.h` per library today.
You just have to clarify that `config.h` is a *private* importable
header (and therefore not use it from any module unit importable from a
consumer of your library as part of its API; impl units are fine).

There's the annoying mechanical problem of where to put the resulting pre-compiled header unit. With modules you can dump everything in one place because module names must be unique, and it's straightforward to write dependencies from the primary module interface to the bmi to the importers of the module. It's a little more work for header units. Where to put them runs into the same issues Nathan mentioned above about which files are the same, and when files with the same identifier are intended to shadow others on the file system somewhere.