After installing rust with rustup, I started getting this warning from Emacs:
You appear to be setting environment variables (“PATH”) in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .profile, .bash_profile or .zshenv. Refer to your shell’s man page for more info. Customize ‘exec-path-from-shell-arguments’ to remove “-i” when done, or disable ‘exec-path-from-shell-check-startup-files’ to disable this message.
I tried out the new target support and found it less pleasing then I think it could be. I’m not sure if thats a rustup, a cargo, a rustc or a general computers ¯\_(ツ)_/¯ problem.
I know that target add basically just download the artifacts for the platform in question, but the biggest problem is getting a proper toolchain set up. While it fixes the “i need the compiler to run for ages until I have all my stdlibs”-problem, it doesn’t solve the “cross-compile out of the box” problem. It’s a huge step in the right direction, though :).
So on OS X and any other platform that uses clang by default, none of the common targets work easily out of the box, because they don’t work with clang. I do have to cross-compile gcc toolchains lying around, but from a users perspective, it would be great if at some place the whole toolchain would catch that and provide pointers to where to find the appropriate tooling.
I’m not sure what you are pointing at, installing cross-compile toolchains and using them is possible on many platforms through their respective package managers.
I have never had a pleasant experience trying to cross compile anything. Really, I should have left “Rust” out of it; cross-compilation just sucks. But more than that, I used a picture of clippy. If that’s not enough to indicate I’m being deliberately facetious, I just give up.
I understand that you facetious, I just didn’t get the point ;).
There are actually pleasant experiences to be had in that space. e.g. netbsd ships with a very clean cross-compile toolchain :). But defining an interface to these toolchains might be worthwhile even if they suck.
Forgive the tangent here, but in my opinion, the "cross-compiling" to x86_64-unknown-linux-musl in multirust is really really good. I'm not sure how it could be easier.
I like the simplicity of this mode of operation, but it doesn't feel like it's the exact right thing to do. I think my preference would be to have a bare "rustup" just print usage (just like multirust, cargo, and rustc). I don't upgrade toolchains often enough for me to get the benefit of not having to type a few extra keystrokes.
But as designed, both rustup and rustup update seem to work well as described.
Install went smoothly. Above comments and suggestions really good.
I think I’d like rustup show to output hash and version of rustc, if that makes sense, and currently installed targets, or add a show to targets rustup target show.
I see now that target list adds whether it was installed, but o didn’t notice this at first, and I expected a little more info in rustup show I guess.
On another note, looks like you’re getting ready for special toolchains with rustup toolchain link which makes me really excited, and also wonder:
Will there be support for bundling static linkers with targets? I believe modulo legal concerns, and some other obscure details, the linking stage in the pipeline is the only stopping point right now from having potentially the most amazing cross compiling system I’ve ever seen
Will there be support for adding a linker to a toolchain/target, or how could we do this manually, so that it defaults to this linker when rustc or cargo is invoked with the target which it can link?
Again, this is awesome, really excited to see this fleshing out in a principled way, amazing work!
upgrade: I am never going to remember that there is no toolchain add command. I would really appreciate having toolchain add as either an alias or the primary way for adding a new toolchain. I think keeping upgrade as a top-level command for upgrading existing stuff is fine, especially if you think of it as upgrading both toolchains and targets.
default: with no other arguments, this should show the current default.
show: I couldn’t find this at first because I expected it to be a rustup override subcommand. Could be renamed or aliased to override show, or just override with no other arguments. I would also consider renaming the top-level subcommand to status and potentially adding more information to it over time.
override add: I appreciate the consistency, but I also kind of expected this to be override set because you can use it to change an existing override.
override add and override remove: Should take an optional directory argument, so you can e.g. remove overrides from old directories that no longer exist.
override list: The output is hard to read (for humans). Many of the commands could probably use separate modes for human-readable vs. machine-readable output (with human-readable as default).
toolchain list: This only lists installed toolchains. Could we get a --all flag to show available toolchains too? And highlight the default and installed ones, like in target list.
target list: Unlike toolchain list, this lists all available targets by default. This was confusing. The default behavior should be consistent between these.
Hm. @Diggsey had multirust-rs installing path modifications to ~/.profile and I changed it because ~/.profile is only read for login shells, and that seemed wrong since most shells are not login shells. I'm happy to change this to do the right thing, but I'd like to understand better why it's ok not to set the PATH for non-login shells. Issue.
There's more work to come next quarter on installing the native toolchain components. We'll probably start with the android NDK.
Yay!
I've heard this feedback from others too. I intend to make rustup just print help, and move the update-everything feature to rustup update.
I think this makes sense too. Here's an issue. My only reservation is diverging from the behavior of rbenv, which just prints a 'version' and a reason it was selected, and is easily machine-parable.
@mb4 The plan here for the future is that when you rustup target add rustup will give you the option to automatically acquire the right software for your combination of host platform and target platform. So when you install e.g. arm-linux-androideabi, rustup will download the NDK, stash it somewhere, and configure the associated Rust toolchain to use it correctly.
I haven't thought of this question before, but it makes sense to focus specifically on linker customization, not just generally configuring the native toolchain. A part of this hypothetical future ndk-managament could be the ability to specify a custom linker.
OK. Makes sense. The only reasons I haven't added yet are because redundancy, and because install is potentially a better word than add, and because does an add do an upgrade implicitly, or is it just add, and we also need rustup toolchain update?
Then should the same be true of override? override uses subcommands so should it instead be rustup override show? Then what about default again? Should it be default show?
This was a tough one for me. It does logically belong under rustup override show, and in multirust this was even called multirust show-override. In rbenv though it is called rbenv version, which is pretty sweet. For reasons I didn't want to use the word 'version' in rustup so I picked 'show'.
I also considered calling this 'status' and as you suggest putting more info in it, but rbenv does not do that. Furthermore, the word 'show' can be more easily reused for other purposes: toolchain show, override show.
Maybe instead I should put the existing feature in rustup override show, and save rustup status for more broader status (like rustup update vs. rustup toolchain update or rustup update nightly.
Yep! But then you probably want to call 'remove' 'unset' ('set' and 'unset' are what rbenv use).
Yes, yes it is. Programs that don't have a manifest or whose manifest says they are for a really old version of Windows, if they have a name that suggests them being an installer, Windows will expect them to actually install something. Since I assume this rustup setup isn't actually an installer but just copies some files around, Windows thinks it might have failed.
The smartscreen filter thing just means you need to get a certificate and sign the installer with that.
Also, the website doesn't let me download rustup if I don't enable Javascript, It just says "I don't recognize your platform." with no links to manually choose what to download.
Also I'm still opposed to having a dot directory in my home folder on Windows. Both for rustup and for cargo.
I’ve completely replaced multirust with rustup since the day it was announced here, and it’s great so far. Cargo’s cross-compile tests started passing with just rustup target add i686-unknown-linux-gnu.
Yes, it is. Windows has a shim that everything with setup or install in its name will get:
elevated privileges and
the dialog about not installing correctly if it does not actually write anything to Program Files.
I believe the utility does not actually need elevated privileges (everything gets installed in user profile, doesn't it?), in which case it would be easiest to just rename it.
Note that the magic words are setup and install, but notinst, so I would suggest inst or init; set_up will probably work too.
