14

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.

Boann
  • 48,794
  • 16
  • 117
  • 146
Mary Chang
  • 865
  • 6
  • 25
  • 2
    "*You can't use a module built by GCC in Clang*" You can't use the *compiled results* of a module built by GCC in Clang. – Nicol Bolas Jan 05 '20 at 14:59
  • 1
    I can't catch the problem. It is possible to distribute the precompiled module files, but it is not a must. Every user can compile them once for every compiler/version and all is fine. If the distro package delivers that precompiled files, it only saves a single compile which we currently do on every compile. Where is the benefit to deliver precompiled modules? Download/Installing may take longer as the compilation one time. – Klaus Jan 05 '20 at 15:40
  • What kind of anawer do you envision which wouldn't be pure speculation? – n. m. could be an AI Jan 05 '20 at 17:29
  • @Klaus Exactly, there's no benefit. But most applications are split into 2 part. A interface and the core lib. So people can interact with the core functionality directly. Take yosys for example. It is spitted into libyosys and yosys. If libyosys decides to use modules for faster builds, libyosys has to be built by each user. Effectively turning every package manager into AUR or emerge. – Mary Chang Jan 06 '20 at 04:03
  • @n.'pronouns'm. I was hoping a package manager developer would see the question and explain how they are solving the problem. – Mary Chang Jan 06 '20 at 04:06

2 Answers2

2

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.

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

1

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!

hedayat
  • 184
  • 1
  • 10