Stephan, you bring up a lot of interesting work to be done.

I don't see that work as orthogonal to the discussions we're having, though.

I think having some minimal standards around build system and package
system support for C++ modules will be necessary (though not sufficient!)
to answer the work you've identified. I think a lot of us have a similar
backlog in our heads, at least.

At any rate, I don't see publicly available libraries shipping modular
interfaces if they are nontrivial for users to consume. At a minimum, I
predict we'll need to be able to hand-write CMake modules that define
IMPORTED modular library targets. But, as Daniel identifies, that doesn't
help in all cases. As far as I know, everyone has at least some libraries
they use that do not provide CMake modules; I believe that's part of the
reason CMake ships with some precanned modules for sufficiently popular
dependencies like FindProtobuf.cmake.

I don't see modular fmt, let alone entire graphs of dependent modular
libraries, really "working" until both CMake and other build systems can
*ergonomically* consume modular libraries.

Bret

On Wed, May 18, 2022, 11:58 Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

> Em qua., 18 de mai. de 2022 às 11:34, Stephen Kelly
> <steveire_at_[hidden]> escreveu:
> > - how will transition to modules work?
> > - Will large parts of libraries have to be restructured? [...]
> > - Will it be possible to support both modules of some kind and headers
> > for a library in a transitionary phase? [...]
> > - How much danger is there of bifucating the ecosystem between projects
> > that migrate to modules and those that don't? [...]
>
> Those are all fundamentally important questions.
>
> We need someone to start looking at commonly used libraries and
> experiment on what that migration would look like. I have some
> educated guesses, but this is real hard work that needs to be done for
> us to have real information.
>
> Ideally the Modules Ecosystem Technical Report would include
> recommendations based on lessons learned from those experiments.
>
> > > 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 ?
>
> Correct.
>
> > > 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.
>
> Correct.
>
> > 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).
>
> It works if all libraries you consume are providing CMake exports, but
> that's not uniform.
>
> > Looks like that paper acknowledges that a lot of engineering remains to
> > do (pushed onto toolchain developers?).
>
> It's not just the toolchain, it's also the build systems (e.g.: CMake,
> scons, bazel, etc) and package managers (e.g.: dpkg, vcpkg, conan,
> conda, etc). And there's a bit more specific engineering work to
> create interoperability between all those stakeholders, which is what
> I'm trying to do.
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>