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

bitbake: lib/bb/siggen: fix debug() call

2023-02-24T15:38:24+00:00

Bitbake f68682 changed the logger's debug() method to be compatible with logging.debug(), but this caller was still using the old API where you can pass an integer as the first argument: WARNING: Invalid arguments in bbdebug: (1, 1, 'Found unihash[...]') Instead, call bbdebug() which has the priority argument. (Bitbake rev: 18d4f9e8387f7994cf6d46300e25dda1c3a593b2) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: siggen: Fix inefficient string concatenation

2023-02-04T17:03:15+00:00

As discussed in https://stackoverflow.com/a/4435752/1710392 , CPython has an optimization for statements in the form "a = a + b" or "a += b". It seems that this line does not get optimized, because it has a form a = a + b + c: data = data + "./" + f.split("/./")[1] For that reason, it does a copy of data for each iteration, potentially copying megabytes of data for each iteration. Changing this line causes SignatureGeneratorBasic::get_taskhash to take 0.06 seconds instead of 45 seconds on my test setup where SRC_URI points to a big directory. Note that PEP8 recommends explicitely not to use this optimization which is specific to CPython: "do not rely on CPython’s efficient implementation of in-place string concatenation for statements in the form a += b or a = a + b" However, the PEP8 recommended form using "join()" also does not avoid the copy and takes 45 seconds in my test setup: data = ''.join((data, "./", f.split("/./")[1])) I have changed the other lines to also use += for consistency only, however those were in the form a = a + b and were optimized already. Co-authored-by: JJ Robertson (Bitbake rev: 195750f2ca355e29d51219c58ecb2c1d83692717) Signed-off-by: Etienne Cordonnier Signed-off-by: Richard Purdie

bitbake: siggen: Minor code improvement

2022-12-21T14:15:26+00:00

Tweak the code to remove duplication and only set if the attribute isn't already there to avoid overwriting. (Bitbake rev: 513e6c4e9233e0d0bc31e1169077fdbf9aaf4ec3) Signed-off-by: Richard Purdie

bitbake: siggen: Clarify which fn is meant

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

"fn" can mean different things in bitbake, we added support for class extensions and then mutlticonfigs by extending it. In siggen, it generally means that mc is prefixed to it and that it is a virtual filename. Replace "fn" with "mcfn" in the code to make this clearer as if I'm getting confused, everyone else likely is as well. "mcfn" is sometimes referred to as taskfn as well but mcfn is probably the easiest to understand as the taskname isn't included. (Bitbake rev: e1c1139ab90f8da1b5036db11d943daefbe87859) 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: siggen: Add dummy dataCaches from task context/datastore

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

One of the challenges in maintaining the code is that it sometimes uses a datacaches structure and sometimes a datastore. Rather than continue the current dual API madness, have the worker contexts create a dummy datacaches structure with the entries we need. Whilst this does need to be kept in sync with the real structure, that doesn't change and this allows the code to be simplified. With this new approach, we can unify the stamps dependency code again. (Bitbake rev: c6d325fc9b53e9d588ab273ee3c2a99a70fba42c) 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