Em qui., 21 de abr. de 2022 às 01:48, Jens Maurer
<Jens.Maurer_at_[hidden]> escreveu:
> Apologies for chiming in.

Contributions to this discussion are always welcome, no need to apologise.

> Why, exactly, are we contemplating that the BMIs of the standard library
> be produced on-demand, as opposed to being pre-compiled at installation
> time of the implementation?

Because the current level of interoperability of the generated binary
module interface files is substantially narrower than the surface of
ABI compatibility.

Essentially, both GCC and Clang are taking the approach that a BMI is
functionally closer to a precompiled header than it is to an output
file of a specified format (an area where MSVC is taking a radically
different approach).

> Even if the standard library is installed
> separately from the compiler, it seems most straightforward to build
> the BMIs then rather than even attempting to build them on-demand.

The problem is that, outside of a build system, there's no opportunity
for that to happen, the first time a given compiler may see a given
standard library may be when compiling a source file. This is a
problem that is reasonably solvable by a build system, since it just
needs to add the build rules for the standard library as part of the
project itself, but it becomes significantly more awkward for the
compiler operating by itself.

> After all, the .dll or .so or .a (the binary code) for the standard
> library is usually also pre-compiled and not produced on-demand.

Again, the main distinction here is that the compatibility surface of
the binary module interface files is substantially narrower than the
compatibility surface of the binary object code.

> In either case, the location of some artifacts of your standard library
> implementation (headers or BMI) needs to be made known to the compiler,
> but that's not news.

The part that is new here is that the compiler may be seeing that
standard library for the first time, so there won't be BMIs to be
used.

daniel