(I'd rather not support either/not allow "header only" modules - and maybe
if build system maintainers are on board with that, maybe that'd be enough
to force library maintainers to accept that the days of this convenient
distribution workaround are gone? But, yeah, hard to know how much leverage
we have)

On Thu, May 23, 2024 at 2:35 PM Michael Spencer via SG15 <
sg15_at_[hidden]> wrote:

> On Thu, May 23, 2024 at 9:13 AM Daniel Ruoso via SG15 <
> sg15_at_[hidden]> wrote:
>
>> On Thu, May 23, 2024, 10:27 Chuanqi Xu <chuanqi.xcq_at_[hidden]>
>> wrote:
>>
>>> Yes, I personally agree. But my question actually is, there are library
>>> vendors don't buy it. For example, the libc++ developers say no explicitly.
>>>
>>
>> In that case we need a proposal on how to annotate, in the code of the
>> importable unit, that the importing unit must generate weak versions of the
>> symbols that would otherwise be provided by the library
>>
>> Trying to handle this only in the build system is a really bad idea, IMHO.
>>
>> Daniel
>>
>
> Yes, to support "interface only" modules we need some syntax attached to
> the module declaration. The next question is does that mean that only the
> compiler generated symbols are weak? Or that even strong definitions
> belonging to the module are made weak?
>
> There's also two different ways to handle this. One is that you can have
> multiple object files for an interface unit in a single program, but you
> only need one per build environment. The second is that every TU that
> imports (transitively) that interface unit needs to emit all used symbols
> into its object file. The second is terrible and brings us back to headers
> in terms of codegen cost. I'm not sure if CMake can do the first option
> though. It would be very nice to not support the second option.
>
> - Michael Spencer
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>