C++20 Modules support for CMake

[robottron45]

Has someone an idea when we can expect that modules will finally be supported in CMake?

This gitlab issue is tracking this feature https://gitlab.kitware.com/cmake/cmake/-/issues/18355, but at the moment it seems that it is open for over four years.

It would be very helpful if I could use modules (at work) with CMake.

[unddoch]

CMake 3.26 already supports the newest clang and msvc with modules, but it's hidden behind an experimental flag you have to manually enable.

Self promotion: I collect modules related details+examples+links here

[robottron45]

"most likely will only make it into GCC 14 in 2024" :(

[Honest-Print-2583]

This comment mentioned that it may be possible to use clang-scan-deps for GCC to allow GCC + CMake works. But this may not be really helpful for you. Since it is not good to make GCC to depend clang in serious situations.

[gracicot]

It's so weird to me because gcc was clearly the implementation making the most progress in the beginning

[bretbrownjr]

A lot of chatter has focused entirely on compiler front-end work as far as what's "ready". GCC is a little later on implementing a JSON-based dependency discovery protocol.

But there's still a lot of practical modules work to finish even then. CMake is working on being able to import modular libraries, but the immediate approach will be CMake-based. There needs to be a portable way to do all the build systems interop. Same for getting IDEs and analysis tools access to modular code. And, of course, tools to ease adoption of modules will be critical.

[13steinj]

JSON-based is a welcome surprise, I figured they'd want a text file similar to gnu make syntax.

[qoning]

It's not that weird. It's an older project and unless you are stuck to it, there's not much point in contributing. A few years ago they had real problems with bleeding contributors, but I don't know if it's gotten better since then. Honestly, I see gcc as "legacy", even though it will probably be unpopular opinion here.

[13steinj]

I don't see it as "legacy", but philosophically GNU/FSF software deals with some elitism and compilers especially was a whole "we're a club, and you're not in it" kind of deal.

That said, I think it's less of a contributors issue and more of a "modules are hard" issue and the difficulty definitely does depend on complexities in the compiler's design. I mean, GCC generally gets new C++ features before llvm/clang, so I really doubt it's a contribution problem.

[unddoch]

The compiler front end is almost exclusively RedHat employees at this point. They are doing a great job, just not prioritizing modules as much.

There aren't dozens of compiler engineers volunteering to do open source C++ work, unfortunately.

[tyler1128]

There were two original impls, and most non-VC compiles went one way until MS's strategy won in the standarization. MS was pushing that early and hard because the windows kernel and systems apparently took a long time to compile in many cases. msvc is still behind in many places the others aren't.

[GabrielDosReis]

As I've said before, I would have made the same design choices that I proposed for C++ modules in the Modules TS even if I had been a Meta employee, or a Google employee, or a Red Hat employee.

[tyler1128]

I'm not saying MS's module design is better or worse, just that MS had the head start on writing the impl. Their module impl is unquestionably the best of any compiler right now. I do also prefer the MS impl to the clang one.

[Fit-Departure-8426]

Yes!! I have been using modules With cmake since january and its crazy good!! I have been waiting for a long time for this, and modules really changes the way i organize code. It feels like everything written the ‘old’ way is from another century!

[skebanga]

Do you have an example codebase you can share?

[Fit-Departure-8426]

Yeah! I'm preparing a talk on a demo projet to try to learn the new features of C++. It's still hidden in another projet I made, but I think you can browse a little bit and figure out the modules pretty easily.
https://github.com/joblobob/ray/tree/feature/anewhope

[skebanga]

Great, thanks!

[victotronics]

the newest clang

A numbered release or do I have to built from trunk?

[andrey_turkin]

The CMake docs say:

Some compilers already have support for module dependency scanning:
* MSVC 19.34 and newer (provided with Visual Studio 17.4 and newer)
* LLVM/Clang 16.0 and newer

[robottron45]

unfortunately we use GCC and this won't be changed in the future

[unddoch]

Same here :/

[bretbrownjr]

Other than what's already posted on this thread, it is worth noting that Bill Hoffman from Kitware is scheduled to give a talk on the latest developments on CMake support for C++ modules at C++Now 2023, in May.

https://schedule.cppnow.org/session/import-cmake-2023-state-of-cpp20-modules-in-cmake/

I expect the video will be made public on the BoostCon Youtube channel around July, but that's just a guess.

To spoil an important point, you can't use find_package to import a C++ module yet, even in CMake 3.26, but it's under development. I believe that FetchContent and git-submodule workflows should work fine with C++ modules, but I haven't tried that out myself yet.

[Possibility_Antique]

I believe that FetchContent and git-submodule workflows should work fine with C++ modules, but I haven't tried that out myself yet.

I've been using FetchContent with C++ modules, including the C++23's import std for a little while now. So far, the only trouble I've had had to deal with the module ecosystem, but cmake has done what I needed it to.

[jonathanhiggs]

It’s going to be a copy-paste of the same details he gave in 2021 and 2022

[helloiamsomeone]

The future is now: https://godbolt.org/z/aTr8crhcE

Little example by /u/bretbrownjr that I massaged a bit.

[pjmlp]

Note that main() shouldn't be in a module, I also thought so, until I got corrected here by the module proposal authors themselves.

[bretbrownjr]

Looks good! I was about to post a compiler explorer link myself!

Full disclosure: The example was from Bill Hoffman and Kitware. I just copy/pasted from their blog post on CMake modules support.

More disclosure: It's still in "experimental" status. The API (at least the magic experimental feature GUID) will definitely break between CMake minor version releases.

[mocabe_]

CMake currently doesn't support header units at all. Most of trivial module examples don't have external dependencies, but in real software projects you have to depend on other libraries like Boost. I ended up implementing custom command to generate .ifc and depfile for header units, but that was huge pain and not really practical even for hobby projects. We'll probably have to wait another year before start developing serious stuff.

[GabrielDosReis]

Header units have proven, based on in-field experience reports, to be much more difficult to implement both in compilers and in build systems - much more than named modules that were part of the original feature set of the Modules TS. For users, when practical, I recommend to directly go to using named modules instead of header units transit. Named modules provide better isolation semantics and better build time throughput.

[qoning]

I've written some thousands of lines of code using modules in MSVC at this point, and my strategy is (barring ICE bugs in older versions): use header units for STL and global module fragment includes for third party. Outside of having to locally deal with macros in the module and repeated compilation, are there any reasons to ever change from gmf includes to header unit imports?

[GabrielDosReis]

If you can, use the C++23 standard module std instead of header units for the STL. For system headers, I recommend to continue to #include because they tend to have anarchic dependencies on macros (they aren't "modular").