On Fri, Jun 3, 2022 at 7:55 PM Daniela Engert via SG15 <
sg15_at_[hidden]> wrote:

> 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;
>
Don't we already have an extremely portable format for that "metadata"? If
you make a directory with all of the header paths you want to remap and
have them contain a single `import named.module;` line, and inject that
directory to the front of your include paths, this should work out of the
box for all compilers. Why do we need a new metadata format for this?

> 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]> <sdowney_at_[hidden]>
> *Sent:* Friday, June 3, 2022 8:25 AM
> *To:* Ben Boeckel <ben.boeckel_at_[hidden]> <ben.boeckel_at_[hidden]>
> *Cc:* ISO C++ Tooling Study Group <sg15_at_[hidden]>
> <sg15_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>
> <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 listSG15_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>