C++ Logo


Advanced search

Re: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

From: Tom Honermann <tom_at_[hidden]>
Date: Mon, 25 Apr 2022 12:44:11 -0400
On 4/25/22 12:18 PM, Gabriel Dos Reis wrote:
> [Tom]
>> Dependency analysis need not be required for use of a modular standard library.
> That may be true, but would the requests stop there?

Yes, I believe so. Compiler drivers don't do dependency analysis on
linked object files or static libraries today; users are required to
pass them in a suitable order. Likewise, compiler drivers do not attempt
to diagnose whether an object file is out of date with respect to the
source files used to build it.

The request is to ensure that the compiler driver support programs that
import modules from the standard library without having to require
separate compiler invocations to build BMIs for the standard library.
That's it.


> -- Gaby
> -----Original Message-----
> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
> Sent: Monday, April 25, 2022 9:16 AM
> To: Iain Sandoe <iain_at_[hidden]>; sg15_at_[hidden]
> Cc: Tom Honermann <tom_at_[hidden]>; René Ferdinand Rivera Morell via Ext <ext_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
> 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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&amp;data=05%7C01%7Cgdr%40microsoft.com%7Cd90d2b5f2c2f4d93c67808da26d6d959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865001466578054%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=I%2Fl9dmncQ3TJCL8UENmz2aRhD1FZ9i6bDiDSMfk0VUQ%3D&amp;reserved=0

Received on 2022-04-25 16:44:14