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
>