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:
- the version of a compiler used can silently change, but the IDE needs to know the version to resolve standard library and to provide inspections about deprecated or not yet available features
- the user will have to use command line to switch toolchains, which may be painful if you are a windows user
-
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
~/.cargo/bin/cargo
# 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
~/.rustup/toolchains/1.10.0/cargo
# here the real binaries are stored. Completely private API
~/.rustup/impl/toolchains/1.10.0/cargo
Basically, the idea is to be able to run several different toolchains without invoking rustup override
.
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 PATH
