On 21/04/2022 07.58, Corentin Jabot wrote:
>
>
> On Thu, Apr 21, 2022, 07:48 Jens Maurer via SG15 <sg15_at_[hidden] <mailto: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

Thanks. This seems to be less of a concern for Nico's / Tom's sub-goal
of having a single command line be able to compile and link a few toy
modules plus a main program; not supporting arbitrary debug flags or
configuration defines for the standard library implementation might
be acceptable in that scenario.

Jens