On Wed, Apr 20, 2022, 14:59 Tom Honermann <tom@honermann.net> wrote:

I'm having a hard time with the notion that the answer to "How do I
build C++ Hello World using a modularized standard library?" would be
"First, choose and install a build system that works with your compiler".

...

Some things we really need to keep at least as simple as they are today
and introducing a build system requirement doesn't do that.

I don't think that expectation is realistic. C++ Modules are
semantically several orders of magnitude more complex than what we had
with the preprocessor.

I agree modules are more complex. But that doesn't imply, for me, the need for a build system for simple cases.

Let's consider a simple example (apologies if I'm behind the times when it comes to the most current compiler options available; I'd love to be informed if there are better options available)

$ cat t.cpp
import M;
int main() {
  f_from_m();
}

$ cat m.cppm
export module M;
export void f_from_m() {}

Gcc's driver is able to produce an executable with a single invocation so long as m.cppm appears on the command line before t.cpp. Nico explicitly stated he is accepting of such a restriction and so am I. The following example successfully creates a module cache directory (gcm.cache) containing a BMI (M.gcm) that is then used to compile t.cpp and produce an executable (t). This suffices for me so long as gcc will also handle a modularized standard library (I have no idea what is planned for that).

$ gcc -x c++ -std=c++20 -fmodules-ts m.cppm t.cpp -o t

As far as I know, Clang and MSVC both require multiple compiler invocations for the above example. For Clang it is necessary to prebuild the BMI, the both reference it as a BMI and compile it.

$ clang -std=c++20 --precompile m.cppm
$ clang -std=c++20 -fmodule-file=m.pcm m.pcm t.cpp -o t

Likewise, for MSVC:

$ cl /std:c++latest /c /TP /interface m.cppm
$ cl /std:c++latest /reference m.ifc m.obj t.cpp /Fet.exe

Honestly, having to separately invoke the compiler for modules I author isn't a big deal for me, but it would be great if implementors all did as gcc does above.

However, again, the real problem cases will involve use of a modularized standard library. I can't simply build a BMI for the std module the way I can for modules I author. But implementors can and I imagine the changes needed to their drivers to do so would not be any more complicated than other things those drivers already do (and that I rely on). Those are the modules I really want to see implicitly built (if they aren't already available as prebuilt BMIs with the distribution or haven't been explicitly suppressed with a -nostdmodules or similar option).

We went from "it's fine if you just concatenate all files together and
compile to an executable" to "the module parsing context is
independent from the translation unit that consumes it".

And this is a *really good thing*. We'll finally be able to ship
reusable code that is not going to be subject to the random variations
generated by the preprocessor on the caller side.

No disagreement there. My concerns are all about deployment and usability; same as they have been since 2017.

Tom.

daniel