C++ Logo


Advanced search

Re: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

From: Daniel Ruoso <daniel_at_[hidden]>
Date: Wed, 18 May 2022 11:58:02 -0400
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 ?


> > 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.


> 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.


Received on 2022-05-18 15:58:15