'UPDATE' as a name is somewhat unfortunate as the variable is intended only for
the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation.
(From OE-Core rev: 4467aa0661e233f44c4ce029428c67d88fccfc07)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we upgrade a recipe that inherits cargo-update-recipe-crates and
the upstream Cargo.toml/Cargo.lock have been changed, we need to run
the update_crates task or else the devtool upgrade (and therefore
AUH upgrade) will fail.
Add "do_update_crates" task to RECIPE_UPDATE_EXTRA_TASKS for all
recipes that inherit this class.
(From OE-Core rev: 0156ab3e009fa789c629f6c0ab06fcf21add94f8)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the recent change to the crate fetcher, which automatically sets
the name to for each crate to be versioned, there is no longer a need to
explicitly set the name= parameter for each URI. This also results in
generated files that are compatible with the crate fetcher in Kirkstone
and Langdale.
(From OE-Core rev: eb272afcd9a12ce2b2f43436b3f84f52cb6cdfb7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A project can have multiple Cargo.lock (provides
multiple binaries for example) and each one can
depends on differenct version of the same crates.
Even within the same Cargo.lock file, it is possible
to have different version of same crates.
To avoid conflicts, override the name with the version
for all crates checksum
Moreover, when searching for Cargo.lock, we should ignore
specific dir like .git (no use to walk down there) and .pc
(because it can have a Cargo.lock if this file was patched)
(From OE-Core rev: 1795e98a04ad09b011afcc7cc3bf6dc49475b19a)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If having devtool modified a recipe and then updated the crate versions,
e.g., by doing a git bisect, running the update_crates task needs to
always update the .inc file even if the bitbake metadata has not
changed.
(From OE-Core rev: 137d290ac1f7516a509fc9d264489e51c3004d5d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use 4 spaces
* avoid trailing space
* add CARGO_LOCK_SRC_DIR to allow searching outside ${S}
* use BPN in output filename
* First I've used CARGO_LOCK_SRC_DIR as relative to ${S}, because that's what CARGO_SRC_DIR
in cargo.bbclass is using:
meta/classes-recipe/cargo.bbclass:CARGO_SRC_DIR ??= ""
meta/classes-recipe/cargo.bbclass:MANIFEST_PATH ??= "${S}/${CARGO_SRC_DIR}/Cargo.toml"
but change to absolute path (defaulting to ${S}) as requested by Alex:
11:44 < kanavin> JaMa, would prefer CARGO_LOCK_SRC_DIR ??= "${S}"
11:46 < kanavin> otherwise looks good
* I've resolved my usecase for CARGO_LOCK_SRC_DIR by changing
S back to ${WORKDIR}/git and using CARGO_SRC_DIR to select
the right subdirectory to be built, because the Cargo.toml
in this subdirectory was also referencing other subdirectories
with relative path:
88b147506d/token/cli/Cargo.toml (L30)
so including all Cargo.lock files in whole ${WORKDIR}/git
seems like reasonable approach
(From OE-Core rev: 7636a2b8080521ed2ad54b0edce47a8742a12d58)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For better or worse, more and more rust components are appearing that do
not include their dependencies in tarballs (or git trees), and rely on cargo
to fetch them. On the other hand, bitbake does not use cargo (and quite possible
won't ever be able to), and relies on having each item explicitly listed in SRC_URI
with a crate:// prefix. This however creates a problem of both making such lists in
the first place and updating them when a recipe is updated to a newer version.
So this class can be used to perform such updates by implementing a task that does it;
the next commit shows the outcome for python3-bcrypt (which has been tested to work
and produce a successful build).
Note: the python script relies on tomllib library, which appears in Python 3.11 and
does not exist in earlier versions - I've tested this by first updating python to 3.11-rc2
in oe-core.
(From OE-Core rev: 9eee3631124d64574b18a70a2fc42f446d58bfd2)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
