This is another larger topic (Can we distribute the BMI?) than what the opinion man wants to discuss here.
The current consensus is "we may not be able to distribute the BMIs". On the compiler's side (or clang's perspective only), the format of BMI is unstable across every versions. On the build system's side, the BMI need to change every time the compilation flags changes.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Ruki Wang <waruqi_at_[hidden]>
Send Time:2024 Feb. 18 (Sun.) 17:38
To:SG15<sg15_at_[hidden]>
Cc:Gabriel Dos Reis<gdr_at_[hidden]>; Chuanqi<chuanqi.xcq_at_[hidden]>
Subject:Re: [SG15] Packaging: Where should "library interface object files" live?
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] <mailto: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_microsoft.com <mailto:gdr_at_[hidden] >>
Send Time:2024 Feb. 18 (Sun.) 10:47
To:SG15<sg15_at_[hidden] <mailto:sg15_at_[hidden] >>
Cc:Chuanqi<chuanqi.xcq_at_alibaba-inc.com <mailto: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]socpp.org <mailto:sg15-bounces_at_[hidden] >> On Behalf Of Chuanqi Xu via SG15
Sent: Saturday, February 17, 2024 6:32 PM
To: SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden] >>
Cc: Chuanqi Xu <chuanqi.xcq_at_[hidden]nc.com <mailto: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]rg <mailto:sg15_at_[hidden] >>
Send Time:2024 Feb. 14 (Wed.) 23:41
To:SG15<sg15_at_[hidden] <mailto:sg15_at_[hidden] >>
Cc:Boris Kolpackov<boris_at_codesynthesis.com <mailto:boris_at_[hidden] >>
Subject:Re: [SG15] Packaging: Where should "library interface object files" live?
Jan Kokemüller via SG15 <sg15_at_[hidden] <mailto: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_lists.isocpp.org <mailto:SG15_at_[hidden] >
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
_______________________________________________
 SG15 mailing list
SG15_at_lists.isocpp.org <mailto:SG15_at_[hidden] >
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >

-- 
_______________________________________________
Ruki Wang