You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to use wasm-pack, which uses wasm-bindgen, which, in turn, uses the wasm32-unknown-unknown target.
wasm32-unknown-unknown does not support the profiler. Chromium has it enabled under [build] in config.toml, but thankfully, there's a per-target option we can use to disable it for wasm32-unknown-unknown.
In config.toml.template:
[target.wasm32-unknown-unknown]
profiler = false
wasm32-unknown-unknown uses rust-lld. Chromium doesn't explicitly specify in config.toml that it needs it, and even though it does show up at a couple locations:
as a side-effect of building Rust, we are the ones who have to make sure it gets compiled by the stage 1 compiler and is available for wasm32-unknown-unknown.
In config.toml.template:
[rust]
lld = true
Now, since we want to use x.py's build subcommand which defaults to the stage 1 compiler, we need to have the stage 1rustc compiler built first. The rustc toolchain needs to be built against Chromium's LLVM version, so we'll have to go through the same exact steps as they do.
The best shortcut I could find is to use their build_rust.py script's --prepare-run-xpy and --run-xpy flags.
tools/rust % ./build_rust.py --prepare-run-xpy — this prepares the environment for x.py (checks out Rust, builds the LLVM libraries, adds CMake to the path, generates config.toml, etc.)
Obviously, compiling the above with every single build is not at all reasonable, so I suggest that we do what Chromium does with their Rust tooling: build it centrally and distribute it via gclient sync(-like mechanism).
The text was updated successfully, but these errors were encountered:
We want to use
wasm-pack
, which useswasm-bindgen
, which, in turn, uses thewasm32-unknown-unknown
target.wasm32-unknown-unknown
does not support the profiler. Chromium has it enabled under[build]
inconfig.toml
, but thankfully, there's a per-target option we can use to disable it forwasm32-unknown-unknown
.In
config.toml.template
:wasm32-unknown-unknown
usesrust-lld
. Chromium doesn't explicitly specify inconfig.toml
that it needs it, and even though it does show up at a couple locations:as a side-effect of building Rust, we are the ones who have to make sure it gets compiled by the
stage 1
compiler and is available forwasm32-unknown-unknown
.In
config.toml.template
:Now, since we want to use
x.py
'sbuild
subcommand which defaults to thestage 1
compiler, we need to have thestage 1
rustc
compiler built first. Therustc
toolchain needs to be built against Chromium's LLVM version, so we'll have to go through the same exact steps as they do.The best shortcut I could find is to use their
build_rust.py
script's--prepare-run-xpy
and--run-xpy
flags.tools/rust % ./build_rust.py --prepare-run-xpy
— this prepares the environment forx.py
(checks out Rust, builds the LLVM libraries, adds CMake to the path, generatesconfig.toml
, etc.)tools/rust % ./build_rust.py --run-xpy build --build aarch64-apple-darwin --target aarch64-apple-darwin,wasm32-unknown-unknown --stage 1
move build artifacts:
Obviously, compiling the above with every single build is not at all reasonable, so I suggest that we do what Chromium does with their Rust tooling: build it centrally and distribute it via
gclient sync
(-like mechanism).The text was updated successfully, but these errors were encountered: