Re: [bitbake-devel] [RFC-cargo-fetcher 0/3] Suggest a first step

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Sun, 2021-02-07 at 16:01 +0100, Andreas Müller wrote:
> This is a first version of a cargo fetcher. It mimics cargo fetch means
> it creates cargo cache in ${DL_DIR}/cargo. As mentioned in comments the
> proxy-thingy was stolen from npmsw for shrinkwrap files.
> 
> First approach was to parse Cargo.toml for projects that don't ship a
> Cargo.lock (crates for rustlibs should do this) but that was skipped:
> An unknown magic inside cargo detects which libs are avaiable: Blindly
> followin -> download explodedc [1]
> 
> As proof of concept I did (no meta-rust in layers to avoid surprises):
> 
> * add a simple cargo-fetch.bbclass to oe-core [2]
> * adapt a pure rust recipe 'spotifyd' to new fetcher [3-4]
> * moved console to source of spotifyd and did
>   > export CARGO_HOME="<DL_DIR>/cargo"
>   > export CARGO_TARGET_DIR="<B>"
>   > cargo build --frozen
>   --> project was build without issues
> 
> Please review carefully because I am aware that:
> 
> * my python could be better
> * the 'one cache for all in download area thingy' might cause issues I do not
>   see yet
> 
> Am also aware that this is not more than a first step. Once this makes it in,
> further TODOs are:
> 
> * Merge latest meta-rust -> oe-core (latest: There were some riscv adjustments
>   recently - and I am not sure if these are in the poky-contrib of Alex/Ross)
> * Add documentation / tests / devtool-support / ??
> 
> [1] https://github.com/schnitzeltony/mimic-cargo-fetcher/blob/master/test.py
> [2] https://github.com/schnitzeltony/openembedded-core/blob/cargo-fetcher/meta/classes/cargo-fetch.bbclass
> [3] https://github.com/schnitzeltony/meta-musicians/blob/cargo-fetcher/recipes-streaming/spotify/spotifyd.bb
> [4] https://github.com/schnitzeltony/meta-musicians/blob/cargo-fetcher/recipes-streaming/spotify/spotifyd/Cargo.lock


Thanks for putting this together. Out of interest how does it compare
to the code in meta-rust?

I'm hoping Paul Barker and Randy MacLeod can take a look at this as
they've done a lot more work in the area than I have.

Cheers,

Richard