rust-lang / rustup

The Rust toolchain installer

Rustup: the Rust toolchain installer

Master CI	Build Status
Windows
macOS
Linux Etc

Rustup installs The Rust Programming Language from the official release channels, enabling you to easily switch between stable, beta, and nightly compilers and keep them updated. It makes cross-compiling simpler with binary builds of the standard library for common platforms. And it runs on all platforms Rust supports, including Windows.

Documentation

See The Rustup book for documentation on installing and using Rustup.

Contributing

See The Rustup dev guide for information on contributing to Rustup.

License

Copyright Diggory Blake, the Mozilla Corporation, and Rustup contributors.

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

rustup's Issues

Download toolchains from behind a proxy

I'm currently behind a proxy, and can't download any toolchains. How do you set up proxy settings with multirust?

Support updating multirust-rs itself from the command line

Light fonts on white terminal hard to see

It's tough for me to read the "beta"/"stable"/"nightly" tags in the lower left

As a library, this has been a delight to use!

Not actually an issue!!

@Diggsey, @brson, and other authors: I've been using multirust-rs as a library in a little project which I've just wrapped up the initial version of (rust-bisect), and it's been a joy to use. It seems to expose all the things I want. Only minor changes were needed for as-a-library use, and they seemed welcome.

So I just wanted to say thanks and well done!

Use docopt for multirust binary

Hey @Diggsey,

I've been poking around this project a bit to figure out the library API, and I had a look at the cli file. It's sort of..... unapproachable 😁. The API multirust exposes could easily be written using docopt, and it would make maintenance a lot easier.

Are you open to a PR for this if it showed up?

How to install apple-darwin toolchain?

The apple-darwin toolchain has no <env> part (such as gnu or msvc). But when the <env> part is omitted, it defaults to the host. For example on linux:

~ $ multirust update x86_64-apple-darwin-nightly
info: installing toolchain 'x86_64-apple-darwin-nightly'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly.sha256'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly'
checksum passed
error: a binary package was not provided for: 'x86_64-apple-darwin-gnu-nightly (tracking)'

Download progress swamps terminal on MinGW

In a MinGW terminal I ran multirust update, and the new download progress counters look like they didn't correctly overwrite themselves so the output was just swamped with updates:

There's no default default toolchain

Multirust installs with no default toolchain configured, meaning every command fails. "multirust update" works, but when it tries to run rustc -vV for each installed toolchain, each one fails with the "no default toolchain configured" error.

Quick fix is to add "multirust default stable" to the install instructions. Better (IMO) would be to ship with stable as the default toolchain.

Reinstallation attempted to re-run itself

I've got a few downloads of multirust-rs.exe in my downloads folder, so when I download a new one it's auto-renamed to multirust-rs(N).exe, but the installer only works if the filename is called multirust-rs.exe. Perhaps some extra pattern matching could be in play?

MSVC can't install channels

I downloaded the 64-bit MSVC built of multirust and ran multirust update and was then met with:

error: binary packages are not yet provided for this host

"Unknown metadata version" when multirust folder was created by shell multirust

thomas@klinklang:~$ multirust upgrade-data
info: upgrading metadata version from '2
' to '2'
error: unknown metadata version: '2
'

Looks like shell multirust leaves a newline in .multirust/version and multirust-rs doesn't strip it from the string when comparing.

Cannot spawns a process called "rustc" on Windows

When using multirust on Windows it looks like invocations along the lines of Command::new("rustc") will fail because there's no binary called rustc.exe on the system (maybe the shell only runs batch files?)

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 multirust-rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @Diggsey
• @alexcrichton
• @zonyitoo
• @jwilm
• @trolleyman

Change `CARGO_TARGET_DIR` based on toolchain

Switching between toolchains with Multirust causes a lot of cache thrashing as Cargo removes and recompiles artifacts.

It would be nice if there was an option to have Multirust's cargo proxy automatically redefine the CARGO_TARGET_DIR environment variable so that instead of every toolchain's Cargo trying to output to $PKGDIR/target, they instead output to $PKGDIR/target/$TOOLCHAIN. This would make, for example, testing across multiple Rust versions and/or toolchains (i.e. GNU vs. MSVC) much easier.

msiexec returns 1639 with "help" popup

After trying many many many times to get multirust working on Windows without success (with msiexec returning 1639 over and over again with that confusing popup 😭), I finally figured out why multirust was not working for me. std::process::Command will quote arguments as needed, except that the way it quote the arguments doesn't work for msiexec. When this:

