[OE-core] [PATCH RFC] pixbufcache: Use sceneQueueComplete event to simplify usage

[Jacob Kroon]

On Sun, Aug 17, 2014 at 10:55 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sun, 2014-08-17 at 10:33 +0200, Jacob Kroon wrote:
> > On Sat, Aug 2, 2014 at 10:54 AM, Richard Purdie
> > <richard.purdie at linuxfoundation.org> wrote:
> >         [This is an RFC which depends on a patch to bitbake to
> >         operate]
> >
> >         Currently, we have a mess of dependencies for pixbufcache and
> >         even then
> >         it breaks since they might be controlled by PACKAGECONFIG.
> >
> >         Instead, this patch proposes an alternative approach where we
> >         allow
> >         "fixups" from a sceneQueueComplete() event at the end of the
> >         setscene
> >         process. We signal the need for these using simply stamp
> >         files.
> >
> >         The one downside is that the processing code needs to be in a
> >         global
> >         event handler like base.bbclass rather than
> >         pixbufcache.bbclass but this
> >         is probably a price worth paying to avoid the dependency mess?
> >
> >         Signed-off-by: Richard Purdie
> >         <richard.purdie at linuxfoundation.org>
> >
> >
> >
> > Instead of having the sstate_postinst() touch "needpixbuf", could we
> > make it write out the actual script that needs to be executed ?
> >
> > Then base.bbclass could iterate over any scripts installed by any
> > sstate_postinst() and execute them. At least this would better isolate
> > the pixbuf-code to pixbufcache.bbclass, and make the snippet in
> > base.bbclass more generic.
>
> It does become trickier to avoid races when writing out that script.
> Touching the file is rather easy from a lock perspective :)
>
>
How about prefixing the actual written out script with "${PN}-" ? That
would prevent races writing the script.
Downside would be that the pixbuf-cache update would be run multiple times.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140830/18f818fa/attachment-0002.html>