Am 12.02.2025 um 14:55 schrieb Bruce Ashfield:
On Wed, Feb 12, 2025 at 7:42 AM Stefan Herbrechtsmeier
<stefan.herbrechtsmeier-...@weidmueller.com> wrote:
Am 11.02.2025 um 23:32 schrieb Bruce Ashfield via
lists.openembedded.org <http://lists.openembedded.org>:
In message: [OE-core] [RFC PATCH 15/30] classes: add early fetch, unpack
and patch support
on 11/02/2025 Stefan Herbrechtsmeier vialists.openembedded.org
<http://lists.openembedded.org> wrote:
From: Stefan Herbrechtsmeier<stefan.herbrechtsme...@weidmueller.com>
<mailto:stefan.herbrechtsme...@weidmueller.com>
Add support for early fetch, unpack and patches task which run before
normal patch task. This feature is useful to fetch additional
dependencies based on a patched source before the normal unpack and
patch tasks. The patch are marked as early via an early=1 parameter. An
example use case is a patch for a package manager lock file (Cargo.lock,
go.sum, package-lock.json).
I understand why you need to do the above, but there's now multiple
fetch and patch tasks running throughout the pipeline of the
build and that's just more complexity to maintain.
The tasks call the same functions and the difference is really
low. The early task simple use a filtered list of the SRC_URI. At
the moment the gitsm fetcher is doing the same but without a
possibility to patch a dependency.
This is what I was asking about in some of my first replies
to the RFC series. When I've done this in the past, I'd just
suggest something simpler like the recipe provide a complete
"lock file" in the layer/recipe-space and have it overlayed
in the source.
This was already supported by my first patch series. The
disadvantage is a lot of noise during each update.
Of course that means it is in the same fetch task as what
will be fetching the vendor bits, but coordinating within
the single task is simpler in my experience (and it can
be checked on the SRC_URI). I haven't fully thought through
how to manage it, but wanted to reply to this while it was
fresh in my mind.
It is simpler because you manual fetch the lock file, remove the
possibility to patch the file and skip the unpack. But you still
need a manual fetch, unpack and maybe patch the source and copy
the file into the meta layer.
That's a completely different type of complexity. Richard and I are
only talking
about the complexity after "bitbake <foo>" has been called.
It is also possibility to integrate the early and resolve task
into fetch task but I'm unsure if this simplify the complexity.
Having direct calls to additional routines via conditional is less
complex than
tasks (dealing with timing, scheduling, code maintenance, etc), so that is
preferable from at least my point of view.
Okay, I thought separate tasks are preferred. What is the alternative to
the EXPORT_FUNCTIONS in this case. I need to call different functions
depending on the inherit class.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211244):
https://lists.openembedded.org/g/openembedded-core/message/211244
Mute This Topic: https://lists.openembedded.org/mt/111123537/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
