On Sun, Jun 13, 2021 at 11:21 AM Daniel Ruoso via SG15 <
sg15_at_[hidden]> wrote:

> On Sat, Jun 12, 2021, 15:31 David Blaikie <dblaikie_at_[hidden]> 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.