| Message ID | 20221215073224.3061128-1-alejandro@enedino.org |
|---|---|
| State | Accepted, archived |
| Commit | 807a52686682d0d0a151ea3dadd99880feb67cc0 |
| Headers | show |
| Series | [1/2] rust: Enable building rust from stable, beta and nightly channels | expand |
On Thu, 15 Dec 2022 at 08:32, Alejandro Hernandez Samaniego <alejandro@enedino.org> wrote: > +RUST_VERSION = "1.65.0" > +SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust" Adding a manually set variable adds friction to updates. Can RUST_VERSION be set instead with a helper @function from PV? Alex
On Thu, Dec 15, 2022, 3:05 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > On Thu, 15 Dec 2022 at 08:32, Alejandro Hernandez Samaniego > <alejandro@enedino.org> wrote: > > +RUST_VERSION = "1.65.0" > > +SRC_URI += " > https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust > " > > Adding a manually set variable adds friction to updates. Can > RUST_VERSION be set instead with a helper @function from PV? > Hey Alex, I agree, and ideally yes, I tried to set it automatically to PV, but, sadly it conflicts if we try to include rust-source.inc from a non-rust recipe (This is necessary for some recipes that need to have rust source available to them) since it uses the PV set from that recipe instead. Alejandro > Alex >
On Thu, Dec 15, 2022 at 3:38 PM Alejandro Hernandez Samaniego <alejandro@enedino.org> wrote: > > > > On Thu, Dec 15, 2022, 3:05 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: >> >> On Thu, 15 Dec 2022 at 08:32, Alejandro Hernandez Samaniego >> <alejandro@enedino.org> wrote: >> > +RUST_VERSION = "1.65.0" >> > +SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust" >> >> Adding a manually set variable adds friction to updates. Can >> RUST_VERSION be set instead with a helper @function from PV? > > > Hey Alex, > > I agree, and ideally yes, I tried to set it automatically to PV, but, sadly it conflicts if we try to include rust-source.inc from a non-rust recipe (This is necessary for some recipes that need to have rust source available to them) since it uses the PV set from that recipe instead. > Is this different cargo/rust versions, or something else you have? Basically I'm on the same page as Alex - updating this recipe is already quite painful, making it any worse doesn't seem like a great idea, but I guess you could argue that rust/cargo already conflate their versions in the current usage.
On Thu, 15 Dec 2022 at 09:08, Alex Kiernan <alex.kiernan@gmail.com> wrote: > On Thu, Dec 15, 2022 at 3:38 PM Alejandro Hernandez Samaniego > <alejandro@enedino.org> wrote: > > > > > > > > On Thu, Dec 15, 2022, 3:05 AM Alexander Kanavin <alex.kanavin@gmail.com> > wrote: > >> > >> On Thu, 15 Dec 2022 at 08:32, Alejandro Hernandez Samaniego > >> <alejandro@enedino.org> wrote: > >> > +RUST_VERSION = "1.65.0" > >> > +SRC_URI += " > https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust > " > >> > >> Adding a manually set variable adds friction to updates. Can > >> RUST_VERSION be set instead with a helper @function from PV? > > > > > > Hey Alex, > > > > I agree, and ideally yes, I tried to set it automatically to PV, but, > sadly it conflicts if we try to include rust-source.inc from a non-rust > recipe (This is necessary for some recipes that need to have rust source > available to them) since it uses the PV set from that recipe instead. > > > > Is this different cargo/rust versions, or something else you have? > > Basically I'm on the same page as Alex - updating this recipe is > already quite painful, making it any worse doesn't seem like a great > idea, but I guess you could argue that rust/cargo already conflate > their versions in the current usage. > I'm referring to any recipe that could include rust-source.inc, if RUST_VERSION ?= ${PV} for example, for rust recipes that works fine because RUST_VERSION would expand to 1.65.0 today, but lets say recipe foo_1.0.1.bb needs rust-source.inc to recompile built-in crates, in that case RUST_VERSION would expand to 1.0.1 instead. While I agree its not ideal, in my opinion this approach provides more consistency with the drawback of modifying that variable on upgrades, however I also think that requiring rust-source.inc is seldom the case, hence the other option is to keep RUST_VERSION ?= ${PV} and hardcode it on every recipe that would require this flow. Alejandro > > -- > Alex Kiernan >
On Thu, 15 Dec 2022 at 17:38, Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: > I'm referring to any recipe that could include rust-source.inc, if RUST_VERSION ?= ${PV} for example, > for rust recipes that works fine because RUST_VERSION would expand to 1.65.0 today, but lets say > recipe foo_1.0.1.bb needs rust-source.inc to recompile built-in crates, in that case RUST_VERSION > would expand to 1.0.1 instead. > > While I agree its not ideal, in my opinion this approach provides more consistency with the drawback of > modifying that variable on upgrades, however I also think that requiring rust-source.inc is seldom the > case, hence the other option is to keep RUST_VERSION ?= ${PV} and hardcode it on every recipe that > would require this flow. Ok, I think what we should do first is to actually drop the version from all of the .bb file names, and set it once, inside some .inc, and probably next to SRC_URI and tarball checksum. Then this should allow a convenient scheme for including and overriding things. rust_1.65.0.bb - > rust.bb, and so on. Alex
On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > Ok, I think what we should do first is to actually drop the version > from all of the .bb file names, and set it once, inside some .inc, and > probably next to SRC_URI and tarball checksum. Then this should allow > a convenient scheme for including and overriding things. > > rust_1.65.0.bb - > rust.bb, and so on. Oh, and upstream version checks must be kept functional. It needs to both correctly report a newer version, and match the recipe version with upstream if it is already the latest. Alex
On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via > lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> > wrote: > > Ok, I think what we should do first is to actually drop the version > > from all of the .bb file names, and set it once, inside some .inc, and > > probably next to SRC_URI and tarball checksum. Then this should allow > > a convenient scheme for including and overriding things. > > > > rust_1.65.0.bb - > rust.bb, and so on. > > Oh, and upstream version checks must be kept functional. It needs to > both correctly report a newer version, and match the recipe version > with upstream if it is already the latest. > > Alex > How should I test that upstream checks are still functional?
On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego < alejandro@enedino.org> wrote: > > On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> > wrote: > >> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> >> wrote: >> > Ok, I think what we should do first is to actually drop the version >> > from all of the .bb file names, and set it once, inside some .inc, and >> > probably next to SRC_URI and tarball checksum. Then this should allow >> > a convenient scheme for including and overriding things. >> > >> > rust_1.65.0.bb - > rust.bb, and so on. >> >> Oh, and upstream version checks must be kept functional. It needs to >> both correctly report a newer version, and match the recipe version >> with upstream if it is already the latest. >> >> Alex >> > > How should I test that upstream checks are still functional? > > > Actually how would this make it any simpler?, if we remove PV from the filenames, the correct place to put the variable is in rust-source.inc since all others include it (rust-cross-canadian, rust, rust-llvm), if like I said, rust-source.inc gets included from somewhere else, wouldnt that override PV for the other recipe as well? beating the whole purpose of the change, this, or creating a new .inc file just for this seems too convoluted IMO. If changing RUST_VERSION is too problematic on every upgrade I think approach #2 its a lot simpler just specifying RUST_VERSION on other recipes since it would be very seldom used and it wont conflict with upgrades Alejandro
On Thu, 15 Dec 2022 at 19:24, Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: > Actually how would this make it any simpler?, if we remove PV from the filenames, the correct place to put the variable is in rust-source.inc since all others include it (rust-cross-canadian, rust, rust-llvm), if like I said, rust-source.inc gets included from somewhere else, wouldnt that override PV for the other recipe as well? beating the whole purpose of the change, this, or creating a new .inc file just for this seems too convoluted IMO. > > If changing RUST_VERSION is too problematic on every upgrade I think approach #2 its a lot simpler just specifying RUST_VERSION on other recipes since it would be very seldom used and it wont conflict with upgrades It's also possible to not try to reuse rust-source.inc, and just redefine the needed entries in those custom recipes. Including .inc files across layers is already something I am not comfortable with. Alex
On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: > > > > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: >> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >>> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >>> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> >>> wrote: >>> > Ok, I think what we should do first is to actually drop the version >>> > from all of the .bb file names, and set it once, inside some .inc, and >>> > probably next to SRC_URI and tarball checksum. Then this should allow >>> > a convenient scheme for including and overriding things. >>> > >>> > rust_1.65.0.bb - > rust.bb, and so on. >>> >>> Oh, and upstream version checks must be kept functional. It needs to >>> both correctly report a newer version, and match the recipe version >>> with upstream if it is already the latest. >>> >>> Alex >> >> >> How should I test that upstream checks are still functional? >> >> > Actually how would this make it any simpler?, if we remove PV from the filenames, the correct place to put the variable is in rust-source.inc since all others include it (rust-cross-canadian, rust, rust-llvm), if like I said, rust-source.inc gets included from somewhere else, wouldnt that override PV for the other recipe as well? beating the whole purpose of the change, this, or creating a new .inc file just for this seems too convoluted IMO. > > If changing RUST_VERSION is too problematic on every upgrade I think approach #2 its a lot simpler just specifying RUST_VERSION on other recipes since it would be very seldom used and it wont conflict with upgrades > Actually changing it is clearly straightforward, the problem is that upgrading the rust version is already tricky because of the need to regenerate the cargo checksums, so every extra step is something that you have to remember to do. Which leaves me wondering how introducing nightly/beta actually work with those patches? -- Alex Kiernan
On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> wrote: > On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego > <alejandro@enedino.org> wrote: > > > > > > > > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego < > alejandro@enedino.org> wrote: > >> > >> > >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> > wrote: > >>> > >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via > >>> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> > >>> wrote: > >>> > Ok, I think what we should do first is to actually drop the version > >>> > from all of the .bb file names, and set it once, inside some .inc, > and > >>> > probably next to SRC_URI and tarball checksum. Then this should allow > >>> > a convenient scheme for including and overriding things. > >>> > > >>> > rust_1.65.0.bb - > rust.bb, and so on. > >>> > >>> Oh, and upstream version checks must be kept functional. It needs to > >>> both correctly report a newer version, and match the recipe version > >>> with upstream if it is already the latest. > >>> > >>> Alex > >> > >> > >> How should I test that upstream checks are still functional? > >> > >> > > Actually how would this make it any simpler?, if we remove PV from the > filenames, the correct place to put the variable is in rust-source.inc > since all others include it (rust-cross-canadian, rust, rust-llvm), if like > I said, rust-source.inc gets included from somewhere else, wouldnt that > override PV for the other recipe as well? beating the whole purpose of the > change, this, or creating a new .inc file just for this seems too > convoluted IMO. > > > > If changing RUST_VERSION is too problematic on every upgrade I think > approach #2 its a lot simpler just specifying RUST_VERSION on other recipes > since it would be very seldom used and it wont conflict with upgrades > > > > Actually changing it is clearly straightforward, the problem is that > upgrading the rust version is already tricky because of the need to > regenerate the cargo checksums, so every extra step is something that > you have to remember to do. > > Which leaves me wondering how introducing nightly/beta actually work > with those patches? > I understand that , the checksums/patches shouldn't cause any problem since as its explained in the commit message beta/nightly builds from the exact same sources, hence patches should apply and checksums wouldn't change. I'll be sending a v2 later today Alejandro > > > -- > Alex Kiernan >
On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: > > > > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> wrote: >> >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego >> <alejandro@enedino.org> wrote: >> > >> > >> > >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: >> >> >> >> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >> >>> >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> >>> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> >> >>> wrote: >> >>> > Ok, I think what we should do first is to actually drop the version >> >>> > from all of the .bb file names, and set it once, inside some .inc, and >> >>> > probably next to SRC_URI and tarball checksum. Then this should allow >> >>> > a convenient scheme for including and overriding things. >> >>> > >> >>> > rust_1.65.0.bb - > rust.bb, and so on. >> >>> >> >>> Oh, and upstream version checks must be kept functional. It needs to >> >>> both correctly report a newer version, and match the recipe version >> >>> with upstream if it is already the latest. >> >>> >> >>> Alex >> >> >> >> >> >> How should I test that upstream checks are still functional? >> >> >> >> >> > Actually how would this make it any simpler?, if we remove PV from the filenames, the correct place to put the variable is in rust-source.inc since all others include it (rust-cross-canadian, rust, rust-llvm), if like I said, rust-source.inc gets included from somewhere else, wouldnt that override PV for the other recipe as well? beating the whole purpose of the change, this, or creating a new .inc file just for this seems too convoluted IMO. >> > >> > If changing RUST_VERSION is too problematic on every upgrade I think approach #2 its a lot simpler just specifying RUST_VERSION on other recipes since it would be very seldom used and it wont conflict with upgrades >> > >> >> Actually changing it is clearly straightforward, the problem is that >> upgrading the rust version is already tricky because of the need to >> regenerate the cargo checksums, so every extra step is something that >> you have to remember to do. >> >> Which leaves me wondering how introducing nightly/beta actually work >> with those patches? > > > I understand that , the checksums/patches shouldn't cause any problem since as its explained in the commit message beta/nightly builds from the exact same sources, hence patches should apply and checksums wouldn't change. > Sorry, now I'm properly confused, if the sources don't change, how is this beta/nightly? cargo-checksum.json is basically completely non-patch friendly, you have to fix it up every time as its based on the vendored sources in the tarball.
On Thu, 15 Dec 2022 at 22:33, Alex Kiernan <alex.kiernan@gmail.com> wrote: > On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego > <alejandro@enedino.org> wrote: > > > > > > > > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> > wrote: > >> > >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego > >> <alejandro@enedino.org> wrote: > >> > > >> > > >> > > >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego < > alejandro@enedino.org> wrote: > >> >> > >> >> > >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin < > alex.kanavin@gmail.com> wrote: > >> >>> > >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via > >> >>> lists.openembedded.org <alex.kanavin= > gmail.com@lists.openembedded.org> > >> >>> wrote: > >> >>> > Ok, I think what we should do first is to actually drop the > version > >> >>> > from all of the .bb file names, and set it once, inside some > .inc, and > >> >>> > probably next to SRC_URI and tarball checksum. Then this should > allow > >> >>> > a convenient scheme for including and overriding things. > >> >>> > > >> >>> > rust_1.65.0.bb - > rust.bb, and so on. > >> >>> > >> >>> Oh, and upstream version checks must be kept functional. It needs to > >> >>> both correctly report a newer version, and match the recipe version > >> >>> with upstream if it is already the latest. > >> >>> > >> >>> Alex > >> >> > >> >> > >> >> How should I test that upstream checks are still functional? > >> >> > >> >> > >> > Actually how would this make it any simpler?, if we remove PV from > the filenames, the correct place to put the variable is in rust-source.inc > since all others include it (rust-cross-canadian, rust, rust-llvm), if like > I said, rust-source.inc gets included from somewhere else, wouldnt that > override PV for the other recipe as well? beating the whole purpose of the > change, this, or creating a new .inc file just for this seems too > convoluted IMO. > >> > > >> > If changing RUST_VERSION is too problematic on every upgrade I think > approach #2 its a lot simpler just specifying RUST_VERSION on other recipes > since it would be very seldom used and it wont conflict with upgrades > >> > > >> > >> Actually changing it is clearly straightforward, the problem is that > >> upgrading the rust version is already tricky because of the need to > >> regenerate the cargo checksums, so every extra step is something that > >> you have to remember to do. > >> > >> Which leaves me wondering how introducing nightly/beta actually work > >> with those patches? > > > > > > I understand that , the checksums/patches shouldn't cause any problem > since as its explained in the commit message beta/nightly builds from the > exact same sources, hence patches should apply and checksums wouldn't > change. > > > > Sorry, now I'm properly confused, if the sources don't change, how is > this beta/nightly? > > cargo-checksum.json is basically completely non-patch friendly, you > have to fix it up every time as its based on the vendored sources in > the tarball. > > -- > Alex Kiernan > Yes, I was confused at first myself, the channel actually works as a build time flag, setting it to "beta" would enable the beta features that already in the source code at the time of every release, same with nightly hence why there are no extra conflicts when doing upgrades.. I actually just did the upgrade from 1.65.0 to 1.66.0 to test this (I just wasn't able to test target/native/nativesdk and all the arch variants before yours went in) and using different channels worked like a charm, no extra checksum changes other than the ones we have in our patches already. I'll be sending a v2 rebased on top of your 1.66.0 upgrade. Alejandro
On Sat, Dec 17, 2022 at 1:20 AM Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: > > > > > On Thu, 15 Dec 2022 at 22:33, Alex Kiernan <alex.kiernan@gmail.com> wrote: >> >> On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego >> <alejandro@enedino.org> wrote: >> > >> > >> > >> > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com> wrote: >> >> >> >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego >> >> <alejandro@enedino.org> wrote: >> >> > >> >> > >> >> > >> >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> wrote: >> >> >> >> >> >> >> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >> >> >>> >> >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> >> >>> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> >> >> >>> wrote: >> >> >>> > Ok, I think what we should do first is to actually drop the version >> >> >>> > from all of the .bb file names, and set it once, inside some .inc, and >> >> >>> > probably next to SRC_URI and tarball checksum. Then this should allow >> >> >>> > a convenient scheme for including and overriding things. >> >> >>> > >> >> >>> > rust_1.65.0.bb - > rust.bb, and so on. >> >> >>> >> >> >>> Oh, and upstream version checks must be kept functional. It needs to >> >> >>> both correctly report a newer version, and match the recipe version >> >> >>> with upstream if it is already the latest. >> >> >>> >> >> >>> Alex >> >> >> >> >> >> >> >> >> How should I test that upstream checks are still functional? >> >> >> >> >> >> >> >> > Actually how would this make it any simpler?, if we remove PV from the filenames, the correct place to put the variable is in rust-source.inc since all others include it (rust-cross-canadian, rust, rust-llvm), if like I said, rust-source.inc gets included from somewhere else, wouldnt that override PV for the other recipe as well? beating the whole purpose of the change, this, or creating a new .inc file just for this seems too convoluted IMO. >> >> > >> >> > If changing RUST_VERSION is too problematic on every upgrade I think approach #2 its a lot simpler just specifying RUST_VERSION on other recipes since it would be very seldom used and it wont conflict with upgrades >> >> > >> >> >> >> Actually changing it is clearly straightforward, the problem is that >> >> upgrading the rust version is already tricky because of the need to >> >> regenerate the cargo checksums, so every extra step is something that >> >> you have to remember to do. >> >> >> >> Which leaves me wondering how introducing nightly/beta actually work >> >> with those patches? >> > >> > >> > I understand that , the checksums/patches shouldn't cause any problem since as its explained in the commit message beta/nightly builds from the exact same sources, hence patches should apply and checksums wouldn't change. >> > >> >> Sorry, now I'm properly confused, if the sources don't change, how is >> this beta/nightly? >> >> cargo-checksum.json is basically completely non-patch friendly, you >> have to fix it up every time as its based on the vendored sources in >> the tarball. >> >> -- >> Alex Kiernan > > > Yes, I was confused at first myself, the channel actually works as a build time flag, setting it to "beta" would enable the beta > features that already in the source code at the time of every release, same with nightly hence why there are no extra conflicts > when doing upgrades.. > Oh I see... that makes sense now! -- Alex Kiernan
diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc b/meta/recipes-devtools/rust/rust-snapshot.inc index 2f9cdb9566..d84a3ded59 100644 --- a/meta/recipes-devtools/rust/rust-snapshot.inc +++ b/meta/recipes-devtools/rust/rust-snapshot.inc @@ -5,7 +5,8 @@ ## The version is replicated here. ## TODO: find a way to add additional SRC_URIs based on the contents of an ## earlier SRC_URI. -RS_VERSION = "1.64.0" + +SNAPSHOT_VERSION = "1.64.0" CARGO_VERSION = "1.64.0" # TODO: Add hashes for other architecture toolchains as well. Make a script? @@ -27,6 +28,6 @@ SRC_URI += " \ https://static.rust-lang.org/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components \ " -RUST_STD_SNAPSHOT = "rust-std-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu" -RUSTC_SNAPSHOT = "rustc-${RS_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu" +RUST_STD_SNAPSHOT = "rust-std-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu" +RUSTC_SNAPSHOT = "rustc-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu" CARGO_SNAPSHOT = "cargo-${CARGO_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu" diff --git a/meta/recipes-devtools/rust/rust-source.inc b/meta/recipes-devtools/rust/rust-source.inc index 0c85b4b480..a10f5c653a 100644 --- a/meta/recipes-devtools/rust/rust-source.inc +++ b/meta/recipes-devtools/rust/rust-source.inc @@ -1,4 +1,5 @@ -SRC_URI += "https://static.rust-lang.org/dist/rustc-${PV}-src.tar.xz;name=rust" +RUST_VERSION = "1.65.0" +SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust" SRC_URI[rust.sha256sum] = "2d6aa2ea3fedd55acbbd65f78349385f9daa9c14e25db7a8df5d015588eee1cf" SRC_URI:append:class-target:pn-rust = " \ @@ -7,7 +8,7 @@ SRC_URI:append:class-target:pn-rust = " \ file://0001-Add-ENOTSUP-constant-for-riscv32-musl.patch" SRC_URI:append:class-nativesdk:pn-nativesdk-rust = " file://hardcodepaths.patch" -RUSTSRC = "${WORKDIR}/rustc-${PV}-src" +RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src" UPSTREAM_CHECK_URI = "https://forge.rust-lang.org/infra/other-installation-methods.html" UPSTREAM_CHECK_REGEX = "rustc-(?P<pver>\d+(\.\d+)+)-src" diff --git a/meta/recipes-devtools/rust/rust.inc b/meta/recipes-devtools/rust/rust.inc index 956301023a..8a8dcd0b18 100644 --- a/meta/recipes-devtools/rust/rust.inc +++ b/meta/recipes-devtools/rust/rust.inc @@ -13,6 +13,9 @@ DEPENDS:append:class-nativesdk = " nativesdk-rust-llvm" S = "${RUSTSRC}" +RUST_CHANNEL ?= "stable" +PV:append = "${@bb.utils.contains('RUST_CHANNEL', 'stable', '', '-${RUST_CHANNEL}', d)}" + export FORCE_CRATE_HASH="${BB_TASKHASH}" RUST_ALTERNATE_EXE_PATH ?= "${STAGING_LIBDIR}/llvm-rust/bin/llvm-config" @@ -116,7 +119,7 @@ python do_configure() { # [rust] config.add_section("rust") config.set("rust", "rpath", e(True)) - config.set("rust", "channel", e("stable")) + config.set("rust", "channel", e(d.expand("${RUST_CHANNEL}"))) # Whether or not to optimize the compiler and standard library config.set("rust", "optimize", e(True))