On Sun, Dec 10, 2023 at 8:35 PM Alexander Kanavin <[email protected]> wrote: > > I have to say, I struggle to see this as an improvement, and I want > to object to it. >
I have to admit I kinda thought this might be controversial. > Why set the path manually, if the code to find where Cargo.lock is > just works, and handles the situations where upstreams move it around > in source trees? > We have to know where Cargo.lock is else cargo_common_do_patch_paths fails. Searching for it one class and requiring to know where it is another seems odd to me - my first pass on this change was to just set CARGO_LOCK_SRC_DIR based on the directory name of CARGO_LOCK_PATH; I'll resurrect that patch. > Also, is the assumption that there's only one Cargo.lock valid? I'm > not so sure. Note that the code was specifically written to pull in > items from multiple files. > 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. -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192148): https://lists.openembedded.org/g/openembedded-core/message/192148 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]] -=-=-=-=-=-=-=-=-=-=-=-
