I don't think so. Spack works on all major OS systems. And may be I'm
wrong, but from what I remember, visual studio can also install multiple
compilers on the same system. So, the practice seems pretty common.

On Mon, 11 Dec 2023, 15:38 Gabriel Dos Reis, <gdr_at_[hidden]> wrote:

> Is the experience dependent on the platforms?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Jayesh Badwaik
> via SG15 <sg15_at_[hidden]>
> *Sent:* Monday, December 11, 2023 6:04:04 AM
> *To:* sg15_at_[hidden] <sg15_at_[hidden]>
> *Cc:* Jayesh Badwaik <jayesh_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> In my experience, it is not rare to get compiler from library package
> manager and would be an important use case. This is how a large community
> of HPC developers for example get their compilers (spack and easy build for
> example).
>
> On Mon, 11 Dec 2023, 12:26 Mathias Stearn, <redbeard0531+isocpp_at_[hidden]>
> wrote:
>
> Can we please be explicit about which kind of "package manager" is being
> referred to whenever we use that term? Are we talking about a system
> package manager (yum, apt, pacman, brew, winget etc) or a C++/library
> package manager (conan, vcpkg, cpm, etc)? This whole thread seems very
> ambiguous. I _think_ most people are talking about library package
> managers, but references to the FHS imply otherwise.
>
> Right now it is very common to get a compiler and stdlib from the system
> package manager on linux. I think it is fairly rare right now to get the
> stdlib from a library package manager, although it would be nice if it were
> simple and easy to do so. To support std modules with the status quo
> environment, we need to work with system package managers. We will probably
> need to support other modules through them eventually, but it seems a both
> harder and a bit less urgent. The opposite seems to be the case for library
> package managers, where supporting non-std modules is probably a higher
> priority than the std module.
>
> On Mon, Dec 11, 2023 at 7:27 AM Jayesh Badwaik via SG15 <
> sg15_at_[hidden]> wrote:
>
> I am not sure I get where this is coming from. The question is about being
> able to distribute and find a c++ compiler through a package manager.
>
> In order to make things uniform, the posts also want system compiler to
> provide the same CPS interface.
>
> Dependency would have been when it would have been necessary to install
> system compiler with a package manager.
>
> On Mon, 11 Dec 2023, 00:57 Gabriel Dos Reis via SG15, <
> sg15_at_[hidden]> wrote:
>
> Are we establishing a package manager as a dependency for a C++ compiler
> (which typically is also the system compiler)?
>
> -- Gaby
>
>
> ------------------------------
> *From:* SG15 <sg15-bounces_at_[hidden]> on behalf of Steve Downey
> via SG15 <sg15_at_[hidden]>
> *Sent:* Sunday, December 10, 2023 12:01:12 PM
> *To:* Mark de Wever <koraq_at_[hidden]>
> *Cc:* Steve Downey <sdowney_at_[hidden]>; ISO C++ Tooling Study Group <
> sg15_at_[hidden]>
> *Subject:* Re: [SG15] Scheduling a virtual meeting to discuss where the
> std module source file should live
>
> All the flags that make the BMI unusable make binaries unusable, in the
> general case. That standard libraries manage to avoid that is exceptional.
>
> Package managers ought to be able to do this, and an install $prefix is
> the purview of a package manager. This is, of course, slightly to the side
> of where the interface is source lives.
>
> But if a hello world project has to build the standard library, modules as
> a normal feature are DOA as a practical matter.
>
> On Sun, Dec 10, 2023, 14:44 Mark de Wever <koraq_at_[hidden]> wrote:
>
> On Sun, Dec 10, 2023 at 11:40:59AM -0500, Steve Downey wrote:
> > Does the std module use the same .a/.so as as headers?
>
> Yes this is the library shipped by the vendor.
>
> > How does that work with headers and -fno-exception, or does that have
> > to be taken care of today by the user?
>
> I'm not sure, I've no experience with systems where exceptions are
> disabled. Most of libc++'s configuration options do not modify the
> compilation flags.
>
> > The other question is if the interface goes in include/ or share/libc++
> for
> > FHS like layout, and then is it possible to deploy a commonly used BMI
> into
> > lib or libexec.
>
> We don't want to deploy BMI files. In Clang BMI's have the same
> limitations as precomiled headers; almost all compilation flags makes
> BMIs incompatible. The build system needs to build the BMIs from the
> module source files. For example, std.cppm.
>
> > FHS implicitly assumes a coherent installation within a $prefix, which
> also
> > means that ABI affecting flags are fixed, so system compilers ought to be
> > able to at least pre build the system std modules.
>
> At least for now that's not possible with Clang. I'm not sure whether it
> ever be possible. For example, changing -std=c++xx flag changes the
> exported named declarations of the module.
>
> Cheers,
> Mark
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>