[OE-core] Running task for all recipes required by an image (was Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner)

[Patrick Ohly]

On Fri, 2017-02-17 at 15:21 +0000, Mike Crowe wrote:
> On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote:
> > On Fri, 2017-02-10 at 18:32 +0000, Mike Crowe wrote:
> > > On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote:
> > > > On Wed, 2017-02-08 at 13:48 +0000, Mike Crowe wrote:
> > > > > On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> > > The part I'd missed is the all-important line in source-release-world.bb:
> > > 
> > >  do_source_release[depends] += "core-image-sato:do_build"
> > 
> > Okay, that explains it.
> > 
> > IMHO this do_build dependency should trigger do_rm_work. Your "bitbake
> > -c all_source_releases source-release-world" intentionally includes a
> > real world build, not just executing the source release tasks. Cleaning
> > up while building is the goal of rm_work.bbclass. It's arguably a
> > deficiency in the previous rm_work.bbclass that it wasn't active in your
> > case.
> > 
> > Now we just need to find a way to combine these without breaking the
> > extra tasks.
> 
> Now I think about this further, we're only depending on do_build in order
> to ensure that we get all the dependencies included in the source release
> via the recrdeps task. If there were a better way to do that then perhaps
> rm_work wouldn't cause any problems, and we also wouldn't waste time
> building stuff that we aren't going to use.

Isn't that exactly what do_fetchall does? I thought you wanted to build
things as part of your source-release-world. If that isn't needed, then
this in release-source.bbclass might work:

do_all_source_releases[recrdeptask] = "do_all_source_releases do_source_release"
do_all_source_releases[recideptask] = "do_build"

And used like this:
bitbake -c all_source_releases core-image-sato

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.