On Mon, Dec 11, 2023 at 10:52 AM Alex Kiernan via lists.openembedded.org <[email protected]> wrote: > > On Mon, Dec 11, 2023 at 9:43 AM Alex Kiernan <[email protected]> wrote: > > > > On Mon, Dec 11, 2023 at 9:28 AM Alexander Kanavin > > <[email protected]> wrote: > > > > > > On Mon, 11 Dec 2023 at 10:09, Alex Kiernan <[email protected]> wrote: > > > > In a single project there are (potentially) multiple Cargo.toml, but > > > > just one Cargo.lock. If there's multiple Cargo.lock files in a repo, > > > > that implies multiple projects which I don't think we've any way of > > > > building from a single recipe. > > > > > > I'm thinking of projects like librsvg, python3-bcrypt or > > > python3-cryptography where the build is orchestrated by meson, > > > autoconf or setuptools, and where we don't run cargo directly and > > > leave it to those tools. They may have single Cargo.lock now, but will > > > that hold? Also, that Cargo.lock is not necessarily in the root of > > > ${S}, so you'd have to set the location manually, instead of not > > > having to worry about it. Is CARGO_LOCK_PATH or its parent variables > > > already set correctly for all of them? I see this is not done from > > > python3-cryptography; shouldn't the build error out, if > > > cargo_common_do_patch_paths requires the location? Something doesn't > > > compute fully here. > > > > > > > That's exactly the one I was going to look at next, as I agree > > something doesn't add up there. > > > > cargo_common_do_patch_paths isn't in the call graph for > python3-cryptography, it gets patched in like this: > > do_configure[postfuncs] += "cargo_common_do_patch_paths" > > I'm unclear why that doesn't execute, I'm wondering if its related to > the autogenerated do_configure and this is a usage that just doesn't > work? > > # line: 1, file: autogenerated > do_configure() { > setup_target_config > python_setuptools3_rust_do_configure > } > > However even if it was in the call graph, we wouldn't have errored in > it as there's no patches to apply to the cargo config as the crates > are all satisfied from the vendored sources we deliver. > > It does feel like we're missing a piece in our python/rust integration > since if you did have a crate delivered from git then we wouldn't > patch up the cargo config correctly and I guess end up erroring out. >
Okay, I'm wrong. The pieces are all there, just we have no git crates to patch in for python3-cryptography so the existence check for Cargo.lock never runs. Maybe that should be hoisted earlier in the function so you see the failure if Cargo.lock isn't where it would be expected to be. -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192179): https://lists.openembedded.org/g/openembedded-core/message/192179 Mute This Topic: https://lists.openembedded.org/mt/103094777/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
