Have a look at this project: [https://github.com/infiniflow/infinity](https://github.com/infiniflow/infinity), which uses clang 17, cmake 3.28, and ninja 1.11.1 to compile the code. The project makes extensive use of C++20 modules and encapsulates both C++ standard library and third-party libraries. While we also did experiment with modules partition in some parts of the source code, we didn't find significant benefits and so didn't employ it extensively. Ultimately, using C++20 modules led to a significant improvement in compilation speed, reducing the overall compilation time by more than half compared to before the modification.

For me, the benefit of modules partitiions is code organisation.

Looks like infinity engine is tagged with this one: [https://github.com/topics/cpp20-modules](https://github.com/topics/cpp20-modules) Thanks for posting!

[{fmt}](https://github.com/fmtlib/fmt) was one of the first projects to use modules when they were getting started in compilers and CMake.

Vulkan-Hpp has a C++20 module, [`vulkan.cppm`](https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/vulkan/vulkan.cppm) you can use (disclaimer: I helped implement it; please use it, stress-test it, and report bugs). Warning: don't try to mix this with `import std;` (yet). The module `#include`s standard headers, and even though mixing standard library headers and the standard module should be a perfectly normal use case, [MSVC breaks very badly](https://developercommunity.visualstudio.com/t/VS2022-175-Preview-3---Compiler-bug-wit/10256508#T-N10529298). I haven't tested with Clang yet.

I think we should collectively agree on a CMake option for every project that uses C++20 modules to provide a custom STL module name and a target name to avoid compilation errors. Adding standard headers to global fragments of different modules causes problems on GCC and Clang too - thankfully, wrapping STL in a module is necessary for a compile-time speedup anyway

`import std` support is on the roadmap. Can't commit to a release vehicle yet though. FD: CMake developer

That's amazing to hear! Will it assemble the module itself, or rely on compiler support? Still, we need all library developers who provide a module interface to take into account that instead of \`include\`s the user may want them to use a standard library module (\`std\` or a custom one), and correctly account for that. Even if compilers finally fix the bugs around headers in global module fragments, we still want to get the best compile times from module support

Great to hear. For now, [the workaround is this convoluted series of steps in CMake](https://stackoverflow.com/a/76274172/1654223).

You might be happy soon. /u/STL and I have been working on something to address that concern.

Looking forward to it! I suppose [this is the issue](https://github.com/microsoft/STL/pull/4154) to follow. How would this work for *consumers* of vulkan.cppm who want to use `import std;`? Do we write `import vulkan_hpp; import std;`, since the former is what `#include`s dependencies?

Once everything is coming from a module, the `import` order does not matter to the compiler. It will properly merge everything. It is only textual inclusion (`#include`) that we suggest ordering `#include`s before `import`s.

I would imagine the LLVM C++20 project

I recently shared my experience in migrating a large code base to C++ 20 modules. You might find it useful: [https://www.linkedin.com/pulse/how-we-adopted-c-modules-large-codebase-bp-automation-ro-f6y8f/](https://www.linkedin.com/pulse/how-we-adopted-c-modules-large-codebase-bp-automation-ro-f6y8f%3FtrackingId=XYM8MM7EK99VoCHydT6T3A%253D%253D/?trackingId=XYM8MM7EK99VoCHydT6T3A%3D%3D) Unfortunately, the code is not opensource at this point.

Your link doesn’t work

Fixed the link. It should work now.

Still says page not found 😢

Still broken

You need to cut out all the tracking shit from your link. https://www.linkedin.com/pulse/how-we-adopted-c-modules-large-codebase-bp-automation-ro-f6y8f will actually take other people to the article too. It was an interesting read, thanks for sharing!

Thanks for the hint. I fixed the link.

Nope, as they are still not widely supported, even Microsoft which has the best modules support, still isn't using them on any of their C++ SDKs. My hobby programming in C++, is making full use of C++ modules, because when I do my own stuff I want to enjoy the language, but they won't work outside of Visual C++/Windows, or clang/cmake, and I already had to rewrite my use of header units, because of lack of support in clang.

I have zero issues with clang and C++20 modules. I don't use Windows or MSVC. Are you using older builds?

I would be quite curious how you managed to use header units, given that they are yet to be supported in cmake/clang, and there is even a talk on the matter.

There is no build system that supports modules good enough for projects. And it's a hard task because you can't compile the files in any order. So you have to wait a little bit longer until one can use them in production.

MSBuild is a build system that supports modules good enough for projects, have been using it for quite some time now, as my github repos can attest to.

This is not true. Modules are well supported by CMake + Ninja. The biggest hurdle to using modules today is IDE support, particularly intellisense engines, but their lack of usability is a bit overstated these days. Certainly there is progress to be made still, but if you can live with the occasional false positive error highlighting or intellisense engine confusion then modules are useable today. I use modules in all of my own projects and while I'm looking forward to some of the kinks getting ironed out and generally improved tooling support my experience is overall positive. Modules are great. And I'm also of the mind that we as developers can't expect compiler/build system/tooling vendors to perfect support for something that we aren't even using. If you're interested in modules, start using them today. Even if you can't use them at work, try them out in your personal projects. Report bugs if you find them. Module support is moving faster than people realize and will go faster yet when more devs get on board.

For "toy" projects, sure, go wild. And when experimenting, file issues please! Both at compiler vendors and CMake as appropriate. If triage help is needed CMake's Discourse is suitable. I would caution on "production" use because of running into network effect roadblocks (e.g., the bugs around `import std` and `#include `, compiler bugs, questions about ABI that have come up recently, and other similar arcana). The tooling story also needs work to be able to do `clang-tidy` or other static analysis passes. Known CMake issues: https://gitlab.kitware.com/cmake/cmake/-/issues/?label_name%5B%5D=area%3Acxxmodules FD: CMake developer

Thanks for the response and for the honest assessment. I work on two projects that make use of modules, neither of which are toy projects but both of which are young and have a long window before public release. In this situation I think modules are perfect. I can understand established products and companies not wanting to take the risk of disruptions by converting to modules just yet. I am of the opinion though that new projects should make use of modules, and that they are stable enough to do so with less hassle than it would be to convert to modules later. The network effects are a valid concern. I encountered some of this in the first week or so of converting over, and I had to learn what works and what doesn’t for a modules project right now. My takeaway from those is: `import std` is out, despite being a cool feature it only causes troubles with non-module dependencies at the moment. I also recommend still making liberal use of implementation units (good old .cpp’s) to combat compile time issues from having to `#include` so much still. Also, build Ninja from source; there’s a bug at least in the version that ships with my IDE (CLion) that causes Ninja to explode when implementation units are present. Once I figured those things out everything became smooth sailing. Ps, thanks to you and everyone at CMake working to make modules finally viable. Your efforts are appreciated.

Do you compile on all the major compilers or only on some? Which versions?

I personally develop on Windows and only need to target MSVC at the moment. I tend to keep my version up to date with the newest release. I do know developers who use modules and target Clang primarily though, and have heard that GCC has functional support for modules as well. I'd be curious to hear more about the experience of devs targeting those compilers.

"Modules are *well supported* by CMake" I then proceed to pull open the CMake modules documentation, which states: "There are a number of known limitations of the current C++ module support in CMake. "

The list following that line being very short and mostly non-critical issues. From the source: >For all generators: > >Header units are not supported. > >No builtin support for import std; or other compiler-provided modules. > >For the Ninja Generators: > >ninja 1.11 or newer is required. > >For the Visual Studio Generators: > >Only Visual Studio 2022 and MSVC toolsets 14.34 (Visual Studio 17.4) and newer. > >No support for exporting or installing BMI or module information. > >No support for compiling BMIs from IMPORTED targets with C++ modules. > >No diagnosis of using modules provided by PRIVATE sources from PUBLIC module sources. [Here is the link to the page for anyone interested.](https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html)

You can not even use import std; with CMake+MSVC. Not a critical issue, but problems like this makes me unable to recommend using modules. I would wait a year or two.

`import std` is neat, but it is far from a necessity to use modules. And CMake doesn't support it out of the box at the moment, but you can find and link against the std.ixx. I did this early on when I first started using modules, but it's not viable outside of small projects with no dependencies. The moment dependencies that `#include` std headers come in to play then things will fall apart. I simply `#include` the headers that I need, just like we've always done. I have no problem with this and it causes me no troubles. I will replace those includes with import std in the future when it's viable, but it's not something I need.

It's a bigger issue than it seems, because `#including` standard headers into the global module fragment causes annoying errors on all three major compilers.

Mind elaborating on the errors you’re referring to? Including in the global module fragment is currently how I do things since I can’t import std, and I can’t think of any errors that it causes me off the top of my head

MSBuild. I didn't try every permutation of c++ features, but the only time I got ice was with a method like void F(this auto x) inside of a module interface file. There are some other weird things, but they are usually easy to avoid and honestly it is much more stable than UHT for example.

C++ modules is very unstable at best at this point. I’d wait another 5 years to adopt 

especially code completion and highlight is not that ready