Files
codex/codex-rs/docs/bazel.md
Channing Conger 3f3f09e7bc Setup a new v8-poc package
This is a new package that depends on rusty-v8 for embedding a v8
engine.  This builds and works on non-musl platforms now because
rusty-v8 provides versions for that.  But we mocked out the loading of
a musl built library.

TODO: iterate on providing the musl built version for musl-linux builds.
TODO: create a release workflow for publishing the artifact that rusty-v8 can link against
2026-03-17 10:59:25 -07:00

73 lines
3.2 KiB
Markdown

# Bazel in codex-rs
This repository uses Bazel to build the Rust workspace under `codex-rs`.
Cargo remains the source of truth for crates and features, while Bazel
provides hermetic builds, toolchains, and cross-platform artifacts.
As of 1/9/2026, this setup is still experimental as we stabilize it.
## High-level layout
- `../MODULE.bazel` defines Bazel dependencies and Rust toolchains.
- `rules_rs` imports third-party crates from `codex-rs/Cargo.toml` and
`codex-rs/Cargo.lock` via `crate.from_cargo(...)` and exposes them under
`@crates`.
- `../defs.bzl` provides `codex_rust_crate`, which wraps `rust_library`,
`rust_binary`, and `rust_test` so Bazel targets line up with Cargo conventions.
It provides a sane set of defaults that work for most first-party crates, but may
need tweaks in some cases.
- Each crate in `codex-rs/*/BUILD.bazel` typically uses `codex_rust_crate` and
makes some adjustments if the crate needs additional compile-time or runtime data,
or other customizations.
## Evolving the setup
When you add or change Rust dependencies, update the Cargo.toml/Cargo.lock as normal.
Then refresh the Bzlmod lockfile from the repo root:
```bash
just bazel-lock-update
```
This runs `bazel mod deps --lockfile_mode=update` and updates `MODULE.bazel.lock` if needed.
Commit the lockfile changes along with your Cargo lockfile update.
To verify lockfile alignment locally (the same check CI runs), use:
```bash
just bazel-lock-check
```
In some cases, an upstream crate may need a patch or a `crate.annotation` in `../MODULE.bzl`
to have it build in Bazel's sandbox or make it cross-compilation-friendly. If you see issues,
feel free to ping zbarsky or mbolin.
One current example is `rusty_v8`: normal workspace builds should consume a prebuilt archive
through `RUSTY_V8_ARCHIVE` rather than trying to build V8 from source inside every Bazel action.
The placeholder Bazel label lives at `//third_party/v8:rusty_v8_archive`; replace that target's
underlying file with the musl-built archive before enabling the `codex-v8-poc` crate's
`rusty_v8` feature for musl targets in Cargo or Bazel. Non-musl Bazel targets are left to the
crate's default build-script behavior.
When you add a new crate or binary:
1. Add it to the Cargo workspace as usual.
2. Create a `BUILD.bazel` that calls `codex_rust_crate` (see nearby crates for
examples).
3. If a dependency needs special handling (compile/runtime data, additional binaries
for integration tests, env vars, etc) you may need to adjust the parameters to
`codex_rust_crate` to configure it.
One common customization is setting `test_tags = ["no-sandbox]` to run the test
unsandboxed. Prefer to avoid it, but it is necessary in some cases such as when the
test itself uses Seatbelt (the sandbox does as well, and it cannot be nested).
To limit the blast radius, consider isolating such tests to a separate crate.
If you see build issue and are not sure how to apply the proper customizations, feel free to ping zbarsky or mbolin.
## References
- Bazel overview: https://bazel.build/
- Bzlmod (module system): https://bazel.build/external/overview
- rules_rust: https://github.com/bazelbuild/rules_rust
- rules_rs: https://github.com/bazelbuild/rules_rs