Date: Thu, 21 Apr 2022 02:05:06 -0400
> On Apr 21, 2022, at 1:48 AM, Jens Maurer <Jens.Maurer_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.
In practice, standard libraries make different symbols available based on compiler options. Symbols might vary based on standard language dialect, other dialect options, macros defined on the command line (e.g., _XOPEN_SOURCE, extra debugging support), etc… The library binary to BMI mapping need not be 1 to 1.
>
> 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.
Indeed, and for headers, the driver or an implementation provided environment setup script typically provides that.
Tom.
>
> Jens
>
> 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 practice, standard libraries make different symbols available based on compiler options. Symbols might vary based on standard language dialect, other dialect options, macros defined on the command line (e.g., _XOPEN_SOURCE, extra debugging support), etc… The library binary to BMI mapping need not be 1 to 1.
>
> 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.
Indeed, and for headers, the driver or an implementation provided environment setup script typically provides that.
Tom.
>
> Jens
Received on 2022-04-21 06:05:08