Error in configuring crates_universe when included as a Bazel module
I'm attempting to include CXX as a Bzlmod module. Since it is not published on the Bazel Central Registry I'm doing so via a git_override
git_override(
module_name = "cxx.rs",
commit = "462896c80629a51ddcdc72fa55af0bb4befbb675",
patches = [
"//repo_patches:add_rules_cc_to_cxx.patch",
],
remote = "https://github.com/dtolnay/cxx.git",
)
where the add_rules_cc_to_cxx.patch modifies cxx's MODULE.bazel file to include an explicit dependency on rules_cc, something that I found was necessary to allow Bazel to even attempt to build any targets in @cxx.rs//.
Unfortunately, this still fails due to a repo lookup failure that gets memorialized into the MODULE.bazel.lock file. The details are available in this minimal reproduction
https://github.com/tel/cxx_bzlmod_repro
I think this may be an error in rules_rust or how crate_universe is being configured, but I wanted to start here and escalate if necessary.
Hi @tel, have you been able to integrate CXX into a Bazel build? I am very new to Bazel, and would like to add Rust+CXX to maplibre-native, but failing. Mostly I am just struggling with the best approach to integrating it - there seem to be tons of varying docs but none seem to fit. Thx!
I got furthest when using tag 110, prior to the switch to bzlmod. Haven’t had time to figure it out completely maybe next week.
@sthornington not sure what you mean by tag 110 - which repo, or is this a version of something? thx!
@nyurik I did end up getting it working, albeit with in a hacky fashion. Here's some instructions I just wrote up for someone else asking the same thing.
I did end up getting it working... though it's not pretty. I'd love for cxx to just support something like bzlmod and end up in a registry, but until that point what I've done is the following:
- I first vendored the cxx repo into a place in my repo, here
third-party/cxx - I am including a repo for crates.io using bzlmod and rules_rust, so I added copied all of the crate dependencies from the cxx repo into that crates.io vendored repo.
- For instance, I'm not personally using clap, but the cxx codegen application does, so I include it
crates_io.spec(package = "clap", version = "4.5")
- For instance, I'm not personally using clap, but the cxx codegen application does, so I include it
- Then I modified the
third-party/cxx/BUILDdefinition so that all of the dependencies reference my@crates_iorepo, e.g.rust_binary(name = "codegen", ..., deps = ["@crates.io//:clap", ...]) - Finally, I can reference the
cxxtools at paths like//third-party/cxx:codegen. For instance, to build my cxx C++ modules I have agenrulelike this
run_binary(
name = "bridge",
srcs = ["src/ffi.rs"],
outs = [
"ffi.rs.cc",
"ffi.rs.h",
],
args = [
"$(location src/ffi.rs)",
"-o",
"$(location ffi.rs.h)",
"-o",
"$(location ffi.rs.cc)",
],
tool = "//third-party/cxx:codegen",
)
Actually getting the cxx outputs properly integrated into Bazel is a bit messy, but at this point you should be able to mostly follow the examples from the repo. I'm happy to share more, but this should be enough to get you started.
This is awesome, I'll try it shortly. What steps are needed to actually publish cxx as a reusable module?
@nyurik I'm not sure.
Since March 2025 cxx has been available in Bazel Central Registry. Hopefully this issue does not occur when used that way.