Lots of libraries value such easy quick-starts. If they want to keep the
easy quick-start, they will have to provide includable headers and they
won't be able to depend on any library that doesn't provide includable
headers.

Is there any concern that this will harm adoption of modules, or lead to
dialects of the language?

Thanks,

Stephen

On Mon 25 Apr 2022, 21:55 Gabriel Dos Reis via SG15, <sg15_at_[hidden]>
wrote:

> [Iain]
>
> - 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.
>
>
>
> I agreed that prebuilt versions that cover all imaginable combinations of
> compiler options is not practical. But, again when you look at what they
> are asking they seem to be pretty happy with some common or “golden path”
> to run small tests; and I’ve heard them say in the past “it does not need
> to be perfect”… The approach taken in MSVC (not perfect) is to default to
> some “commonly used options” and run experiments with those; that seems to
> work well for those scenarios. For large scale, serious usage, they can’t
> escape the “you’ve got to graduate to skyscrapers settings”.
>
>
>
> -- Gaby
>
>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Iain Sandoe
> via SG15
> *Sent:* Monday, April 25, 2022 1:06 PM
> *To:* sg15_at_[hidden]
> *Cc:* Iain Sandoe <iain_at_[hidden]>; Evolution Working Group mailing
> list <ext_at_[hidden]>
> *Subject:* [SG15] Fwd: [isocpp-ext] Can we expect that all C++ source
> files can have the same suffix?
>
>
>
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C5c73239181be4efcba5a08da26f70e2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865139787540827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ODwDGI4jszllv5ADXuqynHFxNY0QKUs9hBPjsgw476k%3D&reserved=0>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>