TARGETDIR=path with space

is given to std::process::Command, It turns it into:

"TARGETDIR=path with space"

but msiexec needs it as:

TARGETDIR="path with space"

Note the position of the double quotes. One workaround is to use MULTIRUST_HOME= to get multirust to use a path without spaces (and any other character that might get std::process::Command into quoting the TARGETDIR= argument). The other is to create a new user account with a folder that does not have any spaces (or characters that might get std::process::Command to quote TARGETDIR=).

PS: Having figured that out, I decided to use msys2 to try create an isolated environment to temporarily test multirust by setting MULTIRUST_HOME=/c/path/to/multirust/home , but that didn't work either ( since msys2 converts path in what they call "mixed mode", it ends up being c:/path/to/multirust/home instead of c:\path\to\multirust\home ). Of course, msiexec (like many Windows commands) barfed on this 😭. Maybe multirust could change '/' to '' in paths before passing them to msiexec (or maybe warn the user about it).I won't be surprised if there are other combinations that can make msiexec fail, but these are the only ones I've encountered so far. Sorry for the rant 😛.

Refactor into usable library

multirust-rs is currently a direct rewrite of the multirust shell script. It needs refactoring into a reusable and maintainable library and binary.

Default toolchain not propagated to cygwin from msys

I installed multirust in MSYS2 but then when running in a cygwin shell it reports that "no default toolchain is configured" (whereas in MSYS2 it works ok). Perhaps this is because $HOME is changing locations?

Linux binaries don't run on older machines

Unfortunately to get a "maximally compatible" linux binary it needs to be built on a super-old Linux machine (e.g. CentOS 5). This is what we currently do for our rustc distribution, but otherwise the error message you get looks like:

./multirust: /rustroot/lib64/libcrypto.so.1.0.0: no version information available (required by ./multirust)
./multirust: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./multirust)
./multirust: /rustroot/lib64/libssl.so.1.0.0: no version information available (required by ./multirust)

This should be "easily" available through a docker image of CentOS 5 on Travis. You can see our docker image, although that level of complexity probably isn't necessary (e.g. the custom gcc may not be needed).

Another point is that to distribute a linux binary with SSL support the only robust way I know of is to link OpenSSL statically. Older systems don't have the 1.x releases of OpenSSL and still use 0.9.8, so to work on both you've got to statically link in OpenSSL (e.g. this is what Cargo does).

I can certainly help out with all this stuff as well!

Completing cargo crates with racer is broken with multirust-rs

The problem seems to be that racer is expecting the cargo dir to be in .multirust/toolchains/<toolchain>/cargo, while in multirust-rs it's in .multirust/cargo.

DEBUG:racer::cargo: get_cargo_rootdir root is "/home/snake/.multirust/toolchains/nightly/cargo"
DEBUG:racer::cargo: get_versioned_cratefile: cargo rootdir is "/home/snake/.multirust/toolchains/nightly/cargo"
ERROR:racer::cargo: ERROR!: Error { repr: Os { code: 2, message: "No such file or directory" } } src/racer/cargo.rs 403

I'm not sure whether this deviation is an oversight or a deliberate choice. If it's the latter, then perhaps explicit support for multirust-rs vs multirust needs to be added to racer.

Update more than the default channels?

Could multirust update perhaps update all channels that a local installation is tracking instead of just the stable/beta/nightly ones? For example I've got 64-bit GNU and MSVC tracking on Windows, so perhaps they could all be updated at once via a multirust update

Build on stable Rust

The main blocker for this is the use of #[fundamental] in the notification system. I haven't looked into it in too much detail, but I think this can be done by reducing the amount of typegineering going on. Thoughts?

Consider switching to MIT/Apache-2 license

There's a good chance this will become an official Rust project someday, and all Rust code is dual licensed MIT/Apache-2.

Can't reinstall toolchain after removing it

Steps to reproduce:

• multirust default beta
• multirust remove-toolchain beta
• multirust default beta

Output:

info: installing toolchain 'beta'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-beta.sha256'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-beta'
downloading file from: 'https://static.rust-lang.org/dist/rust-beta-x86_64-pc-windows-msvc.msi.sha256'
info: update hash matches: 1c393d0a66788a093712, skipping update...
info: default toolchain set to 'beta'

It doesn't actually reinstall the removed toolchain though, so attempts to use it result in:

error: not a directory: 'C:\Users\Lee\.multirust\toolchains\beta'

