Looking at the examples from using Clang (I use GCC btw.):

   clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm
   clang++ -std=c++20 use.cpp -fmodule-file=Hello=Hello.pcm Hello.pcm -o Hello.out
   ./Hello.out

Why is something which shall makes things easy and secure so complicated?

I'm used to:

    g++ -o hello hello.cpp

It can use headers. Or doesn't use headers. I doesn't matter. That's the decision of the source file. To be fair, the option -std=c++20 probably isn't necessary in future.

I recommend skimming over this issue from Meson:

https://github.com/mesonbuild/meson/issues/5024

Reading the last few blog posts from a developer of Meson, providing some insights why Meson doesn't support modules until now:

https://nibblestew.blogspot.com/

▲ delta_p_delta_x 3 days ago | parent | next [-]

> Why is something which shall makes things easy and secure so complicated? > I'm used to: > > g++ -o hello hello.cpp

That is simple, because C++ inherited C's simplistic, primitive, and unsafe compilation and abstraction model of brute-force textual inclusion. When you scale this to a large project with hundreds of thousands of translation units, every command-line invocation becomes a huge list of flag soup that plain Makefiles become intractable.

Almost all other reasonably-recent programming languages have all of the following:

- a strong coupling of dependency management, building, installation, and publishing tools

- some description of a directed acyclic graph of dependencies, whether it be requirements.txt, cargo.toml, Maven, dotnet and Nuget .csproj files, Go modules, OPAM, PowerShell gallery, and more

- some way to describe the dependencies within the source code itself

C++20 modules are a very good thing, and enforce a stronger coupling between compiler and build tool; it's no longer just some weekend project chucking flags at g++/clang++/cl.exe but analysing source code, realising it needs a, b, c, x, y, z modules, ensuring those modules are built and export the necessary symbols, and then compiling the source at hand correctly. That is what `clang-scan-deps` does: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#di...

I concede there are two problems with C++20 modules: we didn't have a working and correct compiler implementation before the paper was accepted into C++20, and secondly, the built/binary module interface specification is not fixed, so BMIs aren't (yet) portable across compilers.

The Meson developer is notorious for stirring the pot with respect to both the build system competition, and C++20 modules. The Reddit thread on his latest blog post provides a searing criticism for why he is badly mistaken: https://www.reddit.com/r/cpp/comments/1n53mpl/we_need_to_ser...

	▲	reactordev 3 days ago \| parent \| next [-]
		Universal source package management would have been better time spent. This doesn’t solve any problem that wasn’t self-inflicted. I agree on your points about having a working implementation before the paper was accepted, this is why C++ is a mess and will never be cleaned up. I love C++ but man, things like this are plenty.
	▲	ho_schi 3 days ago \| parent \| prev [-]
		Thank you.

▲ slavik81 3 days ago | parent | prev | next [-]

Your comparison is not apples to apples as you would in practice have a seperation of compilation and linking in your non-modules example. The status quo is more like:

    g++ -c -o hello.o hello.cpp
    g++ -o hello hello.o
    ./hello

With that said, the the modules command is mostly complex due to the -fmodule-file=Hello=Hello.pcm argument.

When modules were being standardized, there was a discussion on whether there should be any sort of implicit mapping between modules and files. This was rejected, so the build system must supply the information about which module is contained in which file. The result is more flexible, but also more complex and maybe less efficient.

	▲	ho_schi 3 days ago \| parent [-]
		Thanks :)

▲ Kelteseth 3 days ago | parent | prev | next [-]

> I'm used to: > g++ -o hello hello.cpp

That is an unfair comparison. Nobody uses direct compiler command line approach to compile more than a simple hello world test project.

	▲	skeezyboy 3 days ago \| parent [-]
		have you heard of linux?

▲ bluGill 3 days ago | parent | prev [-]

Because hello is so simple you don't need complicated. When you are doing something complicated though you have to accept that it is complicated. I could concatenate all 20 million lines of C++ (round number) I work with into one file and building would be as simple as your hello example - but that simple building comes at great cost (you try working with a 20 million line file, and then merging it with changes someone else made) and so I'm willing to accept more complex builds.

▲

ho_schi 3 days ago | parent [-]

Thank you. That's right and where usually issues arise and tools challenged. If the hello worlds case starts that complicated already I'm going to being careful.

I'm eager to gather info but the weak spots of headers (and macros) are obvious. Probably holding a waiting position for undefined time. At least as long Meson doesn't support them.

Wikipedia contains false info about toolings: https://en.wikipedia.org/wiki/Modules_(C%2B%2B)#Tooling_supp...

Meson doesn't support modules as of 2025-09-11.

PS: I'm into new stuff when it looks stable and the benefits are obvious. But this looks complicated and backing out of complicated stuff is painful, when necessary.

	▲	bluGill 3 days ago \| parent [-]
		> If the hello worlds case starts that complicated already I'm going to being careful. If the tool is intended for complex things I'm not sure I agree. It is nice when hello is simple, but if you can make the complex cases a little easier at the expense of making the simple things nobody does harder I don't know if I care. (note that the example needed the -o parameter to the command line - gcc doesn't have a good default... maybe it should?)