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]om>
Send Time:2024 Feb. 18 (Sun.) 10:47
To:SG15<sg15_at_lists.isocpp.org>
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_lists.isocpp.org>
Cc: Chuanqi Xu <chuanqi.xcq_at_[hidden]om>
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] <mailto:sg15_at_[hidden] >>
Send Time:2024 Feb. 14 (Wed.) 23:41
To:SG15<sg15_at_[hidden]rg <mailto:sg15_at_[hidden] >>
Cc:Boris Kolpackov<boris_at_[hidden] <mailto:boris_at_[hidden] >>
Subject:Re: [SG15] Packaging: Where should "library interface object files" live?
Jan Kokemüller via SG15 <sg15_at_lists.isocpp.org <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_[hidden] <mailto:SG15_at_[hidden] >
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >