On Sun, Jun 13, 2021 at 11:21 AM Daniel Ruoso via SG15 <sg15@lists.isocpp.org> wrote:
On Sat, Jun 12, 2021, 15:31 David Blaikie <dblaikie@gmail.com> wrote:
Really appreciate the write up!


* Compiler-indepnedent module parsing: [...] though I think my generally understanding has been that this would still be viable, but these BMI artefacts would be local build product in some build-specific cache directory.

Exactly, which works well for "source to source" builds, however how would libblabla-dev on a Debian system provide it when the BMI is not interoperable even on different minor versions of the same compiler?


 
A distro may be entitled to assume that it's just the system compiler that is in use, and provide a blabla.bmi in a compiler specific directory. Note that it can be required that the BMI for a module match the module name. However, because they are fragile, it does mean that libblabla-dev does have to ship all of the module interface files, just as it does for headers, so that the primary module interface can be rebuilt. 
In fact, that might be a requirement in any case, because if the module interface #includes anything, it's likely that the BMI will need to be rebuilt if the include file is changed. Although the dpkg build process should keep that up to date? It's definitely a build system issue, to the extent that you want or need to be able to have any shadowing of dependencies, where there's a source build of a library and binary inclusion of depender libraries building up into an application. I know that's fragile, but it does happen.