-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustbuild: don't create a source tarball when installing #42109
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
src/bootstrap/step.rs
Outdated
@@ -789,6 +786,10 @@ pub fn build_rules<'a>(build: &'a Build) -> Rules { | |||
.dep(move |s| s.name("tool-build-manifest").target(&build.config.build).stage(0)) | |||
.run(move |_| dist::hash_and_sign(build)); | |||
|
|||
rules.install("install", "path/to/nowhere") | |||
.dep(|s| s.name("default:dist")) |
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 I was thinking that this is where we could apply the fix, not depending on default:dist
? Ideally the install
target doesn't depend on any source tarball, so that stage is just skipped entirely. Does that make sense?
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.
I was thinking of that too in the first place, but the install.sh generation is done as part of the dist, so it would be far less trivial.
Still doable though if you think that's a good idea.
Btw the next step could be splitting that into several rules such as install-tool-cargo or such. Just wanted to see if it was a good idea first.
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 yeah so we'll definitely still need to dist things like libstd/librustc, but we just don't need to dist the source tarball, right?
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.
Right.
Since the rls README recommands adding rls, rust-analysis and rust-src to rustup, I figured rust-src was useful for it to work properly, so I didn't want to drop that part entirely. That's why I kept it as is and just put the actual full fist tarball creation (with the call to cargo vendor and so forth) in a conditional.
With these commits, install doesn't depend on "default:dist" anymore, and it doesn't require the combined installer anymore either. |
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.
Looking great! I think there may be some trickery around the flags on the steps though. You may want to copy over stuff like host(true)
and only_host_build(true)
from the dist
steps, as I think that'll be necessary to handle ./x.py install
with a cross-compiling setup.
src/bootstrap/step.rs
Outdated
.dep(|s| s.name("dist-src")) | ||
.run(move |s| install::Installer::new(build).install_src(s.stage)); | ||
rules.install("install-rustc", "src/librustc") | ||
.default(true) |
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.
I think this may need some combination of .host(true)
perhaps?
src/bootstrap/dist.rs
Outdated
// Create the version file | ||
write_file(&plain_dst_src.join("version"), build.rust_version().as_bytes()); | ||
|
||
if let Subcommand::Dist { .. } = build.flags.cmd { |
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.
Is this new clause still necessary?
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.
Yes. This part generates both the rust-src component installer and the full source tarball with vendorized deps, etc, and we only want the former for install
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.
Actually I might have found a way not to require that anymore.
I'm doing some testing, will finish that up tomorrow.
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.
It's definitely still needed.
I tried not to depend on dist-* anymore and to just call the script method from rust-installer, but then it's missing some files like the manifest, so dealing with that would basically end up duplicating dist.
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.
Hm so just to make sure I understand this, during a normal ./x.py install
this step isn't invoked right because the rust-src component is optional?
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.
Ah ok, are you thinking of supporting an extended build without cargo-vendor?
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.
Yes, exactly.
./x.py dist
would run cargo-vendor and create all the proper tarballs for disribution
./x.py install
would just install the components without bothering with the vendoring and the full source tarball
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.
Hm ok so if we want this use case to work then we may need to dig a little deeper. My intention was to not have a clause such as this because it means that a "source tarball" is now context-dependent if you're installing source or not. Ideally every single source tarball we produce is the same, regardless of the context.
IIRC, though, the rust-src component is a stripped down version of the actual source tarball, right? (i.e. it doesn't contain the vendor dir anyway?) If that's the case maybe we could separate these code paths so the rust-src
component installation doesn't generate a vendor dir but the source tarball itself still unconditionally does?
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.
The contents of "source tarball" is not context dependent, its existence is, fwiw. The if block contains the whole tarball generation, not just the vendoring.
I can try to split that in a separate function.
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 sorry about that! I think I misread this.
In that case yeah want to just split this up into two functions and two steps? That way the install step could depend on the right one and dist would depend on both. Sorry for the confusion!
Would it be a good idea to instantiate only one Installer? |
Nah no worries, the impact here should be quite minor. |
This part should be better now! |
Awesome looks great to me! Want to squash and I'll r+? |
only create source tarball for the Dist subcommand mark install rule as default for Kind::Install split install-docs split install-std factor out empty_dir handling split install-cargo split install-analysis split install-src rework install-rustc properly handle cross-compilation setups for install use pkgname in install split plain source tarball generation from rust-src dist document src-tarball in config.toml.exmaple Signed-off-by: Marc-Antoine Perennou <[email protected]>
rebased and squashed |
@bors: r+ |
📌 Commit 150d644 has been approved by |
rustbuild: don't create a source tarball when installing This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command. This will allow splitting install in a few rules if we want as it's done for other phases.
Signed-off-by: Marc-Antoine Perennou <[email protected]>
Signed-off-by: Marc-Antoine Perennou <[email protected]>
That should fix #42173 |
@bors: r+ |
📌 Commit 53ae00a has been approved by |
rustbuild: don't create a source tarball when installing This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command. This will allow splitting install in a few rules if we want as it's done for other phases.
rustbuild: don't create a source tarball when installing This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command. This will allow splitting install in a few rules if we want as it's done for other phases.
Signed-off-by: Marc-Antoine Perennou <[email protected]>
Oh, I somehow missed the second part of distcheck in my previous fix. |
@alexcrichton want me to squash the recent fixes? Distcheck is fine locally now and nothing else seems to need a dependency update |
@bors: r+ Nah looks good to me, thanks for the quick fixes! |
📌 Commit d0ea705 has been approved by |
rustbuild: don't create a source tarball when installing This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command. This will allow splitting install in a few rules if we want as it's done for other phases.
rustbuild: don't create a source tarball when installing This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command. This will allow splitting install in a few rules if we want as it's done for other phases.
☀️ Test successful - status-appveyor, status-travis |
This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command.
This will allow splitting install in a few rules if we want as it's done for other phases.