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]g> 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 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >