On 4/25/22 12:22 PM, Iain Sandoe wrote:
>
>> 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.
I agree, they are surprisingly complex.
>
> 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.
I disagree, at least somewhat. Consider an invocation like 'clang++
t.cpp -o t'. The driver will search for, and attempt to link with, the
standard C++ library (-lstdc++ or -lc++) regardless of whether the
program being compiled requires is.
>
> 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”.
Thank you, that is appreciated :)
>
>>> 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.

Indeed, and I think is worth considering the possibility of the
mapper-server running within the driver (limited to support of the
standard library) unless a mapper-server is explicitly specified on the
driver command line.

Tom.

>
> Iain
>