Bug 8405

Summary: Automated cascaded cleaning
Product: [Build System, Metadata & Runtime] BitBake Reporter: Igor Stoppa <igor.stoppa>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: Undecided CC: poky.bs.watcher, poky.watcher, ross.burton
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)

Description Igor Stoppa 2015-09-28 14:13:52 UTC 
Scenario
--------

When dealing with multiple recipes having dependency, ex:

A -> B -> C -> D -> ..

one might have to clean all those along the dependency path, ex:

in the previous case I should issue

bitbake -c clean A; bitbake -c clean B; bitbake -c clean C

if it's desired to rebuild C and all those recipes that use it.



Problem
-------

This can be difficult / complex when using lots of nested/interlinked recipes and classes.

bitbake -g A can help, but it stil lrequires manual work and the outcome can vary, as it's based on human work.




Proposed solution
-----------------

It would be more effective if it was possible to issue a command like:

bitbake -c clean C A

meaning: clean C and everything that is in the dependency path between A and C
Comment 1 Ross Burton 2015-09-29 15:00:35 UTC 
Having to explicitly clean sounds like a bug in the recipe, state shouldn't be preserved between builds.  Possibly you should reduce this problem down to a minimal example and file a concrete bug.

Note that if B depends on A and A is rebuilt then B onwards will all re-execute from do_configure.  If those recipes are well behaved and do a clean before configure then you've got the behaviour you want already (for example, autotools.bbclass does out of tree builds and deletes $B before running configure).

Finally you can execute multiple cleans in a single invocation by doing "bitbake A:do_clean B:do_clean C:do_clean".
Comment 2 Igor Stoppa 2015-09-30 06:13:08 UTC 
@Ross: I understand and agree with what you are saying.

The difficult part is "you should reduce this problem down to a minimal example".

Unfortunately it's not uncommon to find broken recipes, it just happens.

This proposition was an attempt at working around the problem.

Perhaps a better way would have been to ask: if there is any automated way of pinpointing a recipe with broken dependency, without going manually through the .dot file.
Comment 3 Ross Burton 2015-09-30 07:04:02 UTC 
We did a lot of work recently with fixing this sort of problem, which is why most recipes will clean before configuring.  Generally it's the recipe that breaks that needs to be doing the clean if it isn't already.  If you find a recipe in oe-core that breaks on rebuilds please do file a bug/patch.

Of course, using rm_work will make the problem disappear entirely.
Comment 4 Richard Purdie 2015-10-01 12:48:32 UTC 
In case its not clear, you can already run "bitbake A B C -c clean", it will run the do_clean tasks for A, B and C. What it won't do is run clean for any dependencies, or dependees.

If you wanted to trigger a rebuild of all dependees, you can do "bitbake C -f; bitbake A", which will then cause anything depending on C to rebuild, including A which you've then built.

I can't really see how we'd add a commandline option which could describe what you're after, nor have I seen much demand for it from users in general, the -f taint option is probably as close as we can get.