| Age | Commit message (Collapse) | Author |
|---|
|
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.
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)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is related to checksum verification introduction from
https://patchwork.yoctoproject.org/project/bitbake/patch/20230315131513.50635-1-frederic.martinsons@gmail.com/
I also choose to raise an exception if:
- no crates can be found
- no Cargo.lock file exist
Otherwise the generated inc file will silently be emptied.
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
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.
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:
https://github.com/solana-labs/solana-program-library/blob/88b147506d5b9515f3a4762421a0b8c309188dc9/token/cli/Cargo.toml#L30
so including all Cargo.lock files in whole ${WORKDIR}/git
seems like reasonable approach
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
lists from Cargo.lock
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.
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>
|
Peter Kjellerstedt
Frederic Martinsons
Martin Jansa
Alexander Kanavin