On Sun, Feb 06, 2022 at 16:31:12 -0500, William Linkmeyer via SG15 wrote:
> See clang’s model here:
>
> https://clang.llvm.org/docs/Modules.html#module-map-language
>
> It seems simple and appropriate. The idea of using using modulemap
> files, which are found beside their accompanying header files, works
> and is neatly simple. In other words, can we propose to standardize
> something very similar to clang’s method of finding module and
> consuming modules? It is lost on me what the benefit of a BMI is,
> especially if it will eventually be superseded by packages in c++.

I don't know that "packages" is anything the ISO committee can dictate.
Even all of this BMI work is "please follow some conventions so that the
ecosystem has some sanity". That is, this work is not doing anything
that would cause an implementation to lose their "conforms to C++XY"
stamp, but rather their "works with Build System Of Choice" stamp.

> Is there anything amiss with how clang is handling modules?

The build system is no longer participating in this part of the build
graph with this model ("implicit" modules). If the compiler is going to
go and do extra work on its own:

  - The build system may not be able to track changes in the files to
    know when to rebuild if things change (depfiles probably help here,
    but this doesn't help tracking extra *outputs* from compilation).
  - If two concurrent compilations want to make module X available, how
    is it assured that they do not step on each other? What
    communication channel is used? How is build of project A and project
    B, both wanting module X, *not* going to communicate (as they should
    not care about each other)?
  - If there is some coordination, how does the compiler know a "safe"
    place to put any output such that other compilations can find it (or
    is the build system just passing a flag that says "use this for
    scratchspace")? The user's home directory is too shared, but the
    "project" directory is unknown to individual compilation commands.
  - If there is no coordination and compilers use `mkdtemp(3)` to
    isolate any intermediate work, how is this different than header
    files?

There has been discussion about the "implicit" (where the compiler does
all the hard work so that `g++ -std=c++20 use-modules.cpp -o
use-modules` Just Works™) versus "explicit" (where the build system is
aware of and coordinates module output production as part of the build
graph) build strategies[1]. The former is fine for one-off testing, but
does not scale without basically putting some kind of build graph
execution engine inside of the compiler. One *could* do `g++ -std=c++20
*.cpp -o program`, but then the trivially parallelization that C and C++
have had for so long is basically gone.

--Ben

[1]https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html