pon., 30 mar 2020 o 18:31 Richard Purdie
<[email protected]> napisał(a):
>
> On Mon, 2020-03-30 at 18:26 +0200, Bartosz Golaszewski wrote:
> > pon., 23 mar 2020 o 18:28 Bartosz Golaszewski <[email protected]>
> > napisał(a):
> > > From: Bartosz Golaszewski <[email protected]>
> > >
> > > Make each IMAGE_CMD task an sstate task with its own IMGDEPLOYDIR
> > > override. This way each generated set of artifacts is deployed as
> > > soon
> > > as it's ready instead of the do_image_complete task handling the
> > > entire
> > > deployement. This allows us to better fine-tune dependencies e.g.
> > > we
> > > can make do_image_wic depend on fitImage task which can in turn
> > > depend
> > > on do_image_ext4.
> > >
> > > We need to completely delete the do_package task in order to avoid
> > > problems with task hash changes as well as delete the IMGDEPLOYDIR
> > > variable from the data object passed to each image task so that
> > > it's
> > > expanded with the correct override.
> > >
> > > Signed-off-by: Bartosz Golaszewski <[email protected]>
> >
> > It's been a week. Can I get some feedback on this? Is the idea at
> > least remotely acceptable/can we build upon it?
>
> FWIW at a quick glance I didn't think it was too bad.
>
> I think there will be corner cases to resolve which I was hoping to
> look into and give some pointers to but I haven't had the time.
>
> I'm hoping somehow we can improve the FIXME you mention too.
>
Yeah, after thinking about it more, I figured that if a task signature
changes, then something is wrong. I guess it's because we end up
assigning pre- and postfuncs to tasks twice: once in anonymous python
code from image.bbclass and then from sstate.bbclass. Maybe we should
provide a python helper for explicitly making a task an sstate task
and - when using it - not add said task to SSTATETASKS, so that
sstate.bbclass code ignores it? Or maybe this anonymous function
should become an event handler invoked at event.RecipeParsed?
> The do_package change should probably be separated out - I'm guessing
> we did noexec there for a reason though?
>
I couldn't find a reason. Maybe it's a leftover from some previous,
now cleaned up change.
> Also, you used {}.format which I'm torn on since most of the codebase
> uses the other approach.
>
I couldn't find any official guidelines for that. {} is the preferred
way in Python. Maybe it's time to start slowly converting the bitbake
codebase?
> Its too late to get this into 3.1 and that is where I'm focusing my
> effort right now but I think this is probably going the right way.
>
Sure, I didn't expect it to go into the next release. If you're happy
with this direction I'll try to improve it and send a v2.
Bartosz
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136877):
https://lists.openembedded.org/g/openembedded-core/message/136877
Mute This Topic: https://lists.openembedded.org/mt/72497792/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
