Aha, and this will make things a little more interesting for IntelliJ Rust. Let me give you some more context about our use case.
To compile code in IntelliJ, the use should configure SDK (software development kit). SDK is basically a path pointing to the location of necessary tools (cargo in the case of Rust), but it also includes sources of the standard library and a supported language version. If the user wants to develop a project with several versions of the language, she can configure several SDKs and switch between them from within IDE.
With the current setup we have the following options.
- We can make an SDK pointing to the rustup proxy bins in
~/.cargo/bin, but this will have several disadvantages:
We can call
rustup run instead of
cargo, but not everyone will be using
rustup. And I think this will have little annoyances for the end user, like having
rustup run in front of every command in the console output.
We can call tools from the toolchains directly, creating the necessary environment ourselves and basically replicating
rustup run functionality.
Options 1 and 3 seem the most promising here.
The alternative solution would be to add a level of indirection to
rustup I imagine it like this
# this is a rustup wrapper which uses overrides to determine which toolchain to invoke.
# This is a public API.
# A user can use `cargo` command to invoke active toolchain
# this is another wrapper which invokes particular toolchain.
# This is also a public API.
# A user can use `~/.rustup/toolchains/1.10.0/cargo` as a synonym to `rustup run 1.10.0 cargo`
# An IDE can use this path to invoke a particular toolchain
# here the real binaries are stored. Completely private API
Basically, the idea is to be able to run several different toolchains without invoking
And yes, the current implementation of SDK in IntelliJ Rust calls a
cargo binary from
~/.multirust/toolchains directly, which is completely broken because
cargo will pick any
rustc which happens to be in