C++20 modules: the packaging and binary redistribution story

C++ modules are one of the most talked-about features introduced in C++20. However, despite available compiler implementations, modules are still not generally in use. Why is this?

When put into practice, C++ modules introduce a dependency in the order in which translation units are built: in order to build a source file that contains a module import statement, the source file that exports the name module needs to have been compiled into a binary module interface beforehand. This calls for compilers and build systems to work together to correctly derive the order in which source files need to be compiled.

The recently released CMake 3.28 introduced built-in support for C++ modules, implementing the proposals from paper P1689 which describe interaction with compilers to derive the correct build order. However, the currently available implementations have limitations and where all the source files that export module definitions should be visible by the same build.

CMake 3.28 allows using modules from imported targets, but how does this work in practice? We have become accustomed to a model where a “binary” package contains, at the very least, header files (.h/.hpp) for the compiler, and libraries (.a/.so/.lib/.dylib) for the linker. How do modules fit into this model when it comes to installing and distributing prebuilt binaries? Now more files are required on the consuming side: the compiled binary module interface, and the corresponding module interface source file. Can there be “module only” libraries, and how would these be handled?

This talk will review the current state of modules in C++, by presenting the experience currently provided by the most recent versions of the relevant tools. Special focus will be put on the potential of using C++20 modules for external library dependencies, and how far we are from being able to consume external libraries using modules.