CppCon 2019: Michael Spencer “Building Modules”

—
—
—
C++20 brings us modules, which, for the first time in 40 years, change the fundamental way in which we build code. In this talk we will cover the different ways C++ code using modules can be built, explore some actual build systems supporting modules, and explain the build performance implications of each method. Modules provide isolation between components to a level never before available in C++, and allow us to share the work of parsing interfaces between compile steps. At their core both headers and modules are represented by a dependency graph. Conceptually, headers resolve this graph by duplicating, pruning, and flattening it for each translation unit. Modules can avoid this duplication, but if they do they pay for it with serialization and synchronization overhead. The end result of this trade-off depends on the shape of your build.
—
Michael Spencer
Compiler Engineer, Apple
—

*-----*
*-----*

[AinurEru]

I was wondering how that would work when consuming a compiled/binary library (either statically or dynamically):
BMI files are the compilation artefact representing module's interfaces.
They're used by the compiler when importing modules.
Would they need to be included as side-carts when distributing a library in binary/compiled form?
If so, how would that work across compiler versions, given how there's no binary-compatability guarantee for that?