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