I was able to reinstall it by first deleting the beta file in update-hashes.

Progress and speed indication for downloads

It's useful to know approximately how much time is left until the download is finished, and at what speed we are downloading at.

The original shell script version of multirust provides this information.

warning: multirust is installed but is not set up correctly: `rustc` invocations will not be proxied

Hi,

I need help to fix the following warning (terminal output):

$ multirust list-toolchains
warning: multirust is installed but is not set up correctly: rustc invocations will not be proxied.

Ensure 'C:\Users\micha\AppData\Local.multirust\bin' is on your PATH, and has priority.

nightly

I am running Windows 10 pro.
My "Path" is correct.

I have installed:
$ rustc --version
rustc 1.8.0-nightly (75271d8f1 2016-02-09)

$ cargo --version
cargo 0.9.0-nightly (3e285ce 2016-02-05)

How to setup multirust correctly?

Thanks.

Michael

open_browser broken on linux

The not(windows) implementation of open_browser uses command to see whether a command exists, but command is a shell-builtin (at least in bash), so it doesn't work when invoked through process::Command.

How about instead using the which command?

Can't install toolchains

I installed the 64-bit GNU installer and ran multirust update nightly and was met with:

extracting ...
tar (child): Cannot connect to C: resolve failed

gzip: stdin: unexpected end of file
tar: Child status returned 128
tar: Error is not recoverable: exiting now
error: command 'tar' terminated with exit code: 2

Might I recommend flate2 + tar for extracting tarballs? This is what Cargo uses and it seems to work out pretty well! (also removes a dep on a local tar command).

Running "multirust" spawns thousands of processes

I ran "multirust" (no arguments) on Windows and now I've got thousands of processes running, presumably waiting for input.

(perhaps this would be a good time to add tests to the repo?)

Running multirust installer hangs on Windows

For example:

$ multirust
This is the currently installed multirust binary.

(and it never returns to the shell). If I hit "enter" it'll return, but perhaps shouldn't require that? I also ran into this when installing or maybe updating a toolchain, but I forget the precise situation.

"multirust run" different syntax?

For example:

$ multirust run stable rustc -vV
thread '<main>' panicked at 'failed to run `stable`', ../src/libcore\option.rs:33

It looks like it's trying to interpret stable as the binary to run?

handle install failures better

Right now, if a toolchain install fails (for example, if the msi server was not running, or one was running multirust in an account without the needed permissions to make installations), one has to start the process all over again. This isn't too bad, except for the case where one has a slow network connection (take hours to download) and the installer was downloaded by multirust (not obvious where to find the downloaded installer file, assuming it still exists somewhere on the the machine). Would be nice to have either some way of retrying the install or a way to download and save the installers somewhere, waiting for the user to install manually (some might like the latter better as it allows them to run multirust with less privileges when downloading the installers).

ctrl-c doesn't kill processes on Windows

When running around in the MSYS shell using multirust I've found that using Ctrl-C to kill a process (or killing multirust in any other way) doesn't actually kill the child that it spawned. This means that the Cargo process, for example, that you tried to interrupt will keep running in the background and spewing output to the console.

The way I know of at least to handle this on Windows at least is to use CreateJobObject which is something I also ended up doing for the bootstrap build system

The command 'multirust doc' should open the main index

As I was coming back to learning the Rust language, and wanted to view the documentation that came with the stable/nightly toolchain, I was confused that I was presented with the documentation for the crate std, instead of the main index where I was looking for the language syntax to see what has changed since the last time I played with it.

My suggestion is to make 'multirust doc' command to open the main index, and the options given to this command like --std, --book, --nomicon etc., would open instead the specific pages instead of the main page.

I know that the multirust project can't help doing some trickery to inject some kind of backlink to the main index, in those pages opened by the options given to the command 'multirust doc', so changing the initial behavior is better for a beginner.

Another solution is to tell the multirust to set the doc command to open the particular page on default by using some command options that sets some internal variables that persists.

What do you think?

'rustc' is an unknown command on Windows

Although rustc.bat is installed, it looks like in an MSYS shell at least running "rustc" as a command doesn't work.

bash: rustc: command not found

Use exec() to delegate to the real cargo/rustc on Unix

Right now the Command API is presumably used which is cross platform (yay!) but doesn't provide the best experience on Unix. For example if I gdb cargo it doesn't actually gdb the Cargo executable itself but rather the shim. If, however, exec were used to spawn the new process then gdb I believe should naturally "just work".

