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

bitbake: parse: Forbid ambiguous assignments to ${.}, ${+}, and ${:} variables

2025-02-05T12:11:01+00:00

Old code that parse variable names in assignment commands behave differently for variables that ends with special symbol for single-character variable names and multi-character variable names. For example: A+="1" # Change variable ${A}, '+' glued to '=' A+ = "1" # Change variable ${A+} +="1" # Change variable ${+}, the '+' symbol not part of assignment operator + = "1" # Change variable ${+} New code would always assume that '.=', '+=', and ':=' is assignment operator. As result code like the following would raise parsing error +="value" While code with extra spaces would work as before + = "value" # Change variable ${+} This change allow to catch issues in code that generate bitbake configuration files in a manner like "echo ${VARNAME}+=${VALUE} >> conf/local.conf" (Bitbake rev: 93059aad13a12cd69d86368795c88e5349197d5d) Signed-off-by: Nikolai Merinov Signed-off-by: Richard Purdie

bitbake: parse/ast: Add support for BB_RECIPE_VIRTUAL_PROVIDERS

2025-01-21T23:09:33+00:00

Currently, providers are set on a global config basis. This change allows for a select set of providers configured in BB_RECIPE_VIRTUAL_PROVIDERS to be selected on a per recipe basis. This would allow for the selection of virtual/cross-cc as gcc or clang for example in OE-Core. DEPENDS and task flag [depends] values are processed. (Bitbake rev: fb119c7888ae8a749aa824f8c51780176af077f9) 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: parse: Add include_all conf file directive

2024-12-17T11:48:25+00:00

In some cases it would be helpful to be able to have an include file in a standard location which is included in all layers that are added to the system. The intent is for these to provide configuration tweaks of specific types so that a given file pattern can be adopted more widely for such configuration. The code will search for any named configuration file within BBPATH, so a configuration directive of: include_all conf/distro/include/myinc.conf would include the myinc.conf file in that subpath if present in any directory in BBPATH. Multiple files will be included if present. (Bitbake rev: d01d5593e7829ac60f37bc23cb87dc6917026471) Signed-off-by: Richard Purdie

bitbake: bitbake: parse: add support for flagged fragment variables

2024-12-13T10:44:35+00:00

It was suggested that using flags in fragment content to mark fragment-specific metadata (such as descriptions and dependencies) is prone to quiet regressions when fragments are renamed or moved, and it clutters the fragment content. With this change allowed fragment metadata variables must be explicitly listed in a variable that is given to addfragment directive, and parser will add the flag containing the fragment name to them. (Bitbake rev: ed9a3ca9426500511feb77f41a146953dbfe9af7) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: parse: add support for 'addfragments' directive

2024-12-08T22:36:11+00:00

It takes two parameters: - location prefix for fragments - name of variable that holds the list of enabled fragments, each of them prefixed by layer id Implementation of this directive essentially expands the fragment list obtained from the variable into absolute fragment paths and hands them to the implementation of 'require'. (Bitbake rev: f687746703e7b096c5480668fd4f49bd4951182b) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: parse/ConfHandler: allow / in variable flags

2024-12-08T22:36:11+00:00

This is beneficial for config fragments, as their names are specified via flags, and those names can include slashes: BB_CONF_FRAGMENT_SUMMARY[init/systemd] = "This fragment enables systemd as an init manager" (Bitbake rev: 80805988492b35593067230f68782a5687c8f557) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: BBHandler/ast: Improve addtask handling

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

The recent addtask improvement to handle comments complicated the regex significantly and there are already a number of corner cases in that code which aren't handled well. Instead of trying to complicate the regex further, switch to code logic instead. This means the following cases are now handled: * addtask with multiple task names * addtask with multiple before constraints * addtask with multiple after constraints The testcase is updated to match the improvements. (Bitbake rev: 417016b83c21fca7616b2ee768d5d08e1edd1e06) Signed-off-by: Richard Purdie

bitbake: BBHandler: Handle comments in addtask/deltask

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

Technically our syntax would allow for comments after an addtask/deltask. Currently these get silently processed in various ways by the code which is bad. Tweak the regex to drop any comments and add test cases to ensure this continues to work in the future. [YOCTO #15250] (Bitbake rev: 64f8796e55a8826ffec0d76b993c8256713f67a3) Signed-off-by: Richard Purdie

bitbake: parse: Improve/fix cache invalidation via mtime

2024-05-16T22:25:55+00:00

We have been seeing obscure failures in devtool, particularly on newer autobuilder workers where it appears the cache is assumed to be valid when it shouldn't be. We're using the 'seconds' granulation mtime field which is not really a good way of telling if a file has changed. We can switch to the "ns" version which is better however also add in inode number and size as precautions. We already have all this data and tuples are fast so there isn't really any cost to do so. This hopefully fixes [YOCTO #15318]. (Bitbake rev: d9e5d313c79500e3c70ab9c3239b6b2180194f67) Signed-off-by: Richard Purdie