On Mon, Dec 29, 2025 at 06:12:59 +0000, vspefs wrote:
> > 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.
>
> I think about distribution mainly in 2 ways, source distribution and binary
> distribution. The former ships the full project, both source files and build
> scripts. Source packages typically need running the corresponding build system
> to consume. The latter, on the contrary, distributes as final output artifacts
> as possible, and uses minimal meta information, whose logic (if there's any)
> is kept minimal as well. Xmake and Bazel both strongly tend towards source
> distribution. CMake packages, if export targets and install exported targets
> and do other stuff right, is "binary distribution + meta info in CMake
> script".Of course, CMake also supports source distribution and other forms of
> binary distribution (none of which support C++20 modules now though).
CMake's C++ module support is kind of a hybrid. Projects ship libraries
and module interface units. The consuming side then rebuilds BMIs as
necessary. I expect this to be the norm until BMI compatibility
detection tooling is available (and even then the support must be there,
but a very opinionated build system *could* just say "fix your stuff to
be consistent" at that point).
> The crucial difference is source distribution makes use of the full power of
> the build system. No semantic information within the scope of that certain
> build system is lost. So does "binary distribution + build system script".
> Binary distribution kinda has to be fixed, universal, and simple (or what's
> the point?). So I think the problem is not "making modules work in source
> packages", because that's totally a per-build-system business, and all it
> requires from the build system is a working dependency scanner. Binary
> distribution + universal meta info is where it's tricky.
Agreed.
> And honestly, the position of compiler in this picture? We don't know exactly
> until we are clear of what that "universal meta info" would look like. But if
> it's for Autotools, then I think it might be acceptable for GCC to have a
> dedicated `dep-format`. Of course, if Autotools figures things out from only
> P1689R5 format output, that's even better.
Note that I'd like to avoid yet another format because I doubt autotools
wants its module support to be "GCC only". I know LLVM-as-frontend is
eating the lunch of proprietary compilers, and P1689R5 is already there,
so that seems like an easy win to me.
I guess the main hurdle is either porting some JSON parser to an
automake-compatible language or growing a dependency on something like
`jq`.
> I know CPS as a good attempt to unify binary distribution meta info. It
> doesn't
> natively support C++20 modules far as I know. And I don't think adding an
> "interface_units" field could fix this problem. I think there has to be a way
This was added recently:
https://github.com/cps-org/cps/pull/95
> to inform users which compilation flags are compatible with this artifact and
> which are not. SG15 used to have core options which could beautifully solve
> this problem (and a few others). Seems like has to be another EcoStd stuff
> now.
CPS has a similar concept to CMake's compile option usage requirements,
so projects requiring specific flags can be propagated that way.
Note that CMake because re-builds BMIs at the consuming side, compatible
flags is down to the same ABI concerns we've always had with header and
library artifact mismatches that have always existed.
Thanks,
--Ben
