chromium_build
Deno floats patches to //build here (they will be sent upstream eventually)
by denolandPython
Commit activity
Last 12 weeks · 0 commits
Community health
1 of 6 standards met
25
✓README○License○Contributing○Code of Conduct○Issue Template○PR Template
Recent PRs & issues
Active · 2 in progress · Last activity 3w ago
See all on GitHub →
This patch is the first of several patches which would bring support for FreeBSD x86_64. Apologies I couldn't figure out what branch to make the PR against (upstream seems very old), so I made it off of the branch that was referenced in rusty_v8 at the time of this commit. Related issue: https://github.com/denoland/rusty_v8/issues/1094
I'm trying to build rusty_v8 on riscv64. This currently requires using either a system-provided or custom rustc, since Chromium does not vendor rustc for riscv64. I would like to use the rustc provided by the distro, which is a stable release rather than nightly. To build with stable rustc, it seems that this Chromium commit is required, which is not synced to this repo (at least the branch) yet: https://github.com/chromium/chromium/commit/4b23724f74f7661b8bc31a2a6b60145b4a81dd48 So I have a few questions: How is this repository synced? How to trigger the sync? Is it based on some schedule or policy? What is the proper way to manually cherry-pick a commit from Chromium into this repository? Which branch should I base my work on if I want to submit a PR here? I noticed that some PRs target the branch, but if the branch carries its own patches, then it does not seem truly “upstream” anymore.
Manually clean up clippy lint. Some of these changes cause about 5% performance improvements because does not need a reference and cannot be optimized by the compiler (but in thees cases the perf difference is less important)
Recent fixes
Follow-up to the musl support (#205), needed for aarch64-unknown-linux-musl. arm64 musl is a cross build (x64 host, arm64 target), and V8 builds mksnapshot with an x64 host snapshot toolchain (clang_x64_v8_arm64). The previous guard (!toolchain_for_rust_host_build_tools) let the global use_musl leak onto that x64 snapshot toolchain, which would build it against a glibc sysroot but with musl rust/libc++ config. Tightening the guard to current_toolchain == default_toolchain scopes musl to the target toolchain only, so host and snapshot toolchains stay glibc for any target arch without per-arch variants. x86_64 musl is unaffected -- its host is already the non-default clang_x64_glibc toolchain.
Adds musl libc target support, used by rusty_v8 to build and publish musl prebuilts (denoland/rusty_v8#2016). Introduces a target-scoped use_musl GN arg. When set, V8's internal Rust crates and libstd build for the musl triple and the target compiles against a musl sysroot, while the executable build tools (torque, mksnapshot, code generators) keep building with a separate glibc toolchain (clang_x64_glibc) so they link and run on the glibc build host. Everything is guarded by use_musl && !toolchain_for_rust_host_build_tools, so only the target toolchain is affected; glibc builds are unchanged.
Structured data for AI agents
Repository: denoland/chromium_build. Description: Deno floats patches to //build here (they will be sent upstream eventually) Stars: 33, Forks: 24. Primary language: Python. Languages: Python (85.1%), Starlark (5.4%), Java (3.8%), Shell (2.6%), C++ (1.3%). Homepage: https://chromium.googlesource.com/chromium/src/build/ Open PRs: 2, open issues: 1. Last activity: 3w ago. Community health: 25%. Top contributors: agrieve, nico, jbudorick, tanderson-google, sdefresne, ukai, zmodem, danakj, bpastene, randomascii and others.