How would Linux package managers handle C++20 modules?

Question

We are in 2020 now and C++20 is coming, along with the long-awaited C++ modules feature. But after watching a few talks on CppCon I find C++ modules are in a weird place, especially for Linux package managers (pacman, apt, emerge, etc...)

From what I have learned, C++ modules are

1. Compiler dependent
   • You can't use a module built by GCC in Clang
   • GCC 9.1 modules won't work on GCC 9.2
2. You can have many different versions of the same module
   • As long as they are not exported into the same scope
3. You need to rebuild a module if its dependencies update

My problem is, in all rolling-release distros compilers get updated all the time and the user might have their own compiler build. Currently one can just update the compiler or also update libstdc++ . But with modules, it seems to suggest libstdc++ has to be updated when the compiler updates.

How would the package manager handle updating, for example, the STL when the compiler updates? I don't think building every version of the STL module for every version of the compiler is feasible. Nor is the user having to build their own STL module a good idea.

Answer 1

For now(Jan/10/2020), the module system is considered more of a project-inner feature rather than a replacement of header/lib distribution. As guys from Clang community suggest, although there's a proposal to create a compiler independent AST form, neither Clang nor Gcc nor Microsoft have plan to do this. So you guess about

You can have many different versions of the same module

is right and will keep still for some time.

As the aspect of package management platform, the resolution is still unknown, but since module system is more of a project-inner feature, the worst case is that the "header/lib" way will still take place.

PS I think stackoverflow is not a good place for questions like these, if you really want an answer, ask to this mail list.

Answer 2

From what I've understood, you don't distribute compiled output of a module interface file. To packagers, module files are just like header files: you distribute the module interface file as source. To sum it up, instead of distributing lib/header files, you'll distribute lib/module interface files. Note that the compiled 'library' is still there, which is same as before: the actual implementation of (module or non-module) functions can go to the compiled library file, as before.

Module interface file really replaces header files: while it may contain implementation too, it is still distributed as source.

And the compiled form of module interface file (apparently called BMI or binary module interface), is almost identical to pre-compiled headers: you should not distribute them!