On Wed, Oct 5, 2022 at 1:56 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
On Wed, 5 Oct 2022 at 07:32, Chuck Wolber <chuckwolber@gmail.com> wrote:
> Can you elaborate on this?
>
> I only ask because we are using this[1] and this[2] to build this[3] recipe for hardknott.
>
> 1. https://github.com/meta-rust/meta-rust/blob/master/lib/crate.py
> 2. https://crates.io/crates/cargo-bitbake
> 3. https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb?h=kirkstone

As you can see in [1], crate:// fetcher is not using cargo, it's using
wget - so the question of resolving and listing dependencies from
Cargo.lock falls on the tooling that writes and updates the recipe
itself. cargo-bitbake failed at the installation step for me (both
with --locked and without it), and in general I do not think we should
rely on external tools with unknown maintenance status. The lists of
open issues and pull requests are not at all reassuring:
https://github.com/meta-rust/cargo-bitbake


I have cargo bitbake running locally, but in recent python3-cryptography and python3-bcrypt upgrades
it produced crate://* SRC_URI that actually failed to build. I had to manually loop through builds until
I sussed out all the versions that would work. This proves Alex's point.

Having looked at the implementation, I am very much in favor of this proposal. In fact, I wonder if
a similar approach could help with golang and maybe even nodejs/npm. But that is for another day.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171453): https://lists.openembedded.org/g/openembedded-core/message/171453
Mute This Topic: https://lists.openembedded.org/mt/94022674/924729
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ticotimo@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-