C++ Logo


Advanced search

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

From: Iain Sandoe <iain_at_[hidden]>
Date: Mon, 25 Apr 2022 21:06:06 +0100
posted from the wrong address, sorry,

> Begin forwarded message:
> From: Iain Sandoe <idsandoe_at_[hidden]>
> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
> Date: 25 April 2022 at 21:02:03 BST
> To: sg15_at_[hidden]
> Cc: Evolution Working Group mailing list <ext_at_[hidden]>, Steve Downey <sdowney_at_[hidden]>, Peter Dimov <pdimov_at_[hidden]>, Tom Honermann <tom_at_[hidden]>, Nathan Sidwell <nathan_at_[hidden]>
>> On 25 Apr 2022, at 19:43, Steve Downey via SG15 <sg15_at_[hidden]> wrote:
>> On Mon, Apr 25, 2022 at 1:55 PM Peter Dimov via Ext <ext_at_[hidden]> wrote:
>> Tom Honermann wrote:
>>> On 4/25/22 1:12 PM, Gabriel Dos Reis wrote:
>>>> [Peter]
>>>>> You are correct that the requests don't stop here.
>>>> Please, go talk to Tom 😊
>>>> Let me know when you're on the same page and what the actual request
>>>> is 😉
>>> I think Peter and I are pretty well aligned. At a minimum, we're aligned on
>>> support for the standard library.
>>> Supporting Boost as Peter suggested would require something like what the
>>> SG15 TR intends to specify or some other form of deeper integration between
>>> the compiler and the Boost installation; I'm content to categorize those
>>> integrations as falling on the sky scraper side. Like Peter, I would like for the
>>> compiler to just support those integrations, but I would also like for build
>>> systems to just never be required at all and I don't see that happening any time
>>> soon :)
>> Boost here is just an example. The `import <boost/smart_ptr.hpp>` scenario
>> concerns a header-only library that is, as today, installed somewhere in the
>> default compiler include path. #include works today, we'd ideally want import
>> to work tomorrow without additional friction, so that people can painlessly
>> migrate to using modules.
>> The Regex scenario describes a C++ compiled library that is installed in the
>> default include path and the default library path (by e.g. the system package
>> manager, although not necessarily.) The question here is would it be possible,
>> in the brave new module world, for the system package manager to install
>> some things somewhere such that `import <boost/regex.hpp>` or
>> `import boost.regex` works as well as #include works today.
>> (I'm assuming here that both libraries have been changed in whatever way
>> is needed to support modules.)
>> Possibly for the system compiler, so that the BMI for <boost/smart_ptr.hpp> could be produced upon installation of the boost library.
> With at least two of the current implementations, this is not a viable proposition - since the BMI is dependent on the compile options - therefore there is no single “BMI to install” - and the set of permutations would be too large to be practicable.
> Iain
>> However, this will also make compiler upgrades and secondary compilers a nightmare to install as the entire world gets rebuilt to generate some set of ABI compatible importable objects.
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden] <mailto:SG15_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15>

Received on 2022-04-25 20:06:08