> On 20 Apr 2022, at 21:51, Tom Honermann via SG15 <sg15_at_[hidden]> wrote:
>
> 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


There are patches in my pipeline to let clang do the same as GCC (i.e. generate the BMI “on demand” using a single invocation to make that and any required object).

Likewise to implement the ‘module mapper’ [Boris referred to this earlier in this thread] which is a way to abstract the mapping module names to on-disk BMIs (without the compiler becoming the build system)… and thus the ‘pcm-cache’ in clang terms.

Those two things will go some way towards achieving what (IIUC the general direction) the “simpler use cases” (I do agree that such a mode is useful, especially in starting out)..

Header units remain the tricky beasts; in my estimation one will need to communicate the intention that a header should be made into a HU to the driver (either by making that the default behaviour or by being explict on your compile line).

More sophisticated ideas (e.g. that the compiler front end, which I’m assuming is the only thing actually parsing the sources, should be able to trigger the build of a module on demand) - would seem to require either accepting a very restricted mapping of module to source names, or external meta-data (and that would need to be consumed by some build system, presumably on the server-side of the module mapper, even it that build system was relatively trivial).

Iain
>

> 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15