Plus there's the added benefit of fewer processes sticking around!

OSX binaries don't run on older machines

Like with #23, building for OSX can be nontrivial sometimes to ensure that something works on older machines. I think that OSX doesn't need the same "CentOS 5 craziness" that Linux needs, but rather it can just set the MACOSX_DEPLOYMENT_TARGET environment variable to "10.7". To the best of my knowledge, that will instruct the linker to "do the old things" which I think is the only point of incompatibility.

"Thankfully" the OpenSSL OSX has and depends on is basically locked at 0.9.8, so no need to worry about that in this case!

Description is confusing for people who don't know what multirust is

The readme says "Multirust-rs is a reimplementation of multirust in rust", but it doesn't say what multirust is. For someone coming in cold, it doesn't offer any clues as to why they want to be using multirust-rs, or what they might want to use it for.

/u/othermike on Reddit

Reset terminal attributes before quitting

multirust-rs does not reset terminal attributes before quitting, resulting in the terminal attributes "bleeding out" into the shell environment.

Example:

multirust self update panics.

After running self update, I get a panic:

 ❯❯❯ multirust self update
downloading file from: 'https://github.com/Diggsey/multirust-rs-binaries/raw/master/x86_64-apple-darwin/multirust-rs.sha256'
thread '<main>' panicked at 'assertion failed: self.is_char_boundary(new_len)', ../src/libcollections/string.rs:597

Make a release?

Hi @Diggsey! I'm trying to use multirust as a library, and the version on crates is pretty ancient. I'm using it from git for now, but an update could be good. :-)

Allow overriding the dist URL

Makes it easier to install things from the staging dist.

multirust update blew away commands from "cargo install"

