From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v3 2/3] rust: refactor source handling into a shared work-shared recipe
Date: Wed, 29 Jul 2026 09:58:04 +0530 [thread overview]
Message-ID: <70d29250-0950-47e9-a180-bfda08a669b3@windriver.com> (raw)
In-Reply-To: <e9117009423ec2c41f99383a7993724bc3d221b9.camel@linuxfoundation.org>
On 28-07-2026 13:18, Richard Purdie wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 2026-07-24 at 20:51 -0700, Varatharajan, Deepesh via lists.openembedded.org wrote:
>> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>
>> [YOCTO #15808]
>>
>> Consolidate Rust source management across all Rust recipes (rust, cargo,
>> libstd-rs and their native/nativesdk variants) into a single shared
>> source tree using the work-shared pattern.
>>
>> Disk savings: a world build with multilibs enabled, together with
>> nativesdk-rust and nativesdk-cargo, now shares a single ~4.2 GB rustc-src
>> tree instead of maintaining up to 11 independent copies (~46.2 GB total).
>>
>> Performance (clean core-image-sato build, qemux86-64):
>>
>> Before: 68m53.507s
>> After: 65m46.159s
>> Improvement: 3m07.348s (~4.5%)
>>
>> New files:
>>
>> - rust-source.bb: A shared recipe that fetches, unpacks, and patches the
>> rustc source tree into ${TMPDIR}/work-shared/rust-source-${PV}-${PR}.
>> All build/install/packaging tasks are disabled; this recipe exists solely
>> to provide a single copy of the source. Inherits allarch/nopackages,
>> excludes itself from rm_work, and is hidden from world builds.
>> Also defines RUST_BUILD_ARCH locally since this recipe does not inherit
>> rust-common.bbclass but still needs the mapping for snapshot fetching
>> via rust-snapshot.inc.
>>
>> - common-source.inc: Included by consumer recipes (rust, cargo, libstd-rs)
>> to disable their local do_fetch/do_unpack/do_patch tasks, clear SRC_URI,
>> and add task dependencies on rust-source-${PV} for configure, licensing,
>> and SPDX generation. Also provides is_work_shared_spdx() override for
>> correct SPDX shared-workdir detection.
>>
>> Modified files:
>>
>> - rust-source.inc:
>> - Replace RUST_VERSION with explicit MAJOR_VER/MINOR_VER/PATCH_VER and PV.
>> - Set UNPACKDIR to the work-shared location so all consumers share one
>> source tree via RUSTSRC and S.
>>
>> - rust_git.bb (renamed from rust_1.96.1.bb):
>> - Add 'require common-source.inc' to use the shared source tree.
>> - Set B = ${WORKDIR}/build to separate build artifacts from shared source.
>> - Set CARGO_HOME = ${WORKDIR}/cargo_home to isolate cargo caching.
>> - Set build-dir = "rust-build" in config.toml to distinguish Yocto's build
>> directory (B), which holds config.toml, from the bootstrap's own build
>> output directory. Without this, bootstrap defaults to "build/" inside B,
>> creating an ambiguous build/build/ nesting.
>> - Use absolute ${S}/src/bootstrap/bootstrap.py path since cwd is now B.
>> - Update install functions to reference rust-build/ instead of build/.
>> - Update do_test_compile to use absolute ${S}/src/tools/ path.
>> - Change do_rust_setup_snapshot from 'after do_unpack' to depend on
>> rust-source-${PV}:do_unpack (since local do_unpack is removed).
>>
>> - cargo_git.bb (renamed from cargo_1.96.1.bb):
>> - Add 'require common-source.inc' to use the shared source tree.
>> - Change do_cargo_setup_snapshot from 'after do_unpack' to depend on
>> rust-source-${PV}:do_unpack.
>>
>> - libstd-rs_git.bb (renamed from libstd-rs_1.96.1.bb):
>> - Add 'require common-source.inc' to use the shared source tree.
>>
>> - rust-cross-canadian_git.bb (renamed from rust-cross-canadian_1.96.1.bb):
>> - Rename only (version now comes from rust-source.inc via PV).
>>
>> - rust-common.bbclass:
>> - Add a second --remap-path-prefix for ${TMPDIR}/work-shared so debug
>> info from the shared source tree is correctly remapped.
>> - Retain RUST_BUILD_ARCH definition so that consumer recipes (rust, cargo,
>> libstd-rs) which inherit this class can resolve snapshot directory names
>> used by do_rust_setup_snapshot and do_cargo_setup_snapshot.
>>
>> - lib/oeqa/selftest/cases/rust.py:
>> - Adapt the selftest to the build-dir/source-dir split: use B for build
>> artifacts and RUSTSRC for source paths.
>> - Update remote-test-server copy path from build/ to rust-build/.
>> - Pass --build-dir and --config explicitly to bootstrap.py.
>>
>> - conf/distro/include/maintainers.inc:
>> - Add maintainer entry for the new rust-source recipe.
>>
>> License-Update: recipe file renames only, no license change
>>
>> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>> ---
>> meta/classes-recipe/rust-common.bbclass | 4 +-
>> meta/conf/distro/include/maintainers.inc | 1 +
>> meta/lib/oeqa/selftest/cases/rust.py | 9 ++-
>> .../rust/{cargo_1.96.1.bb => cargo_git.bb} | 8 ++-
>> meta/recipes-devtools/rust/common-source.inc | 28 ++++++++++
>> .../{libstd-rs_1.96.1.bb => libstd-rs_git.bb} | 4 ++
>> ...n_1.96.1.bb => rust-cross-canadian_git.bb} | 0
>> meta/recipes-devtools/rust/rust-source.bb | 56 +++++++++++++++++++
>> meta/recipes-devtools/rust/rust-source.inc | 16 +++++-
>> .../rust/{rust_1.96.1.bb => rust_git.bb} | 31 +++++++---
>> 10 files changed, 140 insertions(+), 17 deletions(-)
>> rename meta/recipes-devtools/rust/{cargo_1.96.1.bb => cargo_git.bb} (91%)
>> create mode 100644 meta/recipes-devtools/rust/common-source.inc
>> rename meta/recipes-devtools/rust/{libstd-rs_1.96.1.bb => libstd-rs_git.bb} (92%)
>> rename meta/recipes-devtools/rust/{rust-cross-canadian_1.96.1.bb => rust-cross-canadian_git.bb} (100%)
>> create mode 100644 meta/recipes-devtools/rust/rust-source.bb
>> rename meta/recipes-devtools/rust/{rust_1.96.1.bb => rust_git.bb} (93%)
> In the patch review call we noted that "_git" isn't accurate as these
> are version'd recipes, not git based. There was a suggestion to just
> remove that piece but without the versions, it would make it harder to
> have multiple rust versions in parallel should that be needed. This is
> why the gcc recipes retain a version in the filenames.
>
> Our suggestion would be to have rust match what gcc does for those two
> reasons.
>
> Otherwise with the LICENSE bracket fix, we think is is probably ready
> to merge. The space savings are nice to have!
>
> Cheers,
>
> Richard
Hi Richard,
Thanks for the review feedback!
Makes sense I'll rename the recipes to include the version in the
filename, matching the gcc convention.
Also get the LICENSE bracket fix in. Will send a new version shortly.
Regards,
Deepesh
next prev parent reply other threads:[~2026-07-29 4:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 3:51 [PATCH v3 1/3] rust: Fix reproducibility with shared source trees Deepesh.Varatharajan
2026-07-25 3:51 ` [PATCH v3 2/3] rust: refactor source handling into a shared work-shared recipe Deepesh.Varatharajan
2026-07-27 11:29 ` [OE-core] " Mathieu Dubois-Briand
2026-07-28 7:48 ` Richard Purdie
2026-07-29 4:28 ` Deepesh Varatharajan [this message]
2026-07-25 3:51 ` [PATCH v3 3/3] rust: Move do_update_snapshot to rust-source Deepesh.Varatharajan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70d29250-0950-47e9-a180-bfda08a669b3@windriver.com \
--to=deepesh.varatharajan@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox