00e40471f5
Add the `crdtp_binding.cc` source and CRDTP headers to the 147 Bazel V8 binding target so Windows GNU builds provide the symbols required by the `v8::crdtp` Rust APIs. Add a regression test that exercises CRDTP JSON conversion and dispatchable message parsing.
rusty_v8 Consumer Artifacts
This directory wires the v8 crate to exact-version Bazel inputs.
Bazel consumer builds use:
- upstream
denoland/rusty_v8release archives on Windows MSVC - source-built V8 archives on Darwin, GNU Linux, musl Linux, and Windows GNU
openai/codexrelease assets for published musl release pairs
Cargo builds still use prebuilt rusty_v8 archives by default. Only Bazel
overrides RUSTY_V8_ARCHIVE/RUSTY_V8_SRC_BINDING_PATH in MODULE.bazel to
select source-built local archives for its consumer builds.
Source-built Bazel V8 artifacts enable V8's in-process sandbox by default, and
the Bazel v8 crate feature selection tracks those targets. A full consumer
rollout still needs matching sandbox-enabled archives for every non-source-built
target. Until that artifact migration lands, the rusty_v8 publishing workflows
use --config=v8-release-compat to preserve the current non-sandboxed release
artifact contract.
Current pinned versions:
- Rust crate:
v8 = =147.4.0 - Embedded upstream V8 source for Bazel-produced release builds:
14.7.173.20
When changing the remaining prebuilt rusty_v8 http_file inputs, keep the
checked-in checksum manifest and MODULE.bazel in sync:
python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
The commands default to the single rusty_v8_* http_file version still
present in MODULE.bazel and validate every matching entry. CI runs the check
command to block checksum drift.
The consumer-facing selectors are:
//third_party/v8:rusty_v8_archive_for_target//third_party/v8:rusty_v8_binding_for_target
Published release assets are expected at the tag:
rusty-v8-v<crate_version>
with these raw asset names:
librusty_v8_release_<target>.a.gzsrc_binding_release_<target>.rs
During the sandbox rollout, sandbox-enabled assets are published alongside those current assets on the same tag, with the Rust crate's sandbox feature suffix in their raw names:
librusty_v8_ptrcomp_sandbox_release_<target>.a.gzsrc_binding_ptrcomp_sandbox_release_<target>.rs
The dedicated publishing workflow is .github/workflows/rusty-v8-release.yml.
Tagged runs build release artifacts from the Bazel graph itself:
//third_party/v8:rusty_v8_release_pair_x86_64_apple_darwin//third_party/v8:rusty_v8_release_pair_aarch64_apple_darwin//third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_gnu//third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_gnu//third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl//third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl
The same run also builds the matching sandbox pair targets:
//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_apple_darwin//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_apple_darwin//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_gnu//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_gnu//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_musl//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_musl
The Bazel graph pins the same libc++, libc++abi, and llvm-libc source revisions
used by rusty_v8 v147.4.0, compiles published artifact targets with
--config=rusty-v8-upstream-libcxx, and folds the matching runtime objects into
the final static archive so Cargo consumers can link it with the v8 crate's
default use_custom_libcxx feature. The config keeps the object files and the
bundled runtime on Chromium's std::__Cr ABI namespace instead of mixing those
objects with the toolchain libc++ default namespace.
MSVC is not part of the Bazel-produced matrix yet. The repository's current
hermetic Windows C++ platform is windows-gnullvm/x86_64-w64-windows-gnu, so
it cannot truthfully reproduce upstream's *-pc-windows-msvc archives until we
add a real MSVC-targeting C++ toolchain to the Bazel graph.
Cargo musl builds use RUSTY_V8_ARCHIVE plus a downloaded
RUSTY_V8_SRC_BINDING_PATH to point at those openai/codex release assets
directly. We do not use RUSTY_V8_MIRROR for musl because the upstream v8
crate hardcodes a v<crate_version> tag layout, while our musl artifacts are
published under rusty-v8-v<crate_version>.
Do not mix artifacts across crate versions. The archive and binding must match
the exact resolved v8 crate version in codex-rs/Cargo.lock.