Do you know this paper: C++20 modules and Boost: deep dive?
I have a PR which show the current state and problems:
1 Like
Thanks Claus –
Thanks for the link. This is a good update on the state of things. I’d note that on the gcc side, a couple weeks ago they merged support for import std and compat into main. So it seems like we’re getting closer to real modules support.
Also, be aware that @dietmarkuehl while in Poland was hacking his cmake for beman execution. Should we try with additional repos? Not sure where we go next with this.
1 Like
I think Claus’s efforts on modules were triggered somewhat by me creating a PR with a modularized version of beman::execution26. Based on the comments and linked articles it will need some work to make the compilers happy.
That’s fair. It would be interesting to give gcc15 (aka the current trunk) a whirl because as was reported in Poland import std recently got merged.
Some Professional CMake recommendations:
from 17.4. Recommended Practices
Projects should avoid setting compiler and linker flags directly to control the
language standard used. The required flags vary from compiler to compiler, so it
is more robust, more maintainable, and more convenient to use the features that
CMake provides and allow it to populate the flags appropriately. The
CMakeLists.txt file will also more clearly express the intent, since human-
readable variables and properties are used instead of often cryptic raw compiler
and linker flags.
The simplest method for controlling language standard requirements is to use the
CMAKE_<LANG>_STANDARD, CMAKE_<LANG>_STANDARD_REQUIRED, and
CMAKE_<LANG>_EXTENSIONS variables. These can be used to set the language
standard behavior for the entire project, ensuring consistent usage across all
targets. These variables should ideally be set just after the first project()
command in the top level CMakeLists.txt file. Projects should always set all
three variables together to make clear how the language standard requirements
should be enforced, and whether compiler extensions are permitted. Omitting
CMAKE_<LANG>_STANDARD_REQUIRED or CMAKE_<LANG>_EXTENSIONS can lead to unexpected
behavior, as the defaults may not be what some developers intuitively expect.
Projects should check to see if CMAKE_<LANG>_STANDARD and
CMAKE_<LANG>_EXTENSIONS are already set before setting them to a particular
value. Some scenarios may require enforcing stronger settings than the project’s
own minimum requirements, such as it being incorporated into a larger parent
project that needs to use a higher language version. This becomes critical if
C++20 modules are used, since they require a consistent language standard to be
used throughout the build.
If using CMake 3.8 or later, compile features can be used to specify the desired
language standard on a per-target basis. The target_compile_features() command
makes this easy and clearly specifies whether such requirements are PRIVATE,
PUBLIC, or INTERFACE. The main advantage of specifying a language requirement
this way is that it can be enforced transitively on other targets via PUBLIC and
INTERFACE relationships. These requirements are also preserved when targets are
exported and installed (see Chapter 35, Installing).
If a target exports any C++20 modules, it must set a compile feature requiring C++20 or later.
Avoid the more granular compile features like cxx_override and cxx_constexpr.
They are hard to use, difficult to maintain, and serve little practical use with
most compilers in active use today. Prefer instead to use only the higher level
meta- features that specify the language standard directly, such as cxx_std_17,
c_std_11, and so on.
Avoid directly setting the <LANG>_STANDARD and <LANG>_EXTENSIONS properties on
individual targets. Express the language standard requirement with a
<lang>_std_<value> compile feature instead, or use appropriate logic at the top
of the project to check if the standard has been set by a parent project before
setting it globally for the whole build with a CMAKE_<LANG>_STANDARD variable.
This ensures a parent project can enforce a higher language standard if it needs
to. Similarly, use top level logic to conditionally set CMAKE_<LANG>_EXTENSIONS
so it applies consistently to the whole build, but still allows a parent project
to enable extensions if needed. There is no compile feature for enabling or
disabling extensions, so this can only be safely controlled with the
CMAKE_<LANG>_EXTENSIONS variable.
If policy CMP0128 is not set to NEW, the <LANG>_EXTENSIONS properties and their
associated variables often only take effect if the corresponding <LANG>_STANDARD
is also set. This is due to how compilers frequently combine the two into a
single flag. Therefore, unless using CMake 3.22 or later with policy CMP0128 set
to NEW, it is difficult to escape having to specify CMAKE_<LANG>_STANDARD, even
when compile features are used.