On 21/04/2022 06.00, Tom Honermann via Ext wrote:
>
> On 4/20/22 6:48 PM, Iain Sandoe wrote:

>> More sophisticated ideas (e.g. that the compiler front end, which I’m assuming is the only thing actually parsing the sources, should be able to trigger the build of a module on demand) - would seem to require either accepting a very restricted mapping of module to source names, or external meta-data (and that would need to be consumed by some build system, presumably on the server-side of the module mapper, even it that build system was relatively trivial).
>
> Yes. I still struggle with how a modularized standard library can fit
> into such scenarios though. Having to teach a build system about modules
> that I've authored is fine. But I shouldn't have to teach the build tool
> I'm using how to build a module for the standard library for every
> implementation, nor should the build tool have that information embedded
> in it (if it learns it from some standardized mechanism, that is
> probably ok so long as the compiler driver is still able t build it on
> demand for the simple ad-hoc interactive use cases).

Apologies for chiming in.

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? 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.
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.

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.

Jens