On 18/05/2022 13:42, Daniel Ruoso wrote:
> Em qua., 18 de mai. de 2022 às 07:26, Stephen Kelly via SG15
> <sg15_at_[hidden]> escreveu:
>> The reason I got interested in your work there was to see what artifacts
>> you install and where. It seems that in that mode, headers are
>> installed, but I don't see anything in the install prefix that would
>> make it possible for downstreams to use it
> Discussing how libraries are distributed and how a build system can
> discover the modules provided by a library when it's installed has
> been the subject I've been focusing on for the past 10 months. We're
> still not where we need to be.


Indeed. That's one of the things I wonder about (and wrote here about 5
years ago). There is a lot more which I think is important and which
still isn't being thought about even now AFAICT.

[for example

- how will transition to modules work?

- Will large parts of libraries have to be restructured? It's still not
clear to me how any module can be used, but for example it looks like
maybe parts of fmt.cc could be split and installed so that downstreams
could generate the modules from the headers.

- Will it be possible to support both modules of some kind and headers
for a library in a transitionary phase? Note that this means without the
new buildsystem requirements brought in by an attempt to use modules -
meaning #includes containing imports are no-go. That might be possible
by splitting fmt.cc, but will that approach scale? Will all libraries
need to do similar code restructuring for (real) modules support?

- How much danger is there of bifucating the ecosystem between projects
that migrate to modules and those that don't? What could make that more
or less likely?

This is all independent of CMake. I don't know if anyone has put any
thought into those topics. Hopefully someone will do so at some point.

]


> The current work-in-progress patch in CMake will install files and
> produce the necessary information in the export file,


I assume you're referring to
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7210/commits ?


> but that has to
> be just a temporary arrangement. We will be in a very bad place if
> modules can only be used if you use the same build system as the
> library you are trying to reuse.


What are you referring to in particular? Meta-data in the CMake exports
file which informs downstreams how to consume a module and which isn't
otherwise retrievable by non-cmake tools and which your P2577 recommends
a separate file for (next to the library file)? I'm just making some
guesses at what you mean as I haven't looked into it much.


> We are nearing some consensus on that area, and while it's not going
> to be something that is applicable everywhere, we seem to be on the
> same page that whenever you can resolve a link line early enough, we
> should be able to find module metadata for that library (see
> https://wg21.link/P2577R2 ). That paper also outlines what the next
> steps in that work need to be.


At least the concept of communicating usage-requirements of even
header-only libraries is not alien in CMake (target_link_libraries is
used for header-only INTERFACE targets).

Looks like that paper acknowledges that a lot of engineering remains to
do (pushed onto toolchain developers?).

Thanks,

Stephen.


> Ultimately, this needs to be addressed with more convergence in the
> package management space, but that's an even longer conversation.
>
> daniel