On 4/20/22 3:06 PM, Daniel Ruoso wrote:
> On Wed, Apr 20, 2022, 14:59 Tom Honermann<tom_at_[hidden]> 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