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