# Anyone using C++ modules with CMake?
**URL:** https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638
**Category:** Usage
**Created:** [October 10, 2022, 10:49pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638 "2022-10-10T22:49:37Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@RobN](https://discourse.cmake.org/u/RobN)
#### Post date: [October 10, 2022, 10:49pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/1 "2022-10-10T22:49:37Z")
I’m using Clang 15 and it looks like it has a fair amount C++ modules support. But what’s the status in CMake. Is it usable?
~ Rob
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 11, 2022, 2:15pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/2 "2022-10-11T14:15:04Z")
It’s in progress. Support is currently experimental. See:
- [Experimental docs](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst)
- [Examples used in the test suite](https://gitlab.kitware.com/cmake/cmake/-/tree/master/Tests/RunCMake/CXXModules/examples)
- [Issues with the `area:cxxmodules` label](https://gitlab.kitware.com/cmake/cmake/-/issues?label_name%5B%5D=area%3Acxxmodules)
---
### Author:  [@hinell](https://discourse.cmake.org/u/hinell)
#### Post date: [October 17, 2022, 5:57pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/3 "2022-10-17T17:57:49Z")
I think it’s practically unusable cause it doesn’t deliver sane encapsulation of the imported symbols and they are dangling inside a global namespace. The modules don’t do the most important thing they do in most programming languages: provide a way to refer imported symbols by an alias and import them from files.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 17, 2022, 6:25pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/4 "2022-10-17T18:25:23Z")
This is not relevant to CMake’s support of C++ modules. While they’re not everything I’d have wanted either, it’s what C++ got.
---
### Author:  [@hinell](https://discourse.cmake.org/u/hinell)
#### Post date: [October 17, 2022, 6:32pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/5 "2022-10-17T18:32:09Z")
It’s relevant in the sense that the support in CMake is not warranted as support across vendors is basically in a raw state.
---
### Author:  [@RobN](https://discourse.cmake.org/u/RobN)
#### Post date: [October 17, 2022, 6:36pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/6 "2022-10-17T18:36:16Z")
> [@hinell](#):
>
> The modules don’t do the most important thing they do in most programming languages: provide a way to refer imported symbols by an alias and import them from files.
Is this true of C++ modules as implemented today, or C++ modules even in their final state?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 17, 2022, 6:59pm UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/7 "2022-10-17T18:59:06Z")
> [@hinell](#):
>
> It’s relevant in the sense that the support in CMake is not warranted as support across vendors is basically in a raw state.
I’m not sure how else you expect the chicken-and-egg problem to be broken here without build systems supporting C++ modules even as they are being developed. They’re certainly too complicated for anything that used to do `g++ *.cpp -lsome_other_lib` to handle at least.
> [@RobN](#):
>
> Is this true of C++ modules as implemented today, or C++ modules even in their final state?
I don’t know that C++ modules will ever be “in [a] final state” unless the C++ committee ever shuts down. But `import foo;` has absolutely zero relation to what is made available through the `foo` name. It could import Boost symbols, a reimplementation of the standard library (under some non-`std` namespace of course), or nothing. The `foo` name of the module is not referenceable anywhere other than an `import` line. It has no methods, the preprocessor is ignorant, and you cannot do `export foo.*;` to export `foo`’s symbols yourself.
Basically, you can think of named modules being a bag of symbols that have a given label (the name) and can be looked up by that name, but once you import it, the label is gone.
(I think this is what is being complained about here at least.)
---
### Author:  [@RobN](https://discourse.cmake.org/u/RobN)
#### Post date: [October 18, 2022, 4:10am UTC](https://discourse.cmake.org/t/anyone-using-c-modules-with-cmake/6638/8 "2022-10-18T04:10:09Z")
> [@ben.boeckel](#):
>
> It’s in progress. Support is currently experimental. See:
>
> - [Experimental docs](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst)
> - [Examples used in the test suite](https://gitlab.kitware.com/cmake/cmake/-/tree/master/Tests/RunCMake/CXXModules/examples)
> - [Issues with the `area:cxxmodules` label](https://gitlab.kitware.com/cmake/cmake/-/issues?label_name%5B%5D=area%3Acxxmodules)
I’d like to give it a shot. I tried copying [this simple example](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Tests/RunCMake/CXXModules/examples/simple/CMakeLists.txt), but I’m getting:
> CMake Error at MyApp/CMakeLists.txt:21 (target\_sources):
> target\_sources File set TYPE may only be “HEADERS”
I have …
```plaintext
...
set(CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API 3c375311-a3c9-4396-a187-3227ef642046)
...
add_executable(Foo MACOSX_BUNDLE)
target_sources(Foo
PRIVATE
FILE_SET CXX_MODULES
BASE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}"
FILES
Foo/main.cc Foo/App/AppDelegate.cc)
```
Mmm…