linux/poky.git/bitbake/lib/bb/data_smart.py, branch 5.2_M3

bitbake: data_smart.py: clear expand_cache in _setvar_update_overridevars

2025-03-06T16:32:47+00:00

At the end of this function, self.overrides is cleared, which means we'll construct a new self.overrides after this call. And a new self.overrides will give out different expand_cache, so the old expand_cache should also be cleared to avoid any wrong value. Currently, there's a problem revealed by recent recipe specific virtual provider patch. If we enable multilib and set "OVERRIDES:prepend" in local.conf, things don't work. Here's the error message: ERROR: Nothing PROVIDES 'lib32-gcc-cross-x86_64' Below are reproduce steps: 1. Add in local.conf the following lines: MACHINE ?= "qemux86-64" require conf/multilib.conf MULTILIBS ?= "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32" OVERRIDES:prepend = "some-override:" (Note that using :append and :remove also reproduces the issue.) 2. bitbake -n lib32-sysstat (bitbake -n core-image-minimal also reproduces the issue) The expandWithRefs calls getVar, which fills expand_cache. So when setting OVERRIDES:prepend, this will fill the expand_cache. When overridevars are updated, if we don't clear expand_cache, we'll retrieve wrong values. Previously, things happened to work because there's a call to expand PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc, which in turn expands TARGET_VENDOR. Now what we expand is PREFERRED_PROVIDER_ virtual/cross-cc, so the problem is revealed. (Bitbake rev: 842e94234c9b9faf4e902721f516071f643e49c9) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: data_smart.py: simple clean up

2025-03-06T16:32:47+00:00

When var matches __setvar_regexp__, which has the value as below, __setvar_regexp__ = re.compile(r'(?P.*?)(?P:append|:prepend|:remove)(:(?P[^A-Z]*))?$') the keyword will not be __doc__ or __module__ and var will always contain ":". (Bitbake rev: 0af396917fe176df7b1ed0bd7c7267507ed12e03) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: data_smart.py: remove unnecessary ? from __expand_var_regexp__

2025-03-06T16:32:47+00:00

The non-greedy modifier suffix ? is not necessary here because } is not in the character set [a-zA-Z0-9\-_+./~:]. (Bitbake rev: 80735719d0002c02b704a49604ddd82c461203a2) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: data_smart: fix indentation

2025-02-25T15:27:28+00:00

Fix 8 spaces indentation to be 4 spaces. (Bitbake rev: 973866d134f0493bb3034593fe03cb8bf8920c5c) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: bitbake: data_smart: fix ??= operator for variable flags

2025-02-13T22:24:27+00:00

Variable flags have been fixed in commit 0329a7e3ac694737f2d2c1861f65492551360663 which introduces the "_defaultval_flag_" prefix for default values. This must not be ignored in delVarFlags and getVarFlags. Fixes [YOCTO #15685] (Bitbake rev: 2ee079fc1b7cf6d384ca17bd034b0a40461d9d18) Signed-off-by: Louis Rannou Signed-off-by: Richard Purdie

bitbake: data_smart: fix ??= operator for variable flags

2025-01-14T09:51:45+00:00

??= operator works for variable value by defining a "_defaultval" flag. Use something similar for flags: For the default value of the flag "flag_name", define a flag "_defaultval_flag_flagname" that is used when reading flag_name but no other value has been set. Fixes [YOCTO #15685] (Bitbake rev: 0329a7e3ac694737f2d2c1861f65492551360663) Signed-off-by: Yoann Congal Reviewed-by: Ghislain Mangé Suggested-by: Ola Nilsson Signed-off-by: Richard Purdie

bitbake: data_smart: Improve performance for VariableHistory

2024-08-03T10:37:47+00:00

Fixed: - BBMULTICONFIG = "qemux86-64 qemuarm64" and more than 70 layers in BBLAYERS $ bitbake -p -P Check profile.log.processed, the record() cost more than 20 seconds, it is less than 1 second when multiconfig is not enabled, and there would be the following error when more muticonfigs are enabled: Timeout while waiting for a reply from the bitbake server Don't change the type of loginfo['detail'] or re-assign it can make record() back to less than 1 second, this won't affect COW since loginfo is a mutable type. The time mainly affected by two factors: 1) The number of enabled layers, nearly 1 second added per layer when the number is larger than 50. 2) The global var such as USER_CLASSES, about 1 ~ 2 seconds added per layer when the layers number is larger than 50. (Bitbake rev: 0596aa0d5b0e4ed3db11b5bd560f1d3439963a41) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: data_smart: directly check for methodpool functions in context lookup

2023-08-04T10:37:56+00:00

We previously checked for the existence of the 'func' flag to determine if we should avoid looking up in the metadata. This was done to ensure the user gets the function for 'def' python functions rather than their string contents. We can sidestep the metadata lookup and check our function context directly, instead. (Bitbake rev: 6cac1eac51efa9a54e8457f60ea1ea0e604c50b7) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: data_smart: check for python builtins directly for context lookup

2023-08-04T10:37:55+00:00

This avoids the need to hardcode a list of python builtins. This also slightly changes behavior, in a case like `${@eval("3")}`, this will ensure we always call the builtin, even if the metadata has an 'eval' variable defined. (Bitbake rev: 9976ae50677b333d646ca0fd395468bd2301d03f) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: data_smart: Small optimisation to _findVar()

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

Some users of _findVar don't need the override data and even getVarFlag doesn't need it in some common cases (parsing=True). Rearrange the code as the current overridedata approach doesn't need to be in the _findVar code anyway. This removes some search overhead from a critical path. (Bitbake rev: fcb64e1138a20eb19560af3fc5d1fa748cc9cf34) Signed-off-by: Richard Purdie