linux/poky.git/bitbake/lib/bb/parse/ast.py, branch 5.2_M2

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: 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: ast/BBHandler: Add inherit_defer support

2024-01-18T10:15:58+00:00

Add support for an inherit_defer statement which works as inherit does but is only evaulated at the end of parsing. This allows conditional expressions to be evaulated 'late' meaning changes to PACKAGECONFIG from bbappends can be applied for example. This addresses a usability/confusion issue users have with the current conditional inherit mechanism since they don't realise the condition has to be expanded immediately with the current model. There is a commented out warning we could enable in future which warns about the use of a conditional inherit that isn't deferred. There is a behaviour difference in the placement of the inherit, particularly around variables set using ?= which means wen swapping from one to the other, caution must be used as values can change. (Bitbake rev: 5c2e840eafeba1f0f754c226b87bfb674f7bea29) Signed-off-by: Richard Purdie

bitbake: ast: Fix EXPORT_FUNCTIONS bug

2024-01-10T13:55:33+00:00

If you have two classes, both of which set EXPORT_FUNCTIONS for the same funciton and a standard funciton definition for the function that is exported, the export function can sometimes overwrite the standard one. The issue is that the internal flag the code uses isn't ovweritten if the variable is giving a new value. Fix the issue by using a comment in the code that is injected so that we know if it is ours or not. Also add some testing for EXPORT_FUNCTIONS, not perfect but a start. (Bitbake rev: 66306d5151acb0a26a171c338d8f60eb9eb16c6b) Signed-off-by: Richard Purdie

bitbake: fetch2: Add autorev warning when it is set too late

2023-03-22T13:57:04+00:00

Bitbake expects a consistent metadata environment when it parses. There are plenty of ways you can set a recipe to autorev at a point where parts of the fetcher have already been triggered leading to obsure bugs which I struggled to debug, let alone anyone not familar with the code. If anyone is running into the message from the commit, the issue is likely one of timing. Keep in mind that the anonymous python code in base.bbclass will expand variables like FILESPATH, WORKDIR and others which contain PV. The recipe needs to be set to AUTOREV before that anonymous python runs. In particular, that means you can't set SRCREV = "${AUTOREV}" in other anonymous python, it needs to happen earlier. (Bitbake rev: 4d9ec332d5bfc8b60b54f8ec2a17d34e35aa903a) 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