third_party/v8/README.md
rusty_v8 Release ArtifactsThis directory contains the Bazel packaging used to build and stage
target-specific rusty_v8 release artifacts for Bazel-managed consumers.
Current pinned versions:
v8 = =146.4.014.6.202.9The generated release pairs include:
//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//third_party/v8:rusty_v8_release_pair_x86_64_pc_windows_msvc//third_party/v8:rusty_v8_release_pair_aarch64_pc_windows_msvcEach release pair contains:
v8 crate version for that
targetDo not mix artifacts across crate versions. The archive and binding must match
the exact pinned v8 crate version used by this repo.
The dedicated publishing workflow is:
.github/workflows/rusty-v8-release.ymlThat workflow currently stages musl artifacts:
librusty_v8_release_x86_64-unknown-linux-musl.a.gzlibrusty_v8_release_aarch64-unknown-linux-musl.a.gzsrc_binding_release_x86_64-unknown-linux-musl.rssrc_binding_release_aarch64-unknown-linux-musl.rsDuring musl staging, the produced static archive is merged with the target's
LLVM libc++ and libc++abi static runtime archives. Rust's musl toolchain
already provides the matching libunwind, so staging does not bundle a second
copy.