# C++ 20 Modules Update
**URL:** https://discourse.cmake.org/t/c-20-modules-update/7330
**Category:** Development
**Created:** [January 26, 2023, 8:20pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330 "2023-01-26T20:20:17Z")
**Posts on this page:** 20
**Page:** 5
### Author:  [@ComicSansMS](https://discourse.cmake.org/u/ComicSansMS)
#### Post date: [June 1, 2023, 7:09am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/84 "2023-06-01T07:09:09Z")
FYI, I [opened a feature request with MSVC](https://developercommunity.visualstudio.com/t/Allow-selecting-the-public-modules-on-a-/10380361) to add support for a file-based mechanism for specifying the list of public modules for DLLs.
> [@craig.scott](#):
>
> Would such a change mean that a project would not be able to define any modules that are kept private to the project?
This is already the status quo for static libraries on MSVC. And from what I can see there doesn’t seem to be a mechanism in MSVC’s static library toolchain that allows to restrict this, so Ben’s suggestion to enforce it on the CMake level instead may be the only option here.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 1, 2023, 12:32pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/85 "2023-06-01T12:32:53Z")
Note that we need the mechanism regardless because we need to write install and export bits for these modules. While “can use from elsewhere” may be a possible IDE thing, writing out these files is certainly outside the scope.
---
### Author:  [@Zingam](https://discourse.cmake.org/u/Zingam)
#### Post date: [August 28, 2023, 5:31am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/86 "2023-08-28T05:31:09Z")
I followed these
- [Standard C++ Modules — Clang 18.0.0git documentation](https://clang.llvm.org/docs/StandardCPlusPlusModules.html#module-and-module-unit)
- [Modules (since C++20) - cppreference.com](https://en.cppreference.com/w/cpp/language/modules)
to create:
- Module interface partition unit.
- Internal module partition unit.
So I have:
`Details.cpp` with `module RToolBox:MetaInfo.Details;`
`Details.cppm` with `export module RToolBox:MetaInfo.Details;`
When building I get the following error:
> [build] ninja: build stopped: multiple rules generate CMakeFiles/RToolBox.dir/Debug/RToolBox-MetaInfo.Details.ifc.
I add them like that:
```cmake
target_sources("${PROJECT_NAME}"
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES
FILES
"src/MetaInfo/Details.cpp"
"src/MetaInfo/Details.cppm"
```
---
### Author:  [@Zingam](https://discourse.cmake.org/u/Zingam)
#### Post date: [August 28, 2023, 6:00am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/87 "2023-08-28T06:00:15Z")
> [@Zingam](#):
>
> ```cmake
> target_sources("${PROJECT_NAME}"
> PUBLIC
> FILE_SET cxx_modules TYPE CXX_MODULES
> FILES
> "src/MetaInfo/Details.cpp"
> "src/MetaInfo/Details.cppm"
>
> ```
It looks like not all of the proposal is implemented (or I do not understand it yet):
- [[API Design][C++ Modules]: Source listings and interface properties](https://discourse.cmake.org/t/api-design-c-modules-source-listings-and-interface-properties/5389)
- [https://cmake.org/cmake/help/latest/command/target\_sources.html#target-sources](https://cmake.org/cmake/help/latest/command/target_sources.html#target-sources)
---
### Author:  [@DanielaE](https://discourse.cmake.org/u/DanielaE)
#### Post date: [August 28, 2023, 7:02am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/88 "2023-08-28T07:02:31Z")
Your code is invalid: you have two TUs in module ‘RToolBox’ with the same partition name ‘MetaInfo.Details’. [A named module shall not contain multiple module partitions with the same module-partition](http://eel.is/c++draft/module#unit-3)
---
### Author:  [@Zingam](https://discourse.cmake.org/u/Zingam)
#### Post date: [August 28, 2023, 2:54pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/89 "2023-08-28T14:54:04Z")
@DanielaE Thank you for pointing me to the specification. I looked everywhere but there (I assumed it going to be too techincal). This example tied up the loose ends.
I got confused that partition implementation TUs are a thing.
---
### Author:  [@Zingam](https://discourse.cmake.org/u/Zingam)
#### Post date: [August 29, 2023, 11:39am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/90 "2023-08-29T11:39:31Z")
While trying to understand modules. I watched this talk (entirely by coincidence - noticed a YouTube message a few days ago): [https://www.youtube.com/watch?v=DJTEUFRslbI](https://www.youtube.com/watch?v=DJTEUFRslbI)
So if I understand correctly we are supposed to compile `std` on our own for every project.
Will in that case make sense for the build system (in our case CMake) to provide standard facilities to automate this task? This is something I haven’t yet seen discussed anywhere else but in the talk in the link.
---
### Author:  [@DanielaE](https://discourse.cmake.org/u/DanielaE)
#### Post date: [August 29, 2023, 11:45am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/91 "2023-08-29T11:45:33Z")
Ah, **that** latest talk of mine 😊
Your proposal makes sense. MSBuild does it since msvc 17.6 (or .5? I can’t remember).
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 29, 2023, 1:45pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/92 "2023-08-29T13:45:26Z")
> [@Zingam](#):
>
> Will in that case make sense for the build system (in our case CMake) to provide standard facilities to automate this task?
Yes. The idea is that we inspect information from the compiler about the standard library in use and make a target like `CMake::CXX23` that provides the modules. It would be implicitly linked by anything using `cxx_std_23`. Note that adding flags like `-std=c++23` not through a CMake-recognized standard-setting mechanism would likely not be something we notice.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 29, 2023, 2:14pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/93 "2023-08-29T14:14:37Z")
> [@Zingam](#):
>
> ```auto
> target_sources("${PROJECT_NAME}"
> PUBLIC
> FILE_SET cxx_modules TYPE CXX_MODULES
> FILES
> "src/MetaInfo/Details.cpp"
> "src/MetaInfo/Details.cppm"
>
> ```
The `.cpp` file is not a module file (i.e., it does not produce a BMI). It is instead an implementation unit of a module; it does not belong in `CXX_MODULES` filesets.
---
### Author:  [@DanielaE](https://discourse.cmake.org/u/DanielaE)
#### Post date: [August 29, 2023, 3:33pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/94 "2023-08-29T15:33:10Z")
> [@ben.boeckel](#):
>
> It is instead an implementation unit of a module
Wat?
Sorry, but a module TU with a partition name will _always_ create a BMI because it is either a module interface partition (that contributes to the externally visible module interface) or an internal partition (that may or may not contribute to the externally reachable entitities of a module).
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 29, 2023, 4:26pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/95 "2023-08-29T16:26:10Z")
Oh, that `:` hid itself very well (I missed that `.` can be in the partition name too…). Anyways, MSVC _does_ have an extension to allow such things (“implementation of partition” units; these don’t officially exist and should instead just use the module name only). _Those_ files belong in the normal sources list.
---
### Author:  [@DanielaE](https://discourse.cmake.org/u/DanielaE)
#### Post date: [August 29, 2023, 4:34pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/96 "2023-08-29T16:34:32Z")
We don’t like “extensions”, do we? 😱
But you’re right: module implementation units (the ones without a partition name) belong into the regular FILES section because they don’t create BMIs.
BTW: I’m experimenting with CMake 3.27 right now. Unfortunately it broke my (admittedly very brittle) “implementation” of ‘compiling header units with CMake workaround’ that worked in 3.26.
---
### Author:  [@Zingam](https://discourse.cmake.org/u/Zingam)
#### Post date: [August 30, 2023, 5:07pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/97 "2023-08-30T17:07:44Z")
> [@ben.boeckel](#):
>
> > [@Zingam](#):
> >
> > Will in that case make sense for the build system (in our case CMake) to provide standard facilities to automate this task?
>
> Yes. The idea is that we inspect information from the compiler about the standard library in use and make a target like `CMake::CXX23` that provides the modules. It would be implicitly linked by anything using `cxx_std_23`. Note that adding flags like `-std=c++23` not through a CMake-recognized standard-setting mechanism would likely not be something we notice.
Sounds good. All three vendors have agreed to support STD modules in C++20 mode as an extension. CMake should probably do too: [Supporting `import std;` in C++20 · Issue #3945 · microsoft/STL · GitHub](https://github.com/microsoft/STL/issues/3945)
---
### Author:  [@koplas](https://discourse.cmake.org/u/koplas)
#### Post date: [September 5, 2023, 12:19pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/98 "2023-09-05T12:19:16Z")
The issue @RobN created got closed. I got the impression that this is considered a problem of the build tools and not clang itself. So I would like to ask if there are any workarounds for this issue. Currently touching a single file can result in cascade of recompilations.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 6, 2023, 11:34am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/99 "2023-09-06T11:34:54Z")
There’s some work that would be needed to do this, but it isn’t required to make modules work, hence it not being done right now. The basic requirement is that the collator has the compiler write the BMI to a temporary file and then communicate with a command in the same rule that does `cmake -E copy_if_different` to the real location. How exactly this gets communicated needs worked out though.
---
### Author:  [@Przemek\_Koziol](https://discourse.cmake.org/u/Przemek_Koziol)
#### Post date: [September 28, 2023, 11:36am UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/100 "2023-09-28T11:36:30Z")
Are header units supported in cmake 3.27?
I am getting an error:
error: header file (aka ‘/usr/bin/…/lib/gcc/x86\_64-linux-gnu/13/…/…/…/…/include/c++/13/vector’) cannot be imported because it is not known to be a header unit
---
### Author:  [@DanielaE](https://discourse.cmake.org/u/DanielaE)
#### Post date: [September 28, 2023, 12:13pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/101 "2023-09-28T12:13:17Z")
Unfortunately no, they are not (yet).
---
### Author:  [@Przemek\_Koziol](https://discourse.cmake.org/u/Przemek_Koziol)
#### Post date: [September 28, 2023, 1:15pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/102 "2023-09-28T13:15:45Z")
I also tried using gcc - I compiled the following revision
ommit 024f135a1e9b8f8e102960357cae6e99e1dbe6eb
Author: Ben Boeckel [ben.boeckel@kitware.com](mailto:ben.boeckel@kitware.com)
Date: Fri Sep 1 09:04:02 2023 -0400
```
p1689r5: initial support
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the output. Currently named
`p1689r5`.
- `-fdeps-file=` specifies the path to the file to write the format to.
- `-fdeps-target=` specifies the `.o` that will be written for the TU
that is scanned. This is required so that the build system can
correlate the dependency output with the actual compilation that will
occur.
```
The error is now:
[build] /usr/local/bin/g++ -DENABLE\_TESTS -I/home/pkoziol/repos/aoc22/src/…/include/aoc22 -isystem /home/pkoziol/repos/aoc22/tests/Catch2/src/catch2/… -isystem /home/pkoziol/repos/aoc22/builds/dev\_ninja\_gcc/tests/Catch2/generated-includes -g -std=c++20 -Wall -Wextra -Wpedantic -Werror -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wmisleading-indentation -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wimplicit-fallthrough -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast /home/pkoziol/repos/aoc22/imports/aoc22/day2.cppm -MT src/CMakeFiles/aoc22.dir/ **/imports/aoc22/day2.cppm.o.ddi -MD -MF src/CMakeFiles/aoc22.dir/** /imports/aoc22/day2.cppm.o.ddi.d -fdeps-file=src/CMakeFiles/aoc22.dir/ **/imports/aoc22/day2.cppm.o.ddi -fdeps-target=src/CMakeFiles/aoc22.dir/** /imports/aoc22/day2.cppm.o
[build] /usr/bin/ld:/home/pkoziol/repos/aoc22/imports/aoc22/day2.cppm: file format not recognized; treating as linker script
(Note the compiler flags mentioned in [https://www.kitware.com/import-cmake-c20-modules/](https://www.kitware.com/import-cmake-c20-modules/) are outdated)
Should I use “-x c++” option? Clang doesn’t have problem with this.
Also,I am setting set(CMAKE\_CXX\_EXTENSIONS OFF)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [September 28, 2023, 2:12pm UTC](https://discourse.cmake.org/t/c-20-modules-update/7330/103 "2023-09-28T14:12:15Z")
Header units are not supported at all in CMake right now. What is the content of `day2.cppm`?
It looks like GCC is not recognizing the extension; does it work if you use `.cpp` or some other typical file extension?
[Previous page](https://discourse.cmake.org/t/c-20-modules-update/7330.md?page=4)
[Next page](https://discourse.cmake.org/t/c-20-modules-update/7330.md?page=6)