I understand that. My concern is specifically about the C++ implementation (which we all agree will come with standard library modules implementations).

-- Gaby


________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Bret Brown via SG15 <sg15_at_[hidden]>
Sent: Sunday, December 10, 2023 4:10:47 PM
To: SG15 <sg15_at_[hidden]>
Cc: Bret Brown <mail_at_[hidden]>
Subject: Re: [SG15] Scheduling a virtual meeting to discuss where the std module source file should live

No.

The packaging interop standards would allow toolchains and various C and C++ projects to declare requirements and other information for each others' benefit.

Technically if all projects had sufficiently detailed documentation about compilation assumptions, everyone kept up on one anothers' documentation, and everyone hardcoded all compilation flags appropriately, a package manager wouldn't be required. But from a dependency management perspective, that's a bit like eschewing algorithms and even loops because we can get the job done with goto statements.

All that being said, some toolchains have taken on a system library dependency from time to time (oneTBB, filesystem utilities, etc.), so even C++ runtimes would benefit from having explicit dependencies sometimes.

Bret



On Sun, Dec 10, 2023, 18: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]<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_[hidden]>>
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_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15