Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow changing the default toolchain for each channel #1481

Closed
CryZe opened this issue Aug 16, 2018 · 3 comments
Closed

Allow changing the default toolchain for each channel #1481

CryZe opened this issue Aug 16, 2018 · 3 comments

Comments

@CryZe
Copy link

CryZe commented Aug 16, 2018

I set my default toolchain to the stable-x86_64-pc-windows-msvc toolchain from the gnu one, but if I type cargo +nightly it still defaults to the nightly-x86_64-pc-windows-gnu toolchain. Setting the default should either affect all channels or there should be a way to select the specific channel you want to change.

This may already be a thing, but it at least doesn't seem to be documented in the CLI.

@CryZe
Copy link
Author

CryZe commented Aug 16, 2018

Actually, looking at it further, there seems to be a default host, but it's not clear how to change that. (Apparently you can manually change it in the settings.toml)

@rukai
Copy link

rukai commented Sep 20, 2018

Just got tripped up by this.
In my case I have a rust-toolchain file which specifies which nightly release to use.
The correct nightly release was being used but it was for the wrong toolchain (gnu instead of msvc) It took a long time to realize this was my problem.
I was running rustup default stable-pc-windows-msvc expecting this to change the toolchain to use msvc but it wasn't.

After finding this issue I was able to follow CryZe's instructions and inspect settings.toml to find the setting default_host_triple = "x86_64-pc-windows-gnu" that was causing the gnu toolchain to still be used. Manually changing it to msvc resolved the issue. The file also contained the setting default_toolchain = "nightly-x86_64-pc-windows-msvc" appears to be correct.

I'm not sure what command does change this setting, but I think it should be in sync with the current toolchain. i.e. running rustup default stable-pc-windows-msvc should change it to msvc

@rbtcollins
Copy link
Contributor

The issue here is a flexability vs ease of use one.

Ease of use: if you use a particular host, we switch you over to that everywhere, and things just happen.

Flexability: everything is explicit, and you can have stable-x86_64-pc-windows-gnu, stable-x86_64-pc-windows-mvsc, nightly-x86_64-pc-linux-gnu, beta-i686-pc-windows-msvc all installed at once, and rustup will support you in doing that.

The underlying confusion you're facing here is the idea that a channel is unique: it is not - you can have multiple instances of stable installed on your machine at once as my example shows.

Should we permit that? Perhaps not. Most folk don't need it. But folk on linux machines can use OS personalities to do this and then run binaries from vastly different platforms (like ARM on x86 via qemu) , which can make building for other devices without cross-compiling very convenient. (Avoiding cross compiling can be useful to allow test suites to run).

If you have suggestions for making this more useful friendly or more clear, we'd certainly love to hear them, but for now I think the tradeoff is probably about right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants