download bootstrap binary from ci by Shourya742 · Pull Request #140069 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
r? @onur-ozkan
rustbot has assigned @onur-ozkan.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Status: Awaiting review from the assignee but also interested parties.
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
labels
This comment has been minimized.
I don't have space to review this.
r? Kobzol (feel free to reroll)
This comment has been minimized.
This comment has been minimized.
this misses the point. the point of precompiled bootstrap is to allow us not to require python at all. if we use the python script to download, all we gain is slightly faster compiles at the cost of a lot more complexity.
oh, apparently that’s not what i said two years ago. oops.
probably just ignore anything i say then, i don’t have context on this anymore.
Removing the Python logic is an ongoing process. But even if we get rid of most of the Python scripts, we will still need something that will be responsible for setting up bootstrap. That something can be either shell scripts (but that would suck, as it's not cross-platform), some small amount of Python or e.g. a Rust Cargo script. We could even distribute bootstrap through rustup. That's still up to debate, I guess.
Should we go ahead and close this, along with the upstream issue?
Removing the Python logic is an ongoing process. But even if we get rid of most of the Python scripts, we will still need something that will be responsible for setting up bootstrap. That something can be either shell scripts (but that would suck, as it's not cross-platform), some small amount of Python or e.g. a Rust Cargo script. We could even distribute bootstrap through rustup. That's still up to debate, I guess.
I was planning to keep shell scripts as tiny as possible, (e.g., setting up the bootstrap toolchain and using it to run a program that configures and runs bootstrap).
So, after the migration work, it would look like this:
- Handle bootstrap compiler download, extraction and copying tasks with shell script
- Run (from shell script) a Rust program (which is a replacement of most of the Python code) that configures bootstrap and runs it
- The bootstrap workflow, nothing changes here
I am still waiting for #119899, I don't want to deal with 2 major tasks simultaneously. I did a bit of work on Python removal before (I almost done the most logic of 1. above), I will rebase it and continue from there.
Personally, I am not particularly interested in this work. That is another reason I did not want to review it as I do not feel comfortable engaging with it. It's either not worth, or at
I can't speak for other bootstrap team members, but I kinda don't want to download a precompiled bootstrap from CI in addition to CI LLVM and CI rustc. IME, for library and compiler workflows, building bootstrap is relatively fast (approx. 22 seconds on a dev desktop fresh). I feel very iffy about downloading bootstrap itself, because if this logic has issues then it becomes very very nasty to debug, what bootstrap binary other contributor runs on their system does not necessarily match what's built from HEAD...
Something like what Onur proposed seems much less risky to me, at least.
FWIW, we already have Python scripts that predownload Rust and Cargo that is used to build bootstrap, so in terms of download logic bugs, that situation wouldn't become worse here.
We have discussed this sometime in the past on Zulip, but what I would like the most is to simply say that you need to have a recent-ish Rust compiler available locally in order to build rustc. At this day and age, with rustup and Rust compilers being available in distro repositories, I don't think that it's too weird of a requirement (today you need to have a shell interpreter and Python available).
If we consider this requirement to be fine, then we can simply redirect x to first do a cargo build of bootstrap, and then do everything in bootstrap, without requiring any separate shell/Python/Rust scripts. We would also need to avoid bootstrap's compilation to depend on the contents of bootstrap.toml, but I think that's a good idea anyway, it should only contain runtime data. It's quite annoying when I change something (like disable warnings) in bootstrap.toml and bootstrap gets recompiled because of that.
Labels
Status: Awaiting review from the assignee but also interested parties.
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)