Got it. Then it looks like we have consensus with the opinion man. Let's try to ask libc++ to provide library with initializer. This may be tracked in https://github.com/llvm/llvm-project/issues/80639 <https://github.com/llvm/llvm-project/issues/80639 >
Thanks,
Chuanqi
------------------------------------------------------------------
From:Ben Boeckel <ben.boeckel_at_[hidden]>
Send Time:2024 Feb. 25 (Sun.) 22:11
To:SG15<sg15_at_[hidden]>
Cc:Chuanqi<chuanqi.xcq_at_[hidden]>
Subject:Re: [SG15] Packaging: Where should "library interface object files" live?
On Sun, Feb 18, 2024 at 10:32:22 +0800, Chuanqi Xu via SG15 wrote:
> 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.
It is the job of the build system to compile the *BMI* for consumers.
The object should be provided by the provider of the module interface.
This avoids trying to figure out which version of the initializer should
be used.
Note that if there are different ABIs for different options, it can be
done doing something like (untested, but I don't see why this couldn't
work):
```
add_library(libc++-modules-variantA OBJECT)
target_sources(libc++modules-variantA …)
target_compile_options(libc++modules-variantA PRIVATE …)
add_library(libc++-modules-variantB OBJECT)
target_sources(libc++modules-variantB …)
target_compile_options(libc++modules-variantB PRIVATE …)
target_link_libraries(libc++ PRIVATE # probably want `libc++experimental for now
 # The `PROJECT_LOCAL_INTERFACE` avoids the targets from showing up in
 # the exported bits of `libc++` itself.
 "$<PROJECT_LOCAL_INTERFACE:libc++-modules-variantA>"
 "$<PROJECT_LOCAL_INTERFACE:libc++-modules-variantB>")
```
Note that this does require the variant set to be relatively small
(which I don't see how it wouldn't be as the ABI mangling logic would be
similarly "small").
If *this* has problems with duplicate symbols, I don't see how consumers
are going to cope with it via consumer-side object generation.
Note that even when I end up supporting per-consumer-usage-hash BMIs in
CMake, I'm *still* only going to have a single object compilation to
rely upon without generating those `-variant*` targets like above…at
which point it's just easier for the compiler to provide it because it
knows the set of variants that are possible/supported. CMake providing
it means that new variants require a CMake update to use which
sounds…backwards.
--Ben