]> code.ossystems Code Review - openembedded-core.git/commit
rm_work.bbclass: clean up sooner
authorPatrick Ohly <patrick.ohly@intel.com>
Fri, 13 Jan 2017 14:52:33 +0000 (15:52 +0100)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Thu, 19 Jan 2017 22:45:54 +0000 (22:45 +0000)
commit936179754c8d0f98e1196ddc6796fdfd72c0c3b4
treec69c129399a7acd6fdfa84b1b289fdc761cb7353
parentca23a07fc6677720508197f2b44573bfd6b52f28
rm_work.bbclass: clean up sooner

Having do_rm_work depend on do_build had one major disadvantage:
do_build depends on the do_build of other recipes, to ensure that
runtime dependencies also get built. The effect is that when work on a
recipe is complete and it could get cleaned up, do_rm_work still
doesn't run because it waits for those other recipes, thus leading to
more temporary disk space usage than really needed.

The right solution is to inject do_rm_work before do_build and after
all tasks of the recipe. Achieving that depends on the new bitbake
bb.event.RecipeTaskPreProcess and bb.build.preceedtask().

It can't just run in an anonymous function, because other anonymous
functions that run later may add more tasks. There's still such a
potential conflict when some future RecipeTaskPreProcess event handler
also wants to change task dependencies, but that's not a problem
now. Should it ever occur, the two handlers will have to know about
each other and cooperate to resolve the conflict.

Benchmarking (see "rm_work + pybootchart enhancements" on the OE-core
mailing list) showed that builds with the modified rm_work.bbclass
were both faster (albeit not by much) and required considerably less
disk space (14230MiB instead of 18740MiB for core-image-sato).
Interestingly enough, builds with rm_work.bbclass were also faster
than those without.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
meta/classes/rm_work.bbclass