[Tom]

  * 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.

MSVC’s command line requirements are influenced by having to deploy in the real world and having to deal with issues and other requirements in its deployment environment. Similarly, I suspect Clang’s command line requirements come from having to deploy Clang Modules to real world and having to deal with issues (cache invalidation being a famous one). Do you think it would make sense to wait for GCC’s deployment to survive real world scenarios unmodified before the other compilers are pressured to copy it the way it is?


  * However, again, the real problem cases will involve use of a modularized standard library.

That scenario is far more interesting to me, from the community perspective – and it is a scenario that I know the VC team has been considering solving for good.

-- Gaby

From: Tom Honermann <tom_at_honermann.net>
Sent: Wednesday, April 20, 2022 1:51 PM
To: Daniel Ruoso <daniel_at_[hidden]>
Cc: nico_at_[hidden]; René Ferdinand Rivera Morell via Ext <ext_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?

On 4/20/22 3:06 PM, Daniel Ruoso wrote:

On Wed, Apr 20, 2022, 14:59 Tom Honermann <tom_at_[hidden]><mailto: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