Date: Mon, 25 Apr 2022 08:48:35 -0500
On Mon, Apr 25, 2022 at 8:40 AM Iain Sandoe via Ext <ext_at_[hidden]>
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.
>
> 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.
>
It's irrelevant, to this discussion, where you place such functionality if
ultimately the compiler driver is the one providing the UI that people use.
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.
>
> 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.
>
It's irrelevant, to this discussion, where you place such functionality if
ultimately the compiler driver is the one providing the UI that people use.
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
Received on 2022-04-25 13:48:47