-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Update to the Rusty rust-installer #41843
Conversation
All of the generated dist tarballs look sane to me, and seem to install manually just fine. However, this does fail one bootstrap test:
I think that may just be a reflection of the fact that "dist" now depends on a rust-based tool, but I'd like a second opinion before I go clobbering that test into submission. cc @brson This re-introduces the file-sorting optimization in the tarballs, so if there's a way to test rustup against this, we should. I'm now writing all directory names in the tarball before the sorted file list, so hopefully that will be enough to avoid a recurrence of rust-lang/rustup#1092. |
src/bootstrap/step.rs
Outdated
@@ -755,6 +766,7 @@ pub fn build_rules<'a>(build: &'a Build) -> Rules { | |||
.host(true) | |||
.only_host_build(true) | |||
.dep(|s| s.name("tool-cargo")) | |||
.dep(|s| s.name("tool-rust-installer").stage(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh here (and in other steps) I think you'll want to lock the Step
here to build.config.build
for both the host and the target triple, that's the architecture we want to build the tool for (as we're running it here, not packaging it)
If you've got a checkout locally you may also want to run |
☔ The latest upstream changes (presumably #41846) made this pull request unmergeable. Please resolve the merge conflicts. |
77875b3
to
8eaff4d
Compare
|
@bors: r+ How exciting! |
📌 Commit 8eaff4d has been approved by |
It looks like this fails on WIndows @bors r- https://ci.appveyor.com/project/rust-lang/rust/build/1.0.3199/job/21w6ovbl6nycrmcv |
Hmm, OK, I'll have to take a closer look at what |
OK, I removed most of the |
@bors: r+ |
📌 Commit 2729b71 has been approved by |
…richton Update to the Rusty rust-installer This updates the rust-installer submodule to the new version written in Rust (rust-lang/rust-installer#62), now moved to `src/tools/rust-installer` and invoked in `dist.rs` as a cargo-based tool command. All of the former shell-script invocations now invoke the tool, otherwise keeping the same arguments as before. As a small bonus, `rustc-src` now also uses the same tarball generator, so it gains a smaller `.tar.xz` too. Fixes rust-lang#41569. r? @alexcrichton
1 similar comment
Hmm, it's a link error? I'm confused by this, as it built fine in the previous appveyor run, and I didn't change rust-installer itself since then. Has something else changed in the Windows build system?
|
Oh I think that's a legitimate bug with the lzma-sys crate, it's right now apparently not compatible with |
Looks like a fix was indeed needed, once that passes CI I'll publish to crates.io and you can update the dep here |
@alexcrichton I noticed that alexcrichton/xz2-rs#2 changed the VS version, which hasn't reached crates.io yet. Will that be a problem here? |
I suspect this failure in the rollup was caused by this PR. @bors r-
|
Do you have the full appveyor log? or a link to that build? |
Oh, I see. This is due to an off-hand optimization I made in rewriting I don't love that sort of implicit expectation, but I'll go revert that part in rust-installer with a comment about this behavior. The alternative is to just extract them again explicitly -- which is also tempting. |
Hmm, or they could get components from the combined location. I think I like that better, if it works... |
OK, updated rust-installer to stop moving component dirs. cc @Keruspe the submodule update now includes your changes too. |
☔ The latest upstream changes (presumably #41987) made this pull request unmergeable. Please resolve the merge conflicts. |
@cuviper Looks like you'll need to rebase to fix the merge conflict on Cargo.lock. |
Also let me warn you in advance about alexcrichton/xz2-rs#4 |
This gives us an extra rustc-src.tar.xz, which is 33% smaller than the .tar.gz!
There's no shell interpreting the file paths under the new Rusty rust-installer, so we don't need to use `sanitize_sh` for it. Plus, the drive-letter transformation is actually harmful for the now-native Windows rust-installer to understand those paths.
77b68ad
to
1e709fc
Compare
OK, rebased, and I squashed the trivial dependency fixups. I have included lzma-sys 0.1.3 as suggested. |
@bors: r+ |
📌 Commit 1e709fc has been approved by |
Update to the Rusty rust-installer This updates the rust-installer submodule to the new version written in Rust (rust-lang/rust-installer#62), now moved to `src/tools/rust-installer` and invoked in `dist.rs` as a cargo-based tool command. All of the former shell-script invocations now invoke the tool, otherwise keeping the same arguments as before. As a small bonus, `rustc-src` now also uses the same tarball generator, so it gains a smaller `.tar.xz` too. Fixes #41569. r? @alexcrichton
☀️ Test successful - status-appveyor, status-travis |
This updates the rust-installer submodule to the new version written in Rust (rust-lang/rust-installer#62), now moved to
src/tools/rust-installer
and invoked indist.rs
as a cargo-based tool command. All of the former shell-script invocations now invoke the tool, otherwise keeping the same arguments as before.As a small bonus,
rustc-src
now also uses the same tarball generator, so it gains a smaller.tar.xz
too.Fixes #41569. r? @alexcrichton