我们现在是2020年，C++20即将到来，以及期待已久的C++模块功能。但是在看了几场关于 CppCon 的演讲后，我发现C++模块处于一个奇怪的地方，特别是对于 Linux 包管理器(pacman、apt、emerge 等(。
据我所知，C++模块是
- 依赖于编译器
- 您不能在 Clang 中使用 GCC 构建的模块
- GCC 9.1 模块在 GCC 9.2 上不起作用
- 同一模块可以有多个不同版本
- 只要它们不导出到同一范围内
- 如果模块的依赖项更新，则需要重新生成模块
我的问题是，在所有滚动发布发行版中，编译器一直在更新，用户可能有自己的编译器版本。目前可以只更新编译器或更新libstdc++。但是对于模块，它似乎建议在编译器更新时必须更新libstdc++。
当编译器更新时，包管理器将如何处理更新，例如 STL？我不认为为每个版本的编译器构建每个版本的 STL 模块是可行的。用户不必构建自己的 STL 模块也不是一个好主意。
目前(2020 年 1 月 10 日(，模块系统更多地被认为是项目内部功能，而不是 header/lib 发行版的替代品。正如Clang社区的人所建议的那样，尽管有人提议创建一个独立于编译器的AST表单，但Clang，Gcc和Microsoft都没有计划这样做。所以你猜到了
同一模块可以有多个不同版本
是对的，并且会保持一段时间的静止。
作为包管理平台的方面，分辨率仍然未知，但由于模块系统更多的是项目内部功能，最坏的情况是"header/lib"方式仍然会发生。
附言我认为stackoverflow不是回答此类问题的好地方，如果您真的想要答案，请询问此邮件列表。
据我了解，您不会分发模块接口文件的编译输出。对于打包者来说，模块文件就像头文件一样：将模块接口文件作为源文件分发。总而言之，您将分发 lib/模块接口文件，而不是分发 lib/头文件。请注意，编译的"库"仍然存在，这与以前相同：(模块或非模块(函数的实际实现可以像以前一样转到编译的库文件。
模块接口文件真正取代了头文件：虽然它也可能包含实现，但它仍然作为源代码分发。
模块接口文件的编译形式(显然称为BMI或二进制模块接口(几乎与预编译的标头相同：您不应该分发它们！