linux/poky.git/meta/classes/rm_work.bbclass, branch uninative-1.9

rm_work: remove debugging statements

2018-01-02T17:24:38+00:00

(From OE-Core rev: e7da9a3adc1ed430fff7afae4233e62313759b65) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

rm_work: Handle race with -inital tasks

2017-12-21T10:21:00+00:00

There is a race with rm_work when tasks run deltask do_build since do_rm_work becomes a floating task. Handle this by injecting the populate_sysroot/lic dependencies manually if the tasks returned are empty. This depends on a change to fix bb.build.preceedtask() in bitbake too. [YOCTO #12365] (From OE-Core rev: 0f537d985b7b17af508a511fca8a4ec4b5804580) Signed-off-by: Richard Purdie

rm_work: fix build break for do_image_complete

2017-08-15T23:03:14+00:00

* since following commit: commit 2ff9d40dc88d43567472218cf3d3faf414398c71 Author: Richard Purdie Date: Sun Jul 30 16:06:57 2017 +0100 image/rm_work: Promote do_image_complete to be more sstate like all image rm_work tasks are failing with: mv: 1.0-r0.do_image_complete.228730130ba309f85b73b72222ba11d7.raspberrypi3 and 1.0-r0.do_image_complete.228730130ba309f85b73b72222ba11d7.raspberrypi3 are the same file it's because for $i 1.0-r0.do_image_complete.228730130ba309f85b73b72222ba11d7.raspberrypi3 there will be first SSTATETASK in $j do_deploy, so the sed call doesn't replace anything It might be different order of SSTATETASKS in my builds (it might work only when do_image_complete is the first one in the list), but here: SSTATETASKS="do_deploy do_image_complete do_image_qa do_package do_package_qa do_package_write_ipk do_packagedata do_populate_lic do_populate_sdk do_populate_sdk_ext do_populate_sysroot" (From OE-Core rev: 0c905d4e7fa8e5416945fa0d61ebc1d34409d1e6) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

meta: drop do_bootdirectdisk do_vmimg references

2017-08-03T10:14:13+00:00

do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563: [ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ] Also drop the references to them and image-vm. (From OE-Core rev: 609f7f4ecd17c8299b97d9face098e3cc44fa6eb) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie

image/rm_work: Promote do_image_complete to be more sstate like

2017-07-31T14:13:31+00:00

We relied on the missing do_image_complete_setscene task to ensure the dummy sstate tarball that was created would never be used. This lead to its own issues and a better fix for SSTATE_SKIP_CREATION has now been merged. We can therefore make do_image_complete look like a more standard sstate task which means image generation doesn't keep rerunning when using rm_work. We do need to turn do_image_complete's stamp into an sstate version to handle this (it otherwise matches the do_image_* glob). (From OE-Core rev: 2ff9d40dc88d43567472218cf3d3faf414398c71) Signed-off-by: Richard Purdie

rm_work: Improve handling for addto_recipe_sysroot

2017-07-31T14:13:31+00:00

Rather than requiring each user to handle this individually, handle addto_recipe_sysroot in the core class. As well as preserving the sysroot directory, this also ensures the stamp is preserved rather than rerunning the task every time as currently happens. (From OE-Core rev: bf8b9858d9ccce27173d13938a83d249294cc473) Signed-off-by: Richard Purdie

rm_work.bbclass: introduce do_build_without_rm_work

2017-03-31T09:10:29+00:00

Some classes, for example populate_sdk_ext.bbclass, must be able to trigger a full build of a recipe without also triggering do_rm_work. They cannot depend on do_build anymore, because that would trigger do_rm_work. Instead, do_build_without_rm_work can be used. It has the exact same dependencies as do_build, minus do_rm_work and do_rm_work_all. This may also be useful in a test build of a recipe where one wants to preserve the work directory without having to modify configuration settings: bitbake foobar:do_build_without_rm_work (From OE-Core rev: 04a7b8d6d2e86cc4dd1362c775f5e3ac1eb1d19d) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

rm_work.bbclass: re-enable recursive do_rm_work_all

2017-03-22T11:35:21+00:00

When rewriting the do_rm_work injection, do_rm_work_all had been removed because it seemed obsolete, as do_build now always triggers do_rm_work. However, do_build does not get triggered for all recipes and thus do_rm_work was not called for recipes that got built only partially. For example, zlib depends indirectly on zlib-native:do_populate_sysroot. Because of that dependency, zlib-native got compiled, but do_rm_work was never called for it. Re-introducing do_rm_work_all fixes that by making do_build depend on do_rm_work_all, which then recursively depends on do_rm_work of all dependencies. This has the unintended side-effect that do_rm_work then also triggers additional work (like do_populate_lic) that normally doesn't need to be done for a build. This seems like the lesser evil, compared to an incomplete cleanup because it mostly enables the lighter tasks after do_populate_sysroot. The real solution would be to have two kinds of relationships: a weak ordering relationship ("if A and B are enabled, A must run before B, but B can also run without A") and hard dependencies ("B cannot run unless A has run before"). (From OE-Core rev: b3de5d5795767a4b8c331fa5040166e7e410eeec) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

rm_work.bbclass: clean up sooner

2017-01-20T11:53:49+00:00

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. (From OE-Core rev: 936179754c8d0f98e1196ddc6796fdfd72c0c3b4) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

rm_work.bbclass: allow preserving additional content

2017-01-20T11:53:48+00:00

By default, do_rm_work either skips recipes entirely (when listed in RM_WORK_EXCLUDE) or removes everything except for temp. In meta-swupd, virtual image recipes collaborate on producing update data for the base recipe. Tasks running in the base recipe need some information from the virtual images. Those files could be passed via a new shared work directory, but that scatters data in even more places. It's simpler to use the normal WORKDIR and teach rm_work.bbclass to not remove the special output with the new RM_WORK_EXCLUDE_ITEMS. (From OE-Core rev: 28fbb2dd17033308cc09811fbc4f43e2f6c17f54) Signed-off-by: Patrick Ohly Signed-off-by: Ross Burton Signed-off-by: Richard Purdie