> On 25 Apr 2022, at 17:15, Tom Honermann <tom_at_[hidden]> wrote:
>
> On 4/25/22 9:40 AM, Iain Sandoe wrote:
>>
>>> On 25 Apr 2022, at 14:36, Peter Dimov via SG15 <sg15_at_[hidden]> wrote:
>>>
>>> Daniel Ruoso wrote:
>>>> Em seg., 25 de abr. de 2022 às 09:06, Peter Dimov <pdimov_at_[hidden]>
>>>> escreveu:
>>>>> All that's also true without modules, but we still make it possible for
>>>>> c++ hello.cc
>>>>> to produce a working hello world executable
>>>> FWIW, I'd be on board with a proposal for a "trivial build system"
>>>> interface to be supported in various toolchains with the same command line
>>>> and options. Maybe we can even convince our toolchain vendors to include
>>>> such a tool. I think focusing on the compiler executable specifically as the one
>>>> having to implement that is a mistake.
>>> That's also something we already have, because c++ in the above is
>>> typically the "compiler driver" executable, which invokes the compiler front
>>> end, the compiler back end, [the assembler], and the linker.
>> Agreed, but the driver typically makes decisions about forming commands
>> based on flags provided and suffixes to files.
>>
>> (at least for the two I am familiar with) it does not do dependency analysis
>> nor does it have any need to parse the source.
>
> Dependency analysis need not be required for use of a modular standard library.
>
> I don't think anyone is asking for the driver to support arbitrary modules. The request is that it be able to handle the standard library.

My comment was in response to the “we already have a trivial build system in the driver”;
I was not intending to be philosophical (I completely agree that to the end user it makes no difference where the functionality resides - just how it looks)

However, for the drivers with which I am familiar, they are doing a very complex job of managing the interactions between all the various flags, source code dasignations and all the other stuff that the standard does not describe.

That job is quite orthogonal to the one of deciding how to find a BMI for <vector> … especially, since to date the driver would never parse any source code to see that it even needed to consider vector.

So, please read my comment as an engineering “what we have now is far from what we would need, it’s not a done deal”.

>> I suspect it would be better to place the ‘trivial build’ system as a separate
>> entity (perhaps invoked by the driver) rather than upgunning the driver to
>> have those properties.

Nathan’s mapper-server along with the module-mapper interface can be seen as such a facility.

Iain