I installed rustfmt yesterday and ran "multirust update" this morning, but it was gone when I tried to use it again :(

multirust itself and proxied commands occasionaly crash on Windows 10

multirust executable as well as all proxied rust-executables do occasionally crash when run.

I fired up MSVS-Debugger to see from where that crash comes from. It is shown as

Unhandled exception at 0x00007FF80F455AEB (ntdll.dll) in multirust-607yx6q5qo89cvgo_file.exe: 0xC0000005: Access violation writing location 0x0000000000000024.

This was after trying to update multirust via multirust self update.

Another one occured when trying to cargo build in a toyproject (same addresses but some other executable:

Unhandled exception at 0x00007FF80F455AEB (ntdll.dll) in cargo.exe: 0xC0000005: Access violation writing location 0x0000000000000024.

This especially annoying when this occurs during a build with a deep dependency tree and I have to restart the build on every 2nd or 3rd compiled dependency, or on a cargo test when I have to try it about 3 to 5 times before the actual tests are run.

I don't have such problems when using a rust from official installer.

Handle the case where binaries are not available better

This means better error messages, which distinguish between a target triple for which binaries are not yet produced, from when binaries are just not available for that triple on a certain date.

Possibly also fall back to the most recent binary which is available in this case.

multirust update 1.0.0 => invalid custom toolchain name

This currently works on shell-based multirust, perhaps it could also be made to work in multirust-rs?

multirust run can't run external tool?

With multirust.sh I frequently do something like multirust run nightly gdb cargo ... or something like that, but when trying this with multirust-rs:

$ multirust run nightly perf record cargo package
error: command failed: 'perf' (Io: No such file or directory (os error 2))

error: could not rename install directory ...

> multirust default nightly
info: installing toolchain 'nightly'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly.sha256'
downloading file from: 'https://static.rust-lang.org/dist/channel-rust-nightly'
checksum passed
downloading file from: 'https://static.rust-lang.org/dist/rust-nightly-x86_64-pc-windows-msvc.msi.sha256'
downloading file from: 'https://static.rust-lang.org/dist/rust-nightly-x86_64-pc-windows-msvc.msi'
checksum passed
extracting...
error: could not rename install directory from 'C:\Users\kot\AppData\Local\.multirust\tmp\955unrm5mlu_aauj_dir\Rust' to 'C:\Users\kot\AppData\Local\.multirust\toolchains\nightly' (Access is denied. (os error 5))

rustup.rs future work

This is a brain dump of the work I believe is left to complete the transition to rustup.rs.

cc @Diggsey @alexcrichton

Polish existing UI

I'm not sure what else needs to happen but I know there are some commands
that still don't look nice to me. I've taken a pass at the most important ones but not all.

Also go over common error cases and make sure they look good.

Install to $CARGO_HOME

This will probably need another version bump to know to delete the bins from ~/.multirust.

Add tests for delete-data which right now doesn't work correctly because the bins in ~/.multirust/bin get clobbered.

Reconsider windows install dir

Right now multirust-rs installs to AppData/Local/.multirust. It should maybe not use a dotfile here. Use whatever scheme Cargo does.

Make self-install frobbing of $PATH foolproof

I haven't looked at the code for how self install sets up the path,
but I do have opinions about how it should work.

It should both install and remove the path by default, with an option
not to. Because shells typically need to be restarted for this to work
it should probably also emit a shell-specific file that can be
immediately sourceed as well.

Overhaul self-upgrade procedure

The way multirust-rs treats no arguments as a self-upgrade is prone to error, and takes away our
ability to do useful other things with no arguments. Change the name of the installation program
to multirust-setup and only run the 'self install' on no arguments when the binary has that name.

Normalize toolchain names

At the moment multirust-uses the toolchain name as provided by the
user to identify toolchains, even their location on disk. Instead,
ToolchainDesc should be constructed immediately when Toolchain is and
all further internal references to toolchains should be the fully
expanded form. When printing toolchain names to the user either use
the one they refered to or come up with a scheme for automatically
shortening toolchain names, i.e. maybe host toolchains don't get
expanded to $triple-channel.

Create the "rustup" command

When run as "rustup", multirust-rs will present a new, subcommand-based interface. I haven't
thought it through yet but it will probably be something like "rustup default set|show",
"rustup toolchain update|list|remove", "rustup override set|list|show|remove",
"rustup target add|list|remove".

This will reduce the amount of clutter in --help and group
functionality that belongs together, make room for further
subcommands.

Add rustup-setup

Exactly like multirust-setup but rebranded.

Move install dir from .multirust to .rustup.

Need to make sure the metadata format can coexist with rustup.sh.

Make sure the download tracker isn't clobbered by verbose output

I suspect that verbose notification don't play well with the download
tracker but haven't looked.

Fix "invalid custom toolchain name" error

I believe this error is printed in cases where the toolchain is not custom.

Don't manipulate $PATH

I don't think multirust-rs should need to manipulate the path variable.
multirust.sh only does it as a compatibility hack.

Eliminate MULTIRUST_RECURSION_COUNT

I'm not sure what case this is catching but it shouldn't be necessary.

Edit: On second thought, this seems like a reasonable precaution.

Investigate assert in "multirust update foo"

When "foo" is not a valid dist toolchain this command asserts

Make --help look better

It prints in alphabetical order, presenting the commands in a way that
doesn't make logical sense. Converting to a subcommand-based rustup
might make this better, since there would just be fewer options.

Default to stable

Instead of having to explicitly type "multirust default stable", stable
should just be the default.

Make "multirust update" only update installed channels

Right now it updates "nightly", "stable", and "beta", plus any
tracking toolchains. Instead it should only update installed
toolchains, or if no toolchains are installed, just stable.

Use hardlinks instead of softlinks for self installation / --link-local

Softlinks need admin access on windows, which is a pain. I think
hardlinks should be fine since we are in control of all the sources
and destinations.

Add tests for non-build hosts

Installing compilers for arbitrary hosts works, but has no tests.

Set up rustup.rs

This will involve routing DNS to our proxy server and making
sh.rustup.rs and win.rustup.rs proxy to the appropriate resources.

Add download / resume caching

Add cargo fallback

When using a custom installation without Cargo, multirust should
fallback to using nightly, beta, then stable cargo.

Add GPG support

Begin work on NDK support

Right now I intend to make this a standalone library/cargo subcommand
that rustup links to, with support for acquiring NDK,
cross-deployment, and cross-testing.

Begin work on Win32/msi GUI

On windows, the installation experience needs to be better. Right now
I'm hoping that msi offers enough hooks that we can call into rustup,
presenting a familiar experience while still using the common
installation code.

Begin work in VisualRust integration

Optionally download source code along with toolchain

Rust sources comes handy when you are using racer or when you are cross-compiling etc...
It would be nice to have a possibility to download/upgrade rust sources along with the toolchain.

Cross-compiler support

It would be nice to add support for installing standard library for additional targets to support cross-compilation. Multirust (non-rs) is adding it in brson/multirust#112 (it appears to depend on new manifest format, that is not on the main distribution site yet, though).