[gentoo-dev] Request to add USE_EXPAND variable for enabling Rust sysro
From
Michal Rostecki@21:1/5 to
All on Mon May 5 21:10:01 2025
Hi,
Currently, dev-lang/rust ebuild provides `wasm` USE flag which enables WebAssembly LLVM target adds `wasm32-unknown-unknown` to the `targets` parameter in config.toml, which results in building a Rust sysroot for
such target.
Rust sysroot is a directory which contains the prebuilt standard
libraries (in form of `*.rlib` files) and utility binaries (e.g. `rust-objcopy`). Sysroots which are not bare-metal usually contain a
copy of compiler runtime, unwinder and libc as well.
There is more and more interest in packaging BPF projects written in
Rust, which would require adding a posibility to build Rust with BPF
sysroot, similar to the WASM one. The "easiest" (in terms of short-term
low effort) solution would be adding an another USE flag, but once we
are going to add more bare-metal or VM targets (GPUs, amdgcn, risc0
etc.), that might become a bit messy.
That's why I would like to propose adding a new variable, called
RUST_SYSROOTS, which would determine which bare-metal sysroots should
be built. It would start with providing `bpf` and `wasm` as options.
Enabling them would trigger adding appropriate triples to config.toml.
Projects requiring WASM or BPF which are written in Rust would need
to depend on dev-lang/rust with the specific sysroot enabled.
That variable would **not** be used for targets requiring
libc/rt/unwinder, where crossdev is a better fit.
In case you agree with the idea, please let me know if I should send
patches on the ML or on GitHub.
Also, I'm open to suggestions what should be done about rust-bin.
Rustup binaries don't ship any additional sysroots. Should we follow
the same direction in binary builds done by ourselves? Or should we
enable additional sysroots and lean towards building binaries from
scratch always?
Thanks,
Michal
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)