linux/poky.git/bitbake/lib/bb/data.py, branch scarthgap-5.0.15

bitbake: codeparser/data: Ensure module function contents changing is accounted for

2024-07-26T14:43:46+00:00

Currently, if a pylib function changes contents, the taskhash remains unchanged since we assume the functions have stable output. This is probably a poor assumption so take the code of the function into account in the taskhashes. This avoids certain frustrating build failures we've been seeing in automated testing. To make this work we have to add an extra entry to the python code parsing cache so that we can store the hashed function contents for efficiency as in the python module case, that isn't used as the key to the cache. The cache version changes since we're adding data to the cache. (Bitbake rev: 4bf332ccac283ca3440e81d8c781fcc23fe10b98) Signed-off-by: Richard Purdie (cherry picked from commit b2c3438ebe62793ebabe2c282534893908d520b4) Signed-off-by: Steve Sakoman

bitbake: data: Add missing dependency handling of remove operator

2023-09-20T07:57:41+00:00

A recipe variable handles its dependencies even on the "contains" variables within the "inline Python expressions" like bb.utils.filter(). And it also handles those in the append operator correctly, but the problem is that it does not so in the remove operator. Fix it by adding the missing dependencies every time the remove operator has been handled. Also add a test case to check if the override operators handle dependencies correctly. (Bitbake rev: b90520eedb1dbc7f6a3928d089fe74fafb864eb5) Signed-off-by: Insu Park Signed-off-by: Richard Purdie

bitbake: data: Evaluate the value of export/unexport/network flags

2023-02-17T18:02:04+00:00

Currently the export/unexport/network flags are acted on only by presence or lack of in the data store. This is deliberate due to performance reasons since a given recipe shell task might export ~80-90 variables and this means expanding flags for every one of them. This does catch users unaware since values which expand to nothing don't work e.g. ${@""} and setting values to "0" wouldn't work either. The downside to this patch is slow down in parsing speed of around 4%. The network flag is easier to change and doesn't affect performance, it was made to operate the same as export/unexport for consitency reasons. (Bitbake rev: 3d96c07f9fd4ba1a84826811d14bb4e98ad58846) Signed-off-by: Richard Purdie

bitbake: data: Add support for new BB_HASH_CODEPARSER_VALS for cache optimisation

2023-01-24T21:59:44+00:00

Currently the codeparser cache ends up being extended for every parse run since there are values in the functions such as the result of os.getpid() from LOGFIFO in OE-Core. Digging into that issue, there are also lots of similar but different functions being parsed where the change might just be a path to WORKDIR, a change in PN or PV or something like DATE/TIME. There is no reason we have to use these changing values when computing the dependenies of the functions. Even with a small tweak like: BB_HASH_CODEPARSER_VALS = "LOGFIFO=/ T=/ WORKDIR=/ DATE=1234 TIME=1234 PV=0.0-1 PN=nopn" the cache is reduced from ~4.6MB, increasing by ~300kb for every parse run to around 1.3MB and remaining static for oe-core and meta-oe. In my local build, admittedly heavily experimented with, the cache had grown to 120MB. The benefits of doing this are: * faster load time for bitbake since the cache is smaller to read from disk and load into memory * being able to skip saving the cache upon shutdown * lower memory footprint for bitbake * faster codeparser data lookups (since there is less data to search) We only use these special values when passing code fragments to the codeparser to parse so the real variable values should otherwise be used in the hash data. The overall effect of this change, combined with others to avoid saving unchanged cache files can be ~2s on a ~16s parse on my local system and results in a more responsive feeling bitbake. It also allows parsing performance to be investigated more consistently. (Bitbake rev: f24bbaaddb36f479a59a958e7fc90ef454c19473) Signed-off-by: Richard Purdie

bitbake: ast/data/codeparser: Add dependencies from python module functions

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

Moving code into python modules is a very effective way to reduce parsing time and overhead in recipes. The downside has always been that any dependency information on which variables those functions access is lost and the hashes can therefore become less reliable. This patch adds parsing of the imported module functions and that dependency information is them injected back into the hash dependency information. Intermodule function references are resolved to the full function call names in our module namespace to ensure interfunction dependencies are correctly handled too. (Bitbake rev: 605c478ce14cdc3c02d6ef6d57146a76d436a83c) (Bitbake rev: 91441e157e495b02db44e19e836afad366ee8924) Signed-off-by: Richard Purdie

bitbake: data: Tweak code layout

2022-12-08T10:49:53+00:00

Make a small change in the layout of the code in build_dependencies which makes subsequent patches easier to read. No functionality change, just moving the function definitions to the start of the function block. (Bitbake rev: fff13b1e5e8397130b4378e0ba2301336ec651a2) Signed-off-by: Richard Purdie

bitbake: data: Drop obsolete pydoc/path code

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

This code looks like it is from a time when the data module was executable. Nobody does that now and this usage of pydoc is long since obsolete/broken so clean up the code which doesn't do anything useful. (Bitbake rev: 6f4ef770641a9657edaf8618f4c86dfb1116622c) Signed-off-by: Richard Purdie

bitbake: data/siggen: Switch to use frozensets and optimize

2022-11-23T18:27:07+00:00

Python handles frozensets a little more optimally than normal sets. Once we finish parsing, we don't edit this data so we can convert to them. To do that, we need to stop changing them so process ignore_deps earlier then we can freeze the data and keep it frozen. This has the side effect that we need to be careful to sort the data in some of the variables when calculating the hashes. Overall this does seem to show a decent parsing time speed improvement of 20-25% in a local test but this would be highly setup dependent. Also ensure the sigdata can handle exported frozenset and make it import back to them instead of sets. (Bitbake rev: 19475627c363a52da49ec144422c87448ff2a6c5) Signed-off-by: Richard Purdie

bitbake: data/data_smart/build: Clean up datastore finalize/update_data references

2022-11-14T16:22:00+00:00

We dropped the update_data calls a while ago. Clean up the code to match the reality and drop the remaining no-op pieces. Update the comments to reflect the slowest operations and let the cookie monster's spirit live on! (Bitbake rev: 584989ed2b5af4e8799571dece0cf94f995ef14e) Signed-off-by: Richard Purdie

bitbake: data: drop unused __expand_var_regexp and expand_python_regexp__

2022-11-10T14:43:06+00:00

First, commit 81efd77987f6decf256967fa16521a40c14d3518 created a copy of __expand_var_regexp__ and __expand_python_regexp__ when creating the initial version of data_smart.py. A while later commit db1c998b31da06d7f3eb09fc6f59a1915b7b549e dropped all references to these variables from data.py. This leaves us today with two versions of these variables in the global scope. However, only those defined in data_smart.py are being used, in data_smart.py. Unfortunately there was no indication in the commit log for commit db1c998b31da indicating why the variables were left in place despite the functions referencing them were being removed. Additionally data.py imports data_smart, thus the versions of __expand_var_regexp__ and __expand_python_regexp__ defined in data_smart.py would be used by all bitbake code, beyond, potentially, some code in data.py which we know has no references to these variables. To remove any potential confusion around these variables drop the old definitions from data.py. (Bitbake rev: 60f43d0428d43c981b44b6c8d125f77440f6c8f9) Signed-off-by: Mark Asselstine Signed-off-by: Richard Purdie