As stated : a full review of this 100+ mail thread can be done, and it
takes time as you know, but on a simpler path: if there's no problem as you
seem to suggest, it's not even necessary and I sincerely thank you for
making it clear that small std-lib-only programs should compile without a
build system :) This did not seem clear to me from this discussion, but I
appreciate you informing us... and saving me the effort!

Should this not be what you meant, feel free to explain of course.

Cheers!



Le lun. 25 avr. 2022 à 20:01, Gabriel Dos Reis <gdr_at_[hidden]> a écrit :

> I only asked a question that your assertion begged. It sounds like I may
> never get an answer... Oh well :-)
>
> -- Gaby
>
> ------------------------------
> *From:* Patrice Roy <patricer_at_[hidden]>
> *Sent:* Monday, April 25, 2022 4:54:40 PM
> *To:* Gabriel Dos Reis <gdr_at_[hidden]>
> *Cc:* ext_at_[hidden] <ext_at_[hidden]>; sg15_at_[hidden] <
> sg15_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>; Tom Honermann <
> tom_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
> *Subject:* Re: [isocpp-ext] [SG15] Can we expect that all C++ source
> files can have the same suffix?
>
> Well, it's actually simpler than this : if there is (as you seem to
> assert) no evidence of resistance to making Tom's std-lib-only program
> compile, then it's a done deal, and I thank you :)
>
> However, if that's not the case, then my question stands.
>
> Thanks!
>
> Le lun. 25 avr. 2022 à 19:35, Gabriel Dos Reis <gdr_at_[hidden]> a
> écrit :
>
> Yes, because it is important that we proceed from the same observed
> evidence.
>
> I am assuming you didn't make the assertion without evidence, so it
> shouldn't that long to exhibit, no?
>
> -- Gaby
>
> ------------------------------
> *From:* Patrice Roy <patricer_at_[hidden]>
> *Sent:* Monday, April 25, 2022 4:00:41 PM
> *To:* Gabriel Dos Reis <gdr_at_[hidden]>
> *Cc:* ext_at_[hidden] <ext_at_[hidden]>; sg15_at_[hidden] <
> sg15_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>; Tom Honermann <
> tom_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
> *Subject:* Re: [isocpp-ext] [SG15] Can we expect that all C++ source
> files can have the same suffix?
>
> I can do a full recension but it would take time. Do you require this
> given that we're at way more than 100 messages? It would seem just
> explaining what the problem is would be more efficient.
>
> However, should there be a need for a recension of past messages in this
> thread, it can be done. Just not tonight.
>
> Cheers!
>
> Le lun. 25 avr. 2022 à 18:54, Gabriel Dos Reis <gdr_at_[hidden]> a
> écrit :
>
> [Patrice]
>
> - […] there seems to be strong resistance from some implementers as to
> supporting Tom's "Congrats Gaby" hello-world-style program that would only
> depend on a modularized standard library (let's leave Boost and other
> well-known but non-std libraries for the moment). This resistance would be
> hard to explain to users without knowing more about the reasons for this
> resistance.
>
>
>
> To ensure that we are all talking about the same conversation, could you
> point to actual evidence of that resistance and the “some implementers”? I
> want to ensure that we are addressing real resistance.
>
>
>
> -- Gaby
>
>
>
>
>
> *From:* Ext <ext-bounces_at_[hidden]> *On Behalf Of *Patrice Roy via
> Ext
> *Sent:* Monday, April 25, 2022 3:42 PM
> *To:* sg15_at_[hidden]
> *Cc:* Patrice Roy <patricer_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>;
> Tom Honermann <tom_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>;
> Evolution Working Group mailing list <ext_at_[hidden]>
> *Subject:* Re: [isocpp-ext] [SG15] Can we expect that all C++ source
> files can have the same suffix?
>
>
>
> I think a piece from this discussion is missing : there seems to be strong
> resistance from some implementers as to supporting Tom's "Congrats Gaby"
> hello-world-style program that would only depend on a modularized standard
> library (let's leave Boost and other well-known but non-std libraries for
> the moment). This resistance would be hard to explain to users without
> knowing more about the reasons for this resistance.
>
>
>
> Would an implementer care to explain why this seems so unreasonable
> without a build system? Ideally, comparing the "old-style" (lexically
> included headers) approach to the modules-based approach.
>
>
>
> From this, it would at least be easier to explain to beginners why just
> compiling their simple, standard-library-only programs requires more
> tooling than it used to. Everyone would benefit from that knowledge, or so
> it seems to me. My users are game programmers; they are experienced, they
> use build systems, but they also compile small test code manually at the
> command line and if they cannot use modules for this, they will ask why and
> I would really like to have an answer. It's not a sand-castle vs skyscraper
> issue; it's something they will need to know to integrate it in their
> workflow.
>
>
>
> Thanks in advance!
>
>
>
>
>
> Le lun. 25 avr. 2022 à 14:44, Steve Downey via SG15 <sg15_at_[hidden]>
> a écrit :
>
>
>
>
>
> 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.
>
> 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%7C6b1e7b0893b34056ca0908da2716fe81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865276958781109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mZPd8A6gPRtmBSwUgn1O5vd5KbVgKnn3r2i4ZMr3WBQ%3D&reserved=0>
>
>