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.
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.
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”.
On Fri, Jun 3, 2022 at 10:51 AM Ben Boeckel <firstname.lastname@example.org> 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@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/sg15
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
SG15 mailing list