Am 03.06.2022 um 18:44 schrieb Gabriel Dos Reis via SG15:
>
> * 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.
>
Great idea - I love this!

On a tangent, what I really miss is metadata (possibly living besides
the BMI) which is telling the compiler and build tools which header
files a (named) module is replacing such that #include
<lib/some/header.hpp> would be automatically translated into import lib;

My use case is a lib called 'asio' (by Chris Kohlhoff). I've turned the
~480 headers (plus ~40 implementation files) of 'asio' into a named
module with configurable name attachment by adding a tiny 'asio.ixx'
PMIU to the library. What I imagine is a (portable) means to teach the
compiler to divert each occurance of any of the 480 library headers to
the BMI of that library. This is possible today by 480 map instructions
fed to the compiler but that's a tedious endeavour. In this use case
there's also the same question of the identity of headers: is the
#included header.hpp the sames as the one that the BMI is built from?

> Whatever we do, I suspect we would end up with some lite version of
> “module map”.
>
Ciao
   Dani
>
> -- Gaby
>
> *From:* Steve Downey <sdowney_at_[hidden]>
> *Sent:* Friday, June 3, 2022 8:25 AM
> *To:* Ben Boeckel <ben.boeckel_at_[hidden]>
> *Cc:* ISO C++ Tooling Study Group <sg15_at_[hidden]>; 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]>
> 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.
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5