Re: Generation of Make Dependencies for C++ Modules

[vspefs <vspefs@protonmail.com>]

> Some people seem to want that from C++ modules, but the way they
> currently work is highly compiler specific (even to the point that
> mismatching compiler flags can cause a compiled module interface to be
> rejected). I don't see this changing anytime soon; my personal
> expectation is that C++ build systems will still require distributing at
> least the sources for any public module interfaces in addition to shared
> libraries with the contents of any relevant implementation units.

I haven’t really gone through Jose’s informative reply, but your concern here is valid. CMI is designed to be an extremely implementation-specific stuff and everything you said is right.

What I want to point out is there are some standard and community efforts to make it distributable, but to make it actually useful we’re practically at least designing a “standard C++ AST” which can be considered impractical. By “community efforts” I mean CMake does distribute CMI but that’s just one way of distributing module packages. The alternative, and from your (also my) point of view, the correct way, is to use CXX_MODULES file set to package module interface units in the final distribution. Meanwhile, Xmake and Bazel don’t really care about binary distribution.

There are naturally some distribution problems emerging here. CMake’s solution works perfectly if we stay in the CMake universe but it distributes CMake script along with the package. If we want module packages at least universal as pkg-config packages, we’ll need some consensus between build systems. It can be pessimistic or limiting. WG21 used to have a study group that could make it a standard effort but due to reasons they can’t. Now arguably the best place to discuss such things is the EcoStd organization.