On Fri, Jun 3, 2022 at 10:51 AM Ben Boeckel <ben.boeckel@kitware.com> 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.