On Mon, Dec 29, 2025 at 00:03:44 +0000, vspefs via Gcc wrote:
> > 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.
I have a pending reply to Jose's post, but I'll reply here since it is
more focused.
> 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
CMake ships the CMI (though it uses the BMI TLA), but currently does not
consume it. The idea is that multiple CMI files could be shipped for
each module. If P2581 is ever implemented, CMake could look at what BMI
files are available for the module and use "copy file" as the "bmild the
module" implementation.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2581r2.pdf
Will it ever exist? No idea.
I haven't dug into xmake's implementation, but Bazel (AFAIK) is much
stricter about flag sets across the build and can kind of wave it away
by convention.
> 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.
Please see CPS for shipping package information without using CMake
script. CPS export support is currently experimental in CMake, but it is
coming.
https://github.com/cps-org/cps
And yes, please consider joining EcoStd for discussion about such
things.
Thanks,
--Ben
