Maybe libstdc++ isn't coupled with GCC, but not all C++ compilers and C++ Standard Library implementations work that way. Some are tightly coupled, so the theory of Standard Library implementations retrieving to different compilers is nice, but a solution in search of a problem in my view.

-- Gaby


________________________________
From: Bret Brown <mail_at_[hidden]>
Sent: Monday, December 11, 2023 5:43:55 AM
To: SG15 <sg15_at_[hidden]p.org>
Cc: Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [SG15] Scheduling a virtual meeting to discuss where the std module source file should live

We need a solution that works in all dependency management workflows, including people building and installing a standard library different than the one that comes with the compiler, at least in cases where the compiler supports that. For instance, it is fairly common to use libstdc++ with a clang compiler. And a nice but important use case is for standard library developers to point released compilers at versions of the standard library they have under development. This would be analogous to pretending header and library search paths with one locally under development.

I agree that getting 'import std;' to work needs attention immediately. I would say all of the dependency management approaches we have discussed so far require support for that.

Anyway, as we have discussed so far, it seems like using a link line to locate the binary for the standard library is a common activity in all of the workflows we have discussed. Using that location to identify a file containing metadata about the std module seems like a logical next step that could work in all cases, at least for the std module. If not, examples and elaboration on concerns are important, so please share.

There are probably better approaches, but we haven't seen any offered that aren't significantly more complex or require expensive convergence in toolchain and library vendors to be useful. For instance, more expensive examples include developing a standard for how standard libraries should be installed on disk or developing a standard for invoking compilers and linkers.

Bret

On Mon, Dec 11, 2023, 06:37 Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
+1.

-- Gaby


________________________________
From: SG15 <sg15-bounces_at_[hidden]pp.org<mailto:sg15-bounces_at_[hidden]>> on behalf of Mathias Stearn via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Sent: Monday, December 11, 2023 3:26:10 AM
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]ocpp.org> <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]<mailto:redbeard0531%2Bisocpp_at_[hidden]>>
Subject: Re: [SG15] Scheduling a virtual meeting to discuss where the std module source file should live

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]<mailto: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]<mailto: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]rg<mailto:sg15-bounces_at_[hidden]>> on behalf of Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Sent: Sunday, December 10, 2023 12:01:12 PM
To: Mark de Wever <koraq_at_[hidden]<mailto:koraq_at_xs4all.nl>>
Cc: Steve Downey <sdowney_at_[hidden]<mailto:sdowney_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto: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]<mailto: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]<mailto:SG15_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15