5 ms·

Any word on linux-musl builds so that you can use official rust builds on alpine or void linux? Same question for FreeBSD builds.

by cm3 11y ago

steveklabnik 11y ago
Regarding BSDs: https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-installed-on-arm-linux-netbsd-and-freebsd-using-rustup-multirust/5383 https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-ins... We are still working on musl as a host, it's not there yet, in my understanding. Cross-compiling to it should be easy, but that doesn't help much if you're on Alpine.
- cm3 11y ago
  So, I should be able to run rustup on FreeBSD 10/11 and it will install 1.8, right? If so, excellent!
  - steveklabnik 11y ago
    I believe so, though I haven't tried it myself, I just know of that post :)
- cm3 11y ago
  Wait, is this a different rustup than rustup the shell script?
  - cm3 11y ago
    Looks like, and I take it that there are builds for freebsd and netbsd which the bootstrapping shell script will fetch and then have the rustup.rs executable for freebsd ready. Is that correct?
  - steveklabnik 11y ago
    Yes. I might as well take the time to elaborate on the history here. In the beginning, there was rustup. And it was good. Then, Rust matured, and we started the release channels. Now there wasn't just "Rust 0.9", there was Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built to handle that. And so, multirust was born. mutlirust was/is a bash-based shell script that wraps up rustup and gives you the ability to manage multiple installs of Rust. And fun things like "this project uses rust stable, but this project uses Rust 1.1" and "please update every Rust I have installed". Stuff like that. But it was a bash script. Nobody knew that this whole Bash in Windows thing was happening. And we already have a perfectly good, general purpose programming language that runs on all the platforms Rust supports: Rust! So the multirust-rs project was begun, to re-write multirust in Rust. Once that started to become closer to being finished, we took a step back, looked holistically at all of this, and thought "If we started from scratch, what would we do?" https://public.etherpad-mozilla.org/p/rustup-new-experience https://public.etherpad-mozilla.org/p/rustup-new-experience And so, "rustup" was born. It's pretty much multirust.rs, but without trying to mimic the old multirust itself. There's still lots of stuff to do before it's ready to become the default way you manage rust installations: https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316 https://internals.rust-lang.org/t/beta-testing-rustup-rs/331... and https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3Aissue+is%3Aopen+label%3A%22initial+release%22 https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3... And of course, many people will want to use their system package manager too. Choice is good. They also play together. But that's for another post, this one is already getting long. You can find rustup here: https://www.rustup.rs/ https://www.rustup.rs/
    - cm3 11y ago
      Thanks for the backstory. It's always much preferable to have as few dependencies for bootstrapping a platform as possible. Therefore, this is a good development. Similarly, I'm hopeful the Python requirement in the new Rust based build system for rust itself will be removed sooner than later. Building Rust already requires Rust, so what's more logical than replacing the Python part with Rust. It will definitely be easier to get going than having to install some Python modules first. Same improvement should happen in servo's build system which since a few months or a little longer depends on virtualenv.
  - deleted 11y ago
    [deleted]
- cm3 11y ago
  So, rustup should ask before modifying ~/.profile, this is what opam does. Also, it'd be great to have a directory listing for the rustup-setup executables, because I don't run random shell scripts piped from curl, so I had to reconstruct the URL for what the shell script would have downloaded. Anyway, I'm glad multirust functionality is getting mainlined, because it's a PITA to build many things, like for example rustup.rs, which require nightly rust features.
- cm3 11y ago
  Hmm, weird that there's no ~/.rustup, where all the downloaded toolchains should be stored. Wondering where they are for real...
  - steveklabnik 11y ago
    It's still in ~/.multirust for now, it wasn't changed yet. Beta! You might want to join #rust-tools on mozilla's IRC for better help, I bet this is offtopic for a lot of HN.
    - cm3 11y ago
      Yeah the README has it wrong. https://github.com/rust-lang-nursery/rustup.rs/blob/master/README.md#environment-variables https://github.com/rust-lang-nursery/rustup.rs/blob/master/R...
  - cm3 11y ago
    Aah, the README is wrong, figured out it's ~/.multirust.

Any word on linux-musl builds so that you can use official rust builds on alpine or void linux? Same question for FreeBSD builds.

by cm3 11y ago

Any word on linux-musl builds so that you can use official rust builds on alpine or void linux? Same question for FreeBSD builds.

steveklabnik 11y ago

Regarding BSDs: https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-installed-on-arm-linux-netbsd-and-freebsd-using-rustup-multirust/5383 https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-ins... We are still working on musl as a host, it's not there yet, in my understanding. Cross-compiling to it should be easy, but that doesn't help much if you're on Alpine.

cm3 11y ago
So, I should be able to run rustup on FreeBSD 10/11 and it will install 1.8, right? If so, excellent!
- steveklabnik 11y ago
  I believe so, though I haven't tried it myself, I just know of that post :)
cm3 11y ago
Wait, is this a different rustup than rustup the shell script?
- cm3 11y ago
  Looks like, and I take it that there are builds for freebsd and netbsd which the bootstrapping shell script will fetch and then have the rustup.rs executable for freebsd ready. Is that correct?
- steveklabnik 11y ago
  Yes. I might as well take the time to elaborate on the history here. In the beginning, there was rustup. And it was good. Then, Rust matured, and we started the release channels. Now there wasn't just "Rust 0.9", there was Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built to handle that. And so, multirust was born. mutlirust was/is a bash-based shell script that wraps up rustup and gives you the ability to manage multiple installs of Rust. And fun things like "this project uses rust stable, but this project uses Rust 1.1" and "please update every Rust I have installed". Stuff like that. But it was a bash script. Nobody knew that this whole Bash in Windows thing was happening. And we already have a perfectly good, general purpose programming language that runs on all the platforms Rust supports: Rust! So the multirust-rs project was begun, to re-write multirust in Rust. Once that started to become closer to being finished, we took a step back, looked holistically at all of this, and thought "If we started from scratch, what would we do?" https://public.etherpad-mozilla.org/p/rustup-new-experience https://public.etherpad-mozilla.org/p/rustup-new-experience And so, "rustup" was born. It's pretty much multirust.rs, but without trying to mimic the old multirust itself. There's still lots of stuff to do before it's ready to become the default way you manage rust installations: https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316 https://internals.rust-lang.org/t/beta-testing-rustup-rs/331... and https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3Aissue+is%3Aopen+label%3A%22initial+release%22 https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3... And of course, many people will want to use their system package manager too. Choice is good. They also play together. But that's for another post, this one is already getting long. You can find rustup here: https://www.rustup.rs/ https://www.rustup.rs/
  - cm3 11y ago
    Thanks for the backstory. It's always much preferable to have as few dependencies for bootstrapping a platform as possible. Therefore, this is a good development. Similarly, I'm hopeful the Python requirement in the new Rust based build system for rust itself will be removed sooner than later. Building Rust already requires Rust, so what's more logical than replacing the Python part with Rust. It will definitely be easier to get going than having to install some Python modules first. Same improvement should happen in servo's build system which since a few months or a little longer depends on virtualenv.
- deleted 11y ago
  [deleted]
cm3 11y ago
So, rustup should ask before modifying ~/.profile, this is what opam does. Also, it'd be great to have a directory listing for the rustup-setup executables, because I don't run random shell scripts piped from curl, so I had to reconstruct the URL for what the shell script would have downloaded. Anyway, I'm glad multirust functionality is getting mainlined, because it's a PITA to build many things, like for example rustup.rs, which require nightly rust features.
cm3 11y ago
Hmm, weird that there's no ~/.rustup, where all the downloaded toolchains should be stored. Wondering where they are for real...
- steveklabnik 11y ago
  It's still in ~/.multirust for now, it wasn't changed yet. Beta! You might want to join #rust-tools on mozilla's IRC for better help, I bet this is offtopic for a lot of HN.
  - cm3 11y ago
    Yeah the README has it wrong. https://github.com/rust-lang-nursery/rustup.rs/blob/master/README.md#environment-variables https://github.com/rust-lang-nursery/rustup.rs/blob/master/R...
- cm3 11y ago
  Aah, the README is wrong, figured out it's ~/.multirust.