| Message ID | 0dacb7cb72945f7f6886602c47111661b746cbcc.1658440640.git.jnewsome@torproject.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#56684,1/3] Bump rust 1.57 -> 1.58 | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git-branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
Sorry, forgot to change the initial subject line to [PATCH core-updates]. Happy to follow on to bump further; the latest release is 1.62.1: https://github.com/rust-lang/rust/releases 1.60 was the minimum I needed for my own project and since this is my first try contributing to guix I figured I'd try getting that in before bumping further. Each bump takes a while since I need to build one minor version at a time.
merge 54439 56684 thanks You aren't bumping the version but adding a new version of the Rust package, the old one is still there. Also, conventionally it is named updating in Guix, and a commit message is missing. For examples see the git history. Are all the intermediate steps needed, or could you reduce the number of new intermediate packages? E.g., you could try going directly from 1.57 to 1.60 without intermediate steps. If that's possible, it would be less inefficient to compile. Also, there are already patches for updating rust, see <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54439>. Please look for already existing patches before posting duplicates, to avoid double work, etc. Greetings, Maxime.
On 7/21/22 19:08, Maxime Devos wrote: > You aren't bumping the version but adding a new version of the Rust > package, the old one is still there. Also, conventionally it is named > updating in Guix, and a commit message is missing. For examples see the > git history. Thanks, got it. > Are all the intermediate steps needed, or could you reduce the number of > new intermediate packages? > > E.g., you could try going directly from 1.57 to 1.60 without > intermediate steps. If that's possible, it would be less inefficient to > compile. Good question. I assumed that each version was only compilable from the previous version based on that being how the java compiler works, and looking at the chain that's already here. From a quick look I don't see any documented policy to that effect, though, so maybe it's worth a try. > Also, there are already patches for updating rust, see > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54439>. Please look for > already existing patches before posting duplicates, to avoid double > work, etc. Oops! It looks like that is both a bit further along and more ambitious than my version. It's also been lingering for a while, while guix's version of Rust falls further behind, making me wonder if it's worth trying to move things up with something closer to my naive approach in the meantime. Still, I'll take a closer look at that and see if there's anything I can do to help that one along. Thank you for the quick feedback! -Jim
On 7/21/22 19:08, Maxime Devos wrote: > E.g., you could try going directly from 1.57 to 1.60 without > intermediate steps. If that's possible, it would be less inefficient to > compile. I dug into this a bit. The Rust bootstrapping docs say to use x.py to download the stage0 compiler. https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html x.py is a thin wrapper around bootstrap.py: https://github.com/rust-lang/rust/blob/master/x.py bootstrap.py decides what compiler to use as stage0 from stage0.json: https://github.com/rust-lang/rust/blob/master/src/bootstrap/bootstrap.py 1.62.1 was compiled with 1.61.0: https://github.com/rust-lang/rust/blob/1.62.1/src/stage0.json#L6 1.61.0 was compiled with 1.60.0: https://github.com/rust-lang/rust/blob/1.61.0/src/stage0.json#L6 1.60.0 was compiled with 1.59.0: https://github.com/rust-lang/rust/blob/1.60.0/src/stage0.json#L6 1.59.0 was compiled with 1.58.0: https://github.com/rust-lang/rust/blob/1.59.0/src/stage0.json#L6 1.58.0 was compiled with 1.57.0: https://github.com/rust-lang/rust/blob/1.58.0/src/stage0.json#L6 So it looks like each release was compiled with a compiler from one feature-release back. In my patchset, I took the highest patch-version at each feature-version, since I don't think it makes sense to include outdated patch-levels, and it should be safe. Trying to compile a release with an older compiler than it was originally compiled with seems unlikely to go well. It's not explicitly stated that it *won't* work, but it seems unlikely that it would, and would take a lot of time to verify by trial and error.
On 22-07-2022 03:33, Jim Newsome wrote: > Trying to compile a release with an older compiler than it was > originally compiled with seems unlikely to go well. It usually works fine for GCC. For Rust, it's a bit less likely given the rate at which APIs etc are added, but it's possible that once in a while a version can be skipped. Yes, the upstream docs say that X+1 is compiled with X, but this is Guix not upstream and upstream doesn't seem to care about bootstrapping much, I do not recommend just following the method from the docs as a rule or even a recommendation. (Basically the is-ought problem in another context.) > It's not explicitly stated that it *won't* work, but it seems unlikely > that it would, and would take a lot of time to verify by trial and error. ? All you need to do is, say, remove 1.58 and bootstrap 1.59 directly from 1.57 and see if that compiles and then also give current version in guix -> 1.59 a try, etc, if not try 1.57 -> 1.59.. I don't see much trial and error here, there are only a few possible combinations. Yes, it will take some time to compile (rust is big), but this only needs to be done once (or zero, the previous patch submitter tried out some combinations, those don't have to be done again) and all the potential compilation time savings will be shared to everyone, and while it is compiling you can still do other things. If it's too much for your computer if that's what you mean, I suppose it would be possible to set up a branch that tries out various combinations at ci.guix.gnu.org (it has lots of x86-64 machines). > Oops! It looks like that is both a bit further along and more > ambitious than my version. It's also been lingering for a while, while > guix's version of Rust falls further behind, making me wonder if it's > worth trying to move things up with something closer to my naive > approach in the meantime. If you mean ignoring the already existing patch and making a new one that does less, this does not incline me to review your patch and probably would be frustrating to the original patch submitter, causing your patch to linger too. What I meant is: if possible, go for the _original_ patch, improve it with parts of _your_ patch (taking the best of both) and submit that as a v2 or such, otherwise just go for the original patch and review or test it (e.g., verify it compiles reproducibly and share the hash (with "guix hash /gnu/store/the-store-item", not the hash in /gnu/store/HASH-...)). Summarised: double-work tends to cause more lingering, not less. Greetings, Maxime.
I tried and failed to bootstrap from 1.59 and 1.60 to 1.62.1 directly, the focus should be on getting Rust 1.61 to build. It's unlikely that skipping versions for bootstrapping will ever work, since the latest compiler uses nightly features which might not be present in lower versions [1]. But it's good to know that it's ok to skip versions if it does work. 1. https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm index 67dc5cdaf3..dd0f15a95c 100644 --- a/gnu/packages/rust.scm +++ b/gnu/packages/rust.scm @@ -644,10 +644,14 @@ (define rust-1.56 rust-1.55 "1.56.1" "04cmqx7nn63hzz7z27b2b0dj2qx18rck9ifvip43s6dampx8v2f3")) (define rust-1.57 + (rust-bootstrapped-package + rust-1.56 "1.57.0" "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim")) + +(define rust-1.58 (let ((base-rust (rust-bootstrapped-package - rust-1.56 "1.57.0" - "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim"))) + rust-1.57 "1.58.1" + "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8"))) (package (inherit base-rust) (outputs (cons "rustfmt" (package-outputs base-rust))) @@ -790,7 +794,7 @@ (define rust-1.57 ;;; intermediate rusts are built for bootstrapping purposes and should not ;;; be relied upon. This is to ease maintenance and reduce the time ;;; required to build the full Rust bootstrap chain. -(define-public rust rust-1.57) +(define-public rust rust-1.58) (define-public rust-src (hidden-package
From: Jim Newsome <jnewsome@torproject.org> --- gnu/packages/rust.scm | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) base-commit: 5dfc6ab1ab292b87ceea144aa661d0e64c834031