| Message ID | 7a3e6d5250d6d0cc526dbede582815007a3b3e56.1690795930.git.frederic.martinsons@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] cargo.bbclass: Use --frozen flag for cargo operations | expand |
On Mon, 2023-07-31 at 11:44 +0200, Frederic Martinsons wrote: > From: Frederic Martinsons <frederic.martinsons@gmail.com> > > And use that for rust-hello-world recipe that did not ship > a Cargo.lock file. > > Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com> > --- > meta/classes-recipe/cargo.bbclass | 4 +++- > meta/classes-recipe/cargo_common.bbclass | 3 +++ > meta/recipes-extended/rust-example/rust-hello-world_git.bb | 2 ++ > 3 files changed, 8 insertions(+), 1 deletion(-) Could you send a patch to the manual please adding the new variable CARGO_NO_FROZEN? I'm torn on this one as we could have simpler code which did: CARGO_FREEZE_OPTION = "--frozen" and then have the hello-world recipe: CARGO_FREEZE_OPTION = "--offline" but I'm torn on whether that is better or not... Cheers, Richard
Thanks Richard, but I'd prefer to drop this patch if possible. I think the rust-hello-world is no more useful and that we can replace it by a more "real" example like zvariant from meta-selftest. Let's see what others think about this On Tue, 1 Aug 2023 at 10:46, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Mon, 2023-07-31 at 11:44 +0200, Frederic Martinsons wrote: > > From: Frederic Martinsons <frederic.martinsons@gmail.com> > > > > And use that for rust-hello-world recipe that did not ship > > a Cargo.lock file. > > > > Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com> > > --- > > meta/classes-recipe/cargo.bbclass | 4 +++- > > meta/classes-recipe/cargo_common.bbclass | 3 +++ > > meta/recipes-extended/rust-example/rust-hello-world_git.bb | 2 ++ > > 3 files changed, 8 insertions(+), 1 deletion(-) > > Could you send a patch to the manual please adding the new variable > CARGO_NO_FROZEN? > > I'm torn on this one as we could have simpler code which did: > > CARGO_FREEZE_OPTION = "--frozen" > > and then have the hello-world recipe: > > CARGO_FREEZE_OPTION = "--offline" > > but I'm torn on whether that is better or not... > > Cheers, > > Richard >
On Tue, 2023-08-01 at 11:00 +0200, Frédéric Martinsons wrote: > Thanks Richard, but I'd prefer to drop this patch if possible. > I think the rust-hello-world is no more useful and that we can > replace it by a more "real" example like zvariant > from meta-selftest. > > Let's see what others think about this After some thought, I'm in favour. Lets drop it. Cheers, Richard
Ok but this raises other questions then, this recipe is part of packagegroup-core-tools-tesapps <https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb#n28> and is part of a test case <https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/runtime/cases/rust.py#n52> So what to do with those ? Suppress them too or adapt them with another recipe (zvariant ?) On Tue, 1 Aug 2023 at 11:07, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Tue, 2023-08-01 at 11:00 +0200, Frédéric Martinsons wrote: > > Thanks Richard, but I'd prefer to drop this patch if possible. > > I think the rust-hello-world is no more useful and that we can > > replace it by a more "real" example like zvariant > > from meta-selftest. > > > > Let's see what others think about this > > After some thought, I'm in favour. Lets drop it. > > Cheers, > > Richard >
On Tue, 2023-08-01 at 11:20 +0200, Frédéric Martinsons wrote: > Ok but this raises other questions then, this recipe is part of > packagegroup-core-tools-tesapps Just drop that. > and is part of a test case So what to do with those ? Suppress them > too or adapt them with another recipe (zvariant ?) I think the other test cases supersede this one so that can be dropped too? Cheers, Richard
I have no special feelings about rust-hello-world; if all places where it's currently used can be reworked to use real world components, that's totally fine. Alex On Tue, 1 Aug 2023 at 11:38, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Tue, 2023-08-01 at 11:20 +0200, Frédéric Martinsons wrote: > > Ok but this raises other questions then, this recipe is part of > > packagegroup-core-tools-tesapps > > Just drop that. > > > and is part of a test case So what to do with those ? Suppress them > > too or adapt them with another recipe (zvariant ?) > > I think the other test cases supersede this one so that can be dropped > too? > > Cheers, > > Richard > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#185222): https://lists.openembedded.org/g/openembedded-core/message/185222 > Mute This Topic: https://lists.openembedded.org/mt/100458217/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
zariant rust recipe is tested for devtool cases there
<https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/selftest/cases/devtool.py#n891>
The test case mentioned earlier seems to verify that we can run rust test
code, do we want to keep testing
that rust binary can run ? If so, how to keep testing this while removing
rust-hello-world recipes ?
maybe we can add a simple "println!("Hello world") " in this file
<https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/files/test.rs>
,
compile it like it is already done and run it
to check its output ?
What do you think?
On Tue, 1 Aug 2023 at 11:41, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> I have no special feelings about rust-hello-world; if all places where
> it's currently used can be reworked to use real world components,
> that's totally fine.
>
> Alex
>
> On Tue, 1 Aug 2023 at 11:38, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Tue, 2023-08-01 at 11:20 +0200, Frédéric Martinsons wrote:
> > > Ok but this raises other questions then, this recipe is part of
> > > packagegroup-core-tools-tesapps
> >
> > Just drop that.
> >
> > > and is part of a test case So what to do with those ? Suppress them
> > > too or adapt them with another recipe (zvariant ?)
> >
> > I think the other test cases supersede this one so that can be dropped
> > too?
> >
> > Cheers,
> >
> > Richard
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#185222):
> https://lists.openembedded.org/g/openembedded-core/message/185222
> > Mute This Topic: https://lists.openembedded.org/mt/100458217/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>
On Tue, 2023-08-01 at 11:55 +0200, Frédéric Martinsons wrote: > zariant rust recipe is tested for devtool cases there > > The test case mentioned earlier seems to verify that we can run rust > test code, do we want to keep testing > that rust binary can run ? If so, how to keep testing this while > removing rust-hello-world recipes ? > > maybe we can add a simple "println!("Hello world") " in this file , > compile it like it is already done and run it > to check its output ? > > What do you think? Doesn't test_rust_compile already also run the rust code it compiled? Cheers, Richard
On Tue, Aug 1, 2023 at 11:01 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Tue, 2023-08-01 at 11:55 +0200, Frédéric Martinsons wrote: > > zariant rust recipe is tested for devtool cases there > > > > The test case mentioned earlier seems to verify that we can run rust > > test code, do we want to keep testing > > that rust binary can run ? If so, how to keep testing this while > > removing rust-hello-world recipes ? > > > > maybe we can add a simple "println!("Hello world") " in this file , > > compile it like it is already done and run it > > to check its output ? > > > > What do you think? > > Doesn't test_rust_compile already also run the rust code it compiled? > Yes and checks the exit code - really not sure I see any additional value in turning it into another "Hello World". I'm fairly sure the cargo test gets you another "Hello World" test (but again only checks the return value). I think the rust-hello-world test is covered in other ways now.
Ok, thanks you all for the answers. I'll then add a new patch to make this cleansing and drop the patch I made to use --offline instead of --frozen (no more needed) Le mar. 1 août 2023, 12:04, Alex Kiernan <alex.kiernan@gmail.com> a écrit : > On Tue, Aug 1, 2023 at 11:01 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Tue, 2023-08-01 at 11:55 +0200, Frédéric Martinsons wrote: > > > zariant rust recipe is tested for devtool cases there > > > > > > The test case mentioned earlier seems to verify that we can run rust > > > test code, do we want to keep testing > > > that rust binary can run ? If so, how to keep testing this while > > > removing rust-hello-world recipes ? > > > > > > maybe we can add a simple "println!("Hello world") " in this file , > > > compile it like it is already done and run it > > > to check its output ? > > > > > > What do you think? > > > > Doesn't test_rust_compile already also run the rust code it compiled? > > > > Yes and checks the exit code - really not sure I see any additional > value in turning it into another "Hello World". I'm fairly sure the > cargo test gets you another "Hello World" test (but again only checks > the return value). I think the rust-hello-world test is covered in > other ways now. > > > -- > Alex Kiernan >
diff --git a/meta/classes-recipe/cargo.bbclass b/meta/classes-recipe/cargo.bbclass index 8c0b92df8d..d8ab94f2b4 100644 --- a/meta/classes-recipe/cargo.bbclass +++ b/meta/classes-recipe/cargo.bbclass @@ -39,12 +39,14 @@ MANIFEST_PATH ??= "${S}/${CARGO_SRC_DIR}/Cargo.toml" RUSTFLAGS ??= "" BUILD_MODE = "${@['--release', ''][d.getVar('DEBUG_BUILD') == '1']}" + # --frozen flag will prevent network access (which is required since only # the do_fetch step is authorized to access network) # and will require an up to date Cargo.lock file. # This force the package being built to already ship a Cargo.lock, in the end # this is what we want, at least, for reproducibility of the build. -CARGO_BUILD_FLAGS = "-v --frozen --target ${RUST_HOST_SYS} ${BUILD_MODE} --manifest-path=${MANIFEST_PATH}" +CARGO_EXTRA_FLAGS = "${@['--frozen', '--offline'][d.getVar('CARGO_NO_FROZEN') == '1']}" +CARGO_BUILD_FLAGS = "-v ${CARGO_EXTRA_FLAGS} --target ${RUST_HOST_SYS} ${BUILD_MODE} --manifest-path=${MANIFEST_PATH}" # This is based on the content of CARGO_BUILD_FLAGS and generally will need to # change if CARGO_BUILD_FLAGS changes. diff --git a/meta/classes-recipe/cargo_common.bbclass b/meta/classes-recipe/cargo_common.bbclass index 01afb74640..d17501182f 100644 --- a/meta/classes-recipe/cargo_common.bbclass +++ b/meta/classes-recipe/cargo_common.bbclass @@ -152,6 +152,9 @@ python cargo_common_do_patch_paths() { if not patches: return + if d.getVar("CARGO_NO_FROZEN") == 1: + return + # Cargo.lock file is needed for to be sure that artifacts # downloaded by the fetch steps are those expected by the # project and that the possible patches are correctly applied. diff --git a/meta/recipes-extended/rust-example/rust-hello-world_git.bb b/meta/recipes-extended/rust-example/rust-hello-world_git.bb index 1d91109b51..cad184837f 100644 --- a/meta/recipes-extended/rust-example/rust-hello-world_git.bb +++ b/meta/recipes-extended/rust-example/rust-hello-world_git.bb @@ -14,6 +14,8 @@ SUMMARY = "Hello World by Cargo for Rust" HOMEPAGE = "https://github.com/meta-rust/rust-hello-world" LICENSE = "MIT | Apache-2.0" +CARGO_NO_FROZEN = "1" + S = "${WORKDIR}/git" BBCLASSEXTEND = "native"