On Thu, Apr 21, 2022, 07:48 Jens Maurer via SG15 <sg15_at_[hidden]>
wrote:

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


Implementation header files are affected by a number of compiler flags,
defines, etc, such you would need too many sets of BMI for it to be
practical of reliable.

Especially considering implementations may want to have different warning
policies, deprecation policies for their module header units.

If you just look at language modes, warnings, debug flags and configuration
defines, plus architectures, the number of set you would need to cover all
configuration is in the 10s, 100s




> 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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>