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.

Tom.

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