summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/cooker.py
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2016-05-12 17:00:10 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2016-05-14 23:05:14 +0100
commitda467519c2624496ad8f939bf494e8f9aff4d9e3 (patch)
tree3141ac13ac7a2ca618e451c983621c66951b484f /bitbake/lib/bb/cooker.py
parentff5d6f8854264914d28b8b0d45c017b17a6ef185 (diff)
downloadpoky-da467519c2624496ad8f939bf494e8f9aff4d9e3.tar.gz
bitbake: runqueue.py: always emit bb.event.DepTreeGenerated
The data included in the event is useful for implementing a pre-build check that warns about unexpected components, for example because of an incorrect configuration or changed dependencies. Such a check can be done in a .bbclass that gets inherited globally. But in contrast to a UI, such a class cannot request that the event shall be emitted, and thus the event has to be emitted whether there is a consumer or not. This was done conditionally earlier out of concerns about the performance impact. But now events are handled more efficiently, so that concern no longer seems valid: in some simple testing (admittedly on a fast build workstation), the two lines (generating the data and emitting the event with it) only took about 0.05 seconds (measured with timeit). That was for a build with roughly 500 recipes (from pn-buildlist aka depgraph['pn']), triggered via the command line. That was even with a consumer of the data active and doing some work, so it should be even faster when there is no consumer. (Bitbake rev: 5ddaf5b7ed1001d2dd3f67e7a6d704afa85479d2) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/cooker.py')
0 files changed, 0 insertions, 0 deletions