linux/poky.git/bitbake/lib/bb/runqueue.py, branch 4.2_M3

bitbake: event/cooker/runqueue: Add ability to interrupt longer running code

2023-02-23T12:12:18+00:00

Bitbake is now able to understand when a UI wants it to stop the current processing. There are some long running functions which currently have no mechanism to interrupt them however. This patch adds a call, bb.event.check_for_interrupts(d) which can be placed in long running code and allows an internal state flag within bitbake to be checked. If set, that flag will trigger an exit. This means that Ctrl+C can be made to work in a variety of places where it currently would not. Long running event handlers in OE-Core can also then benefit from this new approach with the addition of the function call as well. (Bitbake rev: b7ed7e9a815c4e10447fd499508be3dbb47f06e8) Signed-off-by: Richard Purdie

bitbake: runqueue: Drop SystemExit usage

2023-02-19T07:48:28+00:00

Using bb.fatal for a fatal error message is the best practise, switch the code to match other call sites. (Bitbake rev: c27e48fa81c2327a4a355a028884ab457cde3ae7) Signed-off-by: Richard Purdie

bitbake: event: builtins fix for 'd' deletion

2022-12-29T00:07:06+00:00

I've been seeing event handlers where 'd' seems to disappear half way through event handler execution. This is problematic when multiple threads are active since this code assumes single threading. The easiest fix is to change the handler function calls to contain d as a parameter as we do elsewhere for other functions. This will break any non-text handlers but I was only able to spot one of those in runqueue. It will also break handlers than call functions that assume 'd' is in the global namespace but those failures should be obvious and we can fix those to pass d around. This solution avoids manipulating builtins which was always a horrible thing to do anyway and solves the issue without needing locking, thankfully. (Bitbake rev: 1e12f0a4b592dacd006d370ec29cd71d2a44312e) Signed-off-by: Richard Purdie

bitbake: build/siggen: Rework stamps functions

2022-12-17T08:52:28+00:00

The current method of passing either a task's datastore, or dataCaches and a filename into the stamp functions is rather horrible. Due to the different contexts, fixing this is hard but we do control the bitbake side of the API usage so we can migrate those to use other functions and then only support a datastore in the public bb.build API which is only called from task context in OE-Core. (Bitbake rev: c79ecec580e4c2a141ae483ec0f6448f70593dcf) Signed-off-by: Richard Purdie

bitbake: bitbake: siggen/runqueue: Switch to using RECIPE_SIGGEN_INFO feature for signature dumping

2022-12-17T08:52:28+00:00

Now that we have cache support for the taskdep/gendep/lookupcache data, we can switch to use that cooker feature and skip the secondary reparse to write the sig files. This does make the initial parse longer but means the secondary one isn't needed. At present parsing with the larger cache isn't optimal but we have plans in place which will make this faster than the current reparse code being removed here. (Bitbake rev: 5951b5b56449855bc2a30146af65eb287a35fcef) (Bitbake rev: 1252e5bce51ae912ecff9dcc354a371786ff2c72) Signed-off-by: Richard Purdie

bitbake: siggen: Directly store datacaches reference

2022-12-17T08:52:28+00:00

It is becomming clear the siggen needs access to our cache data but we can't always obtain it in the contexts we need to. Add it directly, meaning over time we should be able to simplify the APIs and stop convoluting new ones! (Bitbake rev: 6b213590ed0e77683cf7fbce6bbe9605ddecf3d3) Signed-off-by: Richard Purdie

bitbake: build/siggen/runqueue: Drop do_setscene references

2022-12-11T23:21:27+00:00

do_setscene was from a different era before our modern setscene per task code. It hasn't been used for years so remove some old obsolete references to it. (Bitbake rev: ef72282298f7c4db74383c23bb0251dd06d3c6d3) Signed-off-by: Richard Purdie

bitbake: siggen: Drop non-multiconfig aware siggen support

2022-12-11T23:21:27+00:00

All siggens in common use should now support multiconfig, drop the compatibility code. (Bitbake rev: b36545b4df6d935ed312ff407d4e0474c3ed8d1a) Signed-off-by: Richard Purdie

bitbake: runqueue: Improve error message for missing multiconfig

2022-11-29T10:25:51+00:00

If you place a multiconfig which isn't enabled into an mcdepends you currently get a traceback from runqueue. We can do better, add some code to tell the user what happened in a more readable way without the traceback. [YOCTO #14970] (Bitbake rev: a4693b70764bb394ee2cf8dd12a5f6fce866008b) Signed-off-by: Richard Purdie

bitbake: runqueue: Fix race issues around hash equivalence and sstate reuse

2022-11-22T15:28:27+00:00

We identified a use case where a native recipe (autoconf-native) was rebuilt with no change in output yet the sstate for do_package tasks wasn't being used. The issue is that do_package tasks have a hard dependency on pseudo-native:do_populate_sysroot. That task was one of the many tasks being rehashed when autoconf-native's hash was changed. If update_tasks processed a recipe before it had processed pseudo-native, that recipe would be marked as not possible from sstate and would run the full tasks. The fix is to split the processing into two passes, first to handle the existing covered/notcovered updates, then in the second pass, check whether there are "harddep" issues. This defers the do_package tasks until after pseudo-native is installed from sstate as expected and everything works well again. (Bitbake rev: e479d1e418a7d34f0a4663b4a0e22bb11503c8ab) Signed-off-by: Richard Purdie