On 4/20/22 6:42 PM, Gabriel Dos Reis wrote:
>
> [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).
>
I am unaware of how anything that has been suggested so far would
interfere with the needs of other use cases. Please elaborate if you see
a conflict.
>
> 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?
>
No. Gcc's abilities demonstrate that single driver invocations are
feasible. We have decades of experience with programmers invoking
compilers in an ad-hoc manner to build one-off utilities or test
programs. I don't think this use case is in need of additional
implementation experience.
>
> * 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.
>
Thanks for sharing that. It would be useful to have more information on
that considering our upcoming plenary poll on P2465
<https://wg21.link/p2465>.

Tom.

> -- Gaby
>
> *From:* Tom Honermann <tom_at_[hidden]>
> *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