linux/poky.git/bitbake/lib/bb/cookerdata.py, branch styhead-5.1.4

bitbake: cookerdata: Separate out data_hash and hook to tinfoil

2024-08-13T14:47:55+00:00

Within tinfoil, the user can write to the configuration data but it won't cause the data_hash checksum to be re-written, meaning cached parsing data can be reused when it would now be incorrect. Abstract out the data_hash code and add it to the invalidateCaches command, called by tinfoil.modified_files() meaning that tinfoil can instruct bitbake to update the caches and re-parse if necessary. Also move the data_hash entirely into databuilder and drop the copy in cooker as obsolete and not needed. (Bitbake rev: d9ee77829f693ce75348fa64f406fcecfe4989aa) Signed-off-by: Richard Purdie

bitbake: cookerdata: Be consistent with what type bb_data represents

2023-11-23T12:06:06+00:00

In _parse_recipe(), bb_data was initially a datastore object, but then after the call to bb.parse.handle() it was all of a sudden turned into a dict of variant:datastore pairs. At the same time, parseRecipeVariants() used bb_data for datastore objects, while parseRecipe() used it for the dicts of variant:datastore pairs. Change these functions to consistently use "bb_data" for datastore objects and use "datastores" for the dicts of variant:datastore pairs. (Bitbake rev: ed0f94c037476efd465db87726b2480406076beb) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: cooker: Add FILE_LAYERNAME variable containing the layername for a recipe

2023-05-25T12:16:24+00:00

There are times when it would be useful for code to know which layer (or collection in old bitbake terms) it is contained within. Add support for FILE_LAYERNAME to be set by bitbake when parsing a recipe so that it is possible to determine this. To do it, we need to pass data from the cooker into the recipe endpoints, since only the top level cooker information knows about the layer structure which makes the patch a bit painful. The idea is that this would make layer overrides possible: OVERRIDES .= ":layer-${FILE_LAYERNAME}" which then opens possibilities like: WARN_QA:append:layer-core = " patch-fuzz" as an example where OE-Core could enable specific QA tests only for that specific layer. (Bitbake rev: 7090a14b0035842112d073acf7f2ed1a01fdeccf) Signed-off-by: Richard Purdie

bitbake: cookerdata: Drop dubious exception handling code

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

This code appears to be dangerous, it swallows exceptions, turning them into "handled" versions which then show no errors to the user. This is a pretty poor user experience and I can't see why this code should be swallowing such things. Drop the worst bits of code. (Bitbake rev: 13279044f16f2cf2502ebf39d277415f99bb6c18) Signed-off-by: Richard Purdie

bitbake: cookerdata: Improve early exception handling

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

Martin Jansa reported that if you put a syntax error into an imported module such as qa.py in OE, no error is shown. Part of the issue appears to be that the catch_parse_error() decorator only catches certain exceptions and SyntaxError isn't one of them. As far as I can tell we should remove all the special cases and use the more advanced code in all cases, not just expansion errors. I confirmed this now prints a proper error message for a qa.py syntax error. (Bitbake rev: 2365d891847f8e73d1c4661ddfdab8818ff619dc) Signed-off-by: Richard Purdie

bitbake: cookerdata: Remove incorrect SystemExit usage

2023-02-17T15:10:02+00:00

Calling SystemExit doesn't work well with server/client usage since the string isn't printed to the right place. Use bb.fatal() instead which prints the right log output and raises and handled exception which then shows correctly on the UI. (Bitbake rev: aaefb43b41a0d9b16a59643136268eb6e5d48cd2) Signed-off-by: Richard Purdie

bitbake: cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location

2023-01-26T21:50:31+00:00

Currently the codeparser cache is set from CACHE, which is typically in bitbake.conf which means we can't read/write any cache until it is found/read. We may well have python expressions to parse before that happens. The net result is suboptimal functioning of the codeparser cache since it will often be invalidated by data that is never written. This patch changes the codeparser and filechecksum caches to use BB_CACHE as their setting and defaults it to ${TOPDIR}/cache. The patch doesn't change where the "persistent" data such as prserver and hash-equiavalance resides (PERSISTENT_DIR) or where the metadata parsing cache resists (still currently CACHE). I've left those for a later patch. The patch does ensure data parsed by the core datastore parsing calls is written back since this is now much more useful after this change. (Bitbake rev: ee89ade5b5a4cf9c53f336d8b800e06fbe436628) Signed-off-by: Richard Purdie

bitbake: cookerdata: Fix previous commit to use a string, not a generator

2023-01-02T00:29:09+00:00

The previous commit was injecting a generator object instead of a string, which happened to fix the issue but we should fix it properly! Thanks to Christopher Larson for spotting. (Bitbake rev: 36589f13c5babb3b2af82666c8a96338e6ea4eb9) Signed-off-by: Richard Purdie

bitbake: cookerdata: Fix cache/reparsing issue

2023-01-01T14:25:20+00:00

When setting the LAYERSERIES_COMPAT and LAYERSERIES_CORENAMES variables, we need to be deterministic. The random ordering from the sets was causing unexpected reparses. (Bitbake rev: 8c405c97430ac830837e25438e8795f6f7abbdaa) Signed-off-by: Richard Purdie

bitbake: cooker/cookerdata: Rework the way the datastores are reset

2022-12-31T17:05:17+00:00

As far as I could tell, the current code could result in some strange situations where some data was set back to the original data store copy but the multiconfig data was not restored. There are also some changes made to the datastore which did not persist. The data store was also being reset at every client reset, which seems a little excessive if we can reset it to the original condition properly. Move the __depends -> __base_depends rename into databuilder along with the __bbclasstype change so these are saved in the original data. Tweak the databuilder code to be clearer and easier to follow on which copies are where, then save copies of all the mc datastores. Finally, drop the cache invalidation upon reset for the base config as we shouldn't need that now (oe-selftest -r tinfoil works with memory resident bitbake which was the original reproducer requiring that change). (Bitbake rev: 5f8b9b9c35b4ec0c8c539bf54ca85f068f4a5094) Signed-off-by: Richard Purdie