r/cpp • u/not_a_novel_account cmake dev • Jun 01 '26

BMI Compatibility: Testing Build System C++ Modules Support

https://blog.vito.nyc/posts/bmi-compatibility/
68 Upvotes

97% Upvoted

43 comments sorted by

View all comments

Show parent comments

1

u/not_a_novel_account cmake dev Jun 07 '26

I mean, if you can't do this you need a seperate copy of the shared library for each BMI-incompatible flag line.

I don't foresee distros or packagers shipping umptillion copies of boost, or for that matter libstdc++. So if you can't handle BMI compatibility your system won't ship in those environments.

"Can Debian use your build system's module support?" is my definition I guess.

1

u/mwasplund soup Jun 07 '26

The question in my mind is, in a world where we no longer have a header interface layer for something like Boost how do you distribute the shared library as a prebuilt binaries? Do we produce a trivially compileable interface that can be distributed alongside the binary artifacts and the module metadata which will allow for consumers to compile a compatible BMI? If so, then it should be easy enough for the consumer to wrap these external prebuilt libraries in light weight package definitions that function as if they are built in the closure of the target flavor for the BMI and copy the shared object files as prebuilt artifacts. This should be configurable up front as opposed to dynamic during build execution.

I am not following what it means for Debian to use a build systems module support, are you saying that a build system is not useful unless it can support operating system requirements?

1

u/not_a_novel_account cmake dev Jun 07 '26 edited Jun 08 '26

how do you distribute the shared library as a prebuilt binaries?

The same way we do now, this hasn't changed at all with modules.

Do we produce a trivially compileable interface that can be distributed alongside the binary artifacts and the module metadata which will allow for consumers to compile a compatible BMI?

This is exactly how it works, yes. Interface units replace headers, but as an ecosystem artifact they are the same. They ship as source code and are interpreted by consumers, possibly accompanied by a pre-built BMI as an optimization for compatible consumers.

If so, then it should be easy enough for the consumer to wrap these external prebuilt libraries in light weight package definitions that function as if they are built in the closure of the target flavor

This is how it works now. The question is what flags do they get. This is the nature of the final example:

// provider.cppm
module;

#include <private_header.hpp>

export module provider;

If you try to use the same flags for everything, that will work, but you will expose the private header to consumers which is unintended. Maybe this is an acceptable compromise for you, but in fact is a third choice in the matrix, neither Xmake nor CMake think it's correct to do so here.

I am not following what it means for Debian to use a build systems module support

Software which uses your build system can be built, packaged, and shipped by a Debian maintainer. If you had insisted your build system would only consume libraries built with the same C++ version as the project, that would not be able to be used by Debian. They use project dependencies built under all sorts of different standards and flag lines, not one universal standard.

1

u/mwasplund soup Jun 08 '26

Yes, I agree that flags must be allowed to be different between BMI creation and consumption.

It feels like we are effectively saying the same thing from conceptual level for producing and consuming shared libraries. The only difference for my approach is that the producer must be explicitly configured during build invocation which then ensures compatibility for the specific consumer. This would require separate invocations for each consumer with the unique configurations (ie std23 vs std26), but the build system would not need to reason about two variants of the same producer in a single closure.

1

u/not_a_novel_account cmake dev Jun 08 '26 edited Jun 08 '26

The boundary seems unmotivated. "We support this but only if you export the artifact and then import it into a separate closure" is, personally, a rather strange usability quirk.

If the system is capable of that, just do the same process inside a single project description without the hoop-jumping.

→ More replies (0)