Hi Daniel,
> I don't know what to say. The module is a part of the interface, therefore it needs to have the objects made available to the user.
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. And there are also vulkan-hpp: https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/CMakeLists.txt <https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/CMakeLists.txt > and magic_enum (which was a header only library, so it makes sense it doesn't want to provide a binary library) https://github.com/Neargye/magic_enum/blob/master/CMakeLists.txt <https://github.com/Neargye/magic_enum/blob/master/CMakeLists.txt >
> Requiring each project to build their own versions of the module objects is, pardon my bluntness, nonsensical.
Then, given that there already such practices and now we're designing module distribution metadata, should we add fields in the metadata to indicate how the object counter part will be provided.
My point is, whether the format will be general enough. I fully agree with the idea that the library should ship the object part of a module interface. But maybe we can't **require** such things. Otherwise the format may only not be avaiable to describe such projects.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Daniel Ruoso <daniel_at_[hidden]>
Send Time:2024 May. 23 (Thu.) 21:43
To:Chuanqi<chuanqi.xcq_at_[hidden]>
Cc:SG15<sg15_at_[hidden]>
Subject:Re: [isocpp-sg15] Module metadata distributed with pre-built libraries
On Wed, May 22, 2024, 23:46 Chuanqi Xu <chuanqi.xcq_at_[hidden] <mailto:chuanqi.xcq_at_[hidden] >> wrote:
Do the format need to specify whether or not the build system should build the object part of modules?
I think the conversation we had on Tokyo setting the expectation that there's always exactly one object built for a module implies that the library *has* to ship that object.
Although previously we though the object part of modules should be part of that library, the libc++ devs seem not like the idea. Further, it might be understandable that other libraries don't want the object parts of the modules "muddy" their libraries.
I don't know what to say. The module is a part of the interface, therefore it needs to have the objects made available to the user.
Requiring each project to build their own versions of the module objects is, pardon my bluntness, nonsensical.
Daniel