[PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

From: Alejandro Hernandez Samaniego <alejandro@enedino.org>

Rust follows the train release model via the stable, beta and nightly channels,
by default we build rust from the stable channel, however there are certain
features which are only available in the beta or nightly channels.

Make these channels available by setting a RUST_CHANNEL variable which defaults
to stable making this change transparent to the user.

The snapshot version used by rust during its compilation wont necessarily match
the version being built, specially if were building from an unstable channel,
to avoid confusion rename this to SNAPSHOT_VERSION and use RUST_VERSION for the
version to be built.

Append -beta or -nightly to rusts PV for signature awareness.

It is important to note that this does not build rust from the beta/nightly
published tarball (which today build rust v1.67.0 and v1.68.0 respectively),
instead this builds rust from the current selected version (1.65.0) and enables
the beta/nightly features for that version.

Setting the variable RUST_CHANNEL=nightly results in the following:

$ rustc -Vv
rustc 1.65.0-nightly

Signed-off-by: Alejandro Hernandez Samaniego <alejandro@enedino.org>
---
 meta/recipes-devtools/rust/rust-snapshot.inc | 7 ++++---
 meta/recipes-devtools/rust/rust-source.inc   | 5 +++--
 meta/recipes-devtools/rust/rust.inc          | 5 ++++-
 3 files changed, 11 insertions(+), 6 deletions(-)

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))
-- 
2.34.1

[PATCH 2/2] rust: Enable baremetal targets

[Alejandro Enedino Hernandez Samaniego]

Allow rust to build for baremetal targets by generating the proper target
triple, follow the format specified by rusts Triple [1], that is:

<arch>-<vendor>-<os>-<abi>

This is done automatically based on both TARGET_OS and TCLIBC.

For example, a riscv64 baremetal target triple would look like this:
riscv64gc-poky-none-elf

matching rusts own target triple for riscv64 according to platform-support [2]

[1] https://docs.rs/target-lexicon/latest/target_lexicon/struct.Triple.html
[2] https://doc.rust-lang.org/stable/rustc/platform-support.html

Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
---
 meta/classes-recipe/rust-common.bbclass        | 6 ++++++
 meta/classes-recipe/rust-target-config.bbclass | 5 ++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
index 3338de7502..0f72e45e8c 100644
--- a/meta/classes-recipe/rust-common.bbclass
+++ b/meta/classes-recipe/rust-common.bbclass
@@ -66,6 +66,12 @@ def rust_base_triple(d, thing):
     elif "musl" in os:
         libc = "-musl"
         os = "linux"
+    elif "elf" in os:
+        libc = "-elf"
+        os = "none"
+    elif "eabi" in os:
+        libc = "-eabi"
+        os = "none"
 
     return arch + vendor + '-' + os + libc
 
diff --git a/meta/classes-recipe/rust-target-config.bbclass b/meta/classes-recipe/rust-target-config.bbclass
index 2710b4325d..7fd7128bcf 100644
--- a/meta/classes-recipe/rust-target-config.bbclass
+++ b/meta/classes-recipe/rust-target-config.bbclass
@@ -355,7 +355,10 @@ def rust_gen_target(d, thing, wd, arch):
     tspec['target-c-int-width'] = d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
     tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN', arch_abi)
     tspec['arch'] = arch_to_rust_target_arch(rust_arch)
-    tspec['os'] = "linux"
+    if "baremetal" in d.getVar('TCLIBC'):
+        tspec['os'] = "none"
+    else:
+        tspec['os'] = "linux"
     if "musl" in tspec['llvm-target']:
         tspec['env'] = "musl"
     else:
-- 
2.34.1

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alexander Kanavin]

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

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 1830 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alex Kiernan]

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.

-- 
Alex Kiernan

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4004 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alexander Kanavin]

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

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alexander Kanavin]

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

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 1937 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3388 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alexander Kanavin]

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

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alex Kiernan]

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

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4276 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[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.

-- 
Alex Kiernan

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alejandro Enedino Hernandez Samaniego]

[-- Attachment #1: Type: text/plain, Size: 3752 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6552 bytes --]

Re: [OE-core] [PATCH 1/2] rust: Enable building rust from stable, beta and nightly channels

[Alex Kiernan]

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