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