Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner

[Mike Crowe <mac@mcrowe.com>]

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.
> 
> > > It seems unsafe to have tasks that are not properly ordered and just
> > > rely on not activating them in the same build, but without understanding
> > > the problem better it is too early to look for a solution.
> > 
> > Thanks for investigating. If you're still having trouble then I have a
> > single patch on top of current oe-core master that reproduces it for me
> > that I can send.
> 
> I can reproduce it.
> 
> As you said earlier, adding "before do_rm_work" solves the problem:
> addtask source_release before do_rm_work

I'd temporarily forgotten that this would cause every build to include the
source release when I wrote that. :(

> That's okay, even when rm_work.bbclass does not get inherited. However,
> when rm_work.bbclass, a "normal" build like "bitbake menu-cache" ends up
> triggering the source_release task:
> 
> $ bitbake -g menu-cache
> ...
> $ grep do_rm_work task-depends.dot  | grep do_source_release | grep menu-cache
> "menu-cache.do_rm_work" -> "menu-cache.do_source_release"
> 
> Is that acceptable for you?

Not really.

> To me it seems like the right solution. Inheriting
> release-source.bbclass could be limited to builds which produce
> releases, for example in your CI setup, then normal developers will not
> be affected.

At the moment it is straightforward to build the source release with a
simple bitbake invocation.

Your solution would work, but it would be necessary to meddle with
local.conf or similar in order to generate the source release.

Is there any way we can get our tasks in as predecessors of rm_work only if
they would have run anyway? Rather like the way make(1) supports order-only
prerequisites[1]?

Thanks.

Mike.

[1] https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html