Point PATH to toolchain/bin on Windows

[SpaceManiac]

Yes, this again. On Windows, LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not obeyed, and .dlls are searched for in the PATH (and located in the bin directory).

This becomes relevant when attempting to link to a rustc_private crate such as libsyntax.

Prior art: brson/multirust#99

[brson]

This env_var::set_path function prepends the path, which (as you mention in the multirust PR) will cause cargo to invoke rustc directly. This would break current and future features where rustup expects to intercept calls to rustc.

Related to this. Right now rustup requires either PATH to be set or RUSTC to be set in the environment, to ~/.cargo/bin, in order for cargo to find rustc. Normally this is set up by the installer but there are scenarios where you might want to run rustup without. I'm not sure this is the best thing to do, and rustup in proxy mode might instead set the PATH to include ~/.cargo/bin to ensure cargo finds the right one (it used to).

What if we prepended ~/.cargo/bin to the PATH and appended $toolchain/bin (on all platforms, for consistency)? With a comment like

Prepend $CARGO_HOME/bin so that cargo finds the rustc proxy even if it's not in PATH. Append $toolchain/bin so that, on Windows, build scripts that invoke plugins can find the rustc dylibs.

(I see that last time I wanted to prepend this path instead, but don't recall the reasoning).

cc @Diggsey I've tweaked, and broke and unbroke these env vars a lot. Seeing if you have opinions.

[brson]

Or alternately we might append both, but in that order. By appending we could let users influence the binary lookup with PATH, by prepending we make a stronger effort to force cargo to find the right rustc.

[Diggsey]

I can't think of a better option. Appending both paths but in the correct order seems like the closest we're going to get.

[Diggsey]

(if the wrong rustc is on the PATH earlier, then that's a configuration error anyway, and rustc wouldn't be proxied correctly to start with, so I'm not too worried about supporting that usecase, whereas I am interested in supporting an intentional override via PATH)

[SpaceManiac]

I'm of course fine with whatever you think the correct behavior for the rest of the system is, as long as $toolchain/bin ends up somewhere in PATH.

[brson]

@SpaceManiac let's rename set_path to prepend_path and add another method append_path, then use that to first append utils::cargo_home, then $toolchain/bin.

[SpaceManiac]

There's a second pass, append_path is a little awkward (especially in the error handling) due to its need to work with a list of paths, but it should be functional.

[brson]

lgtm. Thanks. Just waiting for the build to pass.

[oli-obk]

The appveyor build was cancelled, can someone restart it?

[brson]

Thanks @SpaceManiac!