Perhaps we could distribute both the bmi and the module source at same
time, and provide some abi information in metainfo, so that if the build
tool determines that the user's compiler is compatible with the current
bmi, it can use these bmi file directly, otherwise it will fallback to
source compilation.

Chuanqi Xu via SG15 <sg15_at_[hidden]> 于2024年2月18日周日 13:19写道：

> Yeah, fully agreed. I am not saying "it is fine since we can make special
> trick to std module" but meant to say "let's review how to support the std
> module first."
>
> Thanks,
> Chuanqi
>
> ------------------------------------------------------------------
> From:Gabriel Dos Reis <gdr_at_[hidden]>
> Send Time:2024 Feb. 18 (Sun.) 10:47
> To:SG15<sg15_at_[hidden]>
> Cc:Chuanqi<chuanqi.xcq_at_[hidden]>
> Subject:RE: [SG15] Packaging: Where should "library interface object
> files" live?
>
>
> - So my understanding to the issue is: this is more specific to std
> modules instead of the general cases.
>
>
>
> The std module is where the question might have materialized, but I would
> expect the answer not to be “module std” is very special.
>
> The way I see it, the question applies to just about any module that comes
> with the system, not just the ones that are intrinsically linked to the
> compiler even though the compiler might have special needs. If when and
> libsupc++ is modularized, you might run into the same issue – I might not
> holding my breath for libsupc++ to be modularized, but you see what I am
> trying to point at.
>
>
>
> -- Gaby
>
>
>
> From: SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Chuanqi Xu via
> SG15
> *Sent:* Saturday, February 17, 2024 6:32 PM
> *To:* SG15 <sg15_at_[hidden]>
> *Cc:* Chuanqi Xu <chuanqi.xcq_at_[hidden]>
> *Subject:* Re: [SG15] Packaging: Where should "library interface object
> files" live?
>
>
>
> The reason/history why the object file of `std.cppm` of libc++ is produced
> on the consumer's side is that: when we (clang/libc++ guys) don't have an
> idea how this should happen, Ben (cmake developer) pointed out this should
> be the job of the cmake (or build systems) and the standard library is able
> to distribute the source files only.
>
>
>
> So my understanding to the issue is: this is more specific to std modules
> instead of the general cases.
>
>
>
> Thanks,
>
> Chuanqi
>
>
>
> ------------------------------------------------------------------
>
> From: SG15 <sg15_at_[hidden]>
>
> Send Time:2024 Feb. 14 (Wed.) 23:41
>
> To:SG15<sg15_at_[hidden]>
>
> Cc:Boris Kolpackov<boris_at_[hidden]>
>
> Subject:Re: [SG15] Packaging: Where should "library interface object
> files" live?
>
>
>
> Jan Kokemüller via SG15 <sg15_at_[hidden]> writes:
>
> > let's say I'm packaging a modularized C++ library "foo" that consists of
> a
> > module implementation unit "foo.cpp" and an importable module unit
> "foo.cppm".
> > Where should the "library interface object files" live? In the
> "libfoo.{a,so}"
> > I ship, or can I punt this task to the consumer, who will compile the
> > importable module unit "foo.cppm" anyway (to get the BMI's)?
> >
> > I stumbled across this issue as I was trying to consume the experimental
> libc++
> > "std" module. libc++ chose the second approach, i.e. the module
> initializer
> > symbols are not packaged up in any library artifact provided by libc++.
>
> FWIW, in build2 if the library is "binful" (has a .a/.so/.etc binary),
> then the object file that is produced when compiling the module interface
> always lives in the library binary.
>
> But a user can force a library that only contains module interfaces
> (which is analogous to header-only libraries) to be binless, in which
> case the object file is produces and linked on the consumer side along
> with the BMI. This is how we handle libc++ modules currently.
> _______________________________________________
> 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
>

-- 
_______________________________________________
Ruki Wang