linux/poky.git/bitbake/lib/bb/parse, branch master-next

bitbake: parse: Make include_all raise a parse error for absolute paths

2025-11-07T13:15:35+00:00

It makes no sense to use an absolute path with include_all. (Bitbake rev: 2b19f7b1678974050192a1962244bba594c07bc1) Signed-off-by: Peter Kjellerstedt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

bitbake: parse: Make include_all support empty variable expansions

2025-11-07T13:15:35+00:00

include and require support empty variable expansions, typically used with conditional expansions. However, include_all does not, and instead reports an error for the first path in BBPATH. Rewrite include_all so that its behavior matches include and require. (Bitbake rev: 7e3a64b853b5374205c05b0ab09122f09a1eedfb) Signed-off-by: Peter Kjellerstedt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

bitbake: ast: Better variable history for builtin fragments

2025-11-07T13:15:34+00:00

As of now, the variable history for builtin fragments looks like this (edited for clarity): $ bitbake-getvar MACHINE # # $MACHINE [2 operations] # set ast.py:368 [check_and_set_builtin_fragment] # "qemux86-64" # pre-expansion value: # "qemux86-64" MACHINE="qemux86-64" User can't know where MACHINE was set, this is bad. This patch tries to reconstruct a MACHINE history from OE_FRAGMENTS history. With this patch, history looks like this (for a simple case): $ bitbake-getvar MACHINE NOTE: Starting bitbake server... # # $MACHINE [2 operations] # set .../auto.conf:2 # "qemux86-64 (OE_FRAGMENTS contains "machine/qemux86-64")" # pre-expansion value: # "qemux86-64" MACHINE="qemux86-64" The path where the "machine/qemux86-64" fragment was added to OE_FRAGMENTS is displayed, this is definitely better. Fixes [YOCTO #15939] (Bitbake rev: 54053e0e402c1ed9ae5fe4ed04fc690ecd4b779f) Signed-off-by: Yoann Congal Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

bitbake: ast: Warn on multiple builtin config fragments for the same variable

2025-10-13T22:30:31+00:00

Having multiple builtin config fragments for the same variable (eg OE_FRAGMENTS = "... machine/A ... machine/B") is not supported. Warn the user to make them fix this but continue with the normal variable evaluation : the last affectation "wins". Added warning looks like: WARNING: Multiple builtin fragments are enabled for machine via variable OE_FRAGMENTS: machine/qemux86-64 machine/test machine/qemux86-64. This likely points to a mis-configuration in the metadata, as only one of them should be set. The build will use the last value. (Bitbake rev: 1c12aa23f6678dc289fc0e0d8b4dad311bd39c35) Signed-off-by: Yoann Congal Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

bitbake: ast: Fix fragment behaviour with overrides

2025-10-09T11:48:47+00:00

Imagine a machine fragment machine/A and a configuration which sets: MACHINE = "B" MACHINE:forcevariable = "C" As I understand it, the fragment behaviour was intended to replace the MACHINE = "B", so the override would still be active. The current code replaces all variable overrides. parsing=True, switches to the other behaviour, which I believe was the design intent and the behaviour users would expect. This is useful to allow test configurations to override a MACHINE setting without change the fragments which would complicate the test code. (Bitbake rev: f65bc6aaf4c11bc7e566c895209c093627a3015b) Signed-off-by: Richard Purdie

bitbake: parse/ast: add support for 'built-in' fragments

2025-06-20T11:03:37+00:00

When reviewing proposed fragments to add settings for DISTRO and MACHINE, RP noted that such fragments only add clutter and overhead, and there's no need to maintain them as separate files. Rather when bitbake sees 'fragmentvar/fragmentvalue' it can expand that into FRAGMENTVAR = "fragmentvalue". To achieve that, 'addfragments' directive is extended with a parameter that sets the name of the variable that holds definitions of such built-in fragments, for example like this: "machine:MACHINE distro:DISTRO" Then each enabled fragment name is matched against these definitions and the respective variable is set, e.g. 'machine/qemuarm' would match 'machine:MACHINE' and result in MACHINE set to 'qemuarm'. This happens before any fragment files are looked up on disk, and no such lookup happens if there was a match, which should prevent possible misuse of the feature. So the builtin fragment definition is also an allowlist for them. Please also see the patches for oe-core that show an application of the feature. (Bitbake rev: 3b9d7bea915dc7f10e845854f1dae325743f9456) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: ast/BBHandler: Add support for BB_DEFER_BBCLASSES

2025-06-16T21:23:18+00:00

Add support for automatically promoting class inherits to deferred inherits by listing them in the BB_DEFER_BBCLASSES variable. (Bitbake rev: 8e741b2e885a12d119788d04aa4efcd724dd6bfa) Signed-off-by: Richard Purdie

bitbake: event: Add event for deferred inherits

2025-06-16T21:23:18+00:00

Now that deferred inherits are extension specific, we can pass this list to an event, which our metadata can use to set class overrides earlier (as an example). There are limitations to this, the list of classes is unexpanded and recursive classes are not visible. There isn't much that can be done about this, the ones we are interested in would usually be visible at the top level (such as class extensions). (Bitbake rev: 205d461c05fc7b4a7c81039af3bc3fd71cbb982c) Signed-off-by: Richard Purdie

bitbake: ast: Change deferred inherits to happen per recipe

2025-06-16T21:23:18+00:00

Currently deferred inherits get processed once for all class extensions as a minor speed optimisation. Unfortunately this limits our options for being able to report deferred classes to our code. There are two challenges with using our deferred classes in OE at present. One is that PACKAGECONFIG values don't work well with class overrides like class-native if there are deferred classes based on PACKAGECONFIG, such as python support. The second is that toolchain selection is proving problematic to implement due to interactions between the toolchain deferred inherit, the class extensions and class overrides being very late. By changing deferred inherits to be recipe extension specific, we open the way to generate events and "peek" at where things will end up, allowing the class overrides to be set earlier. The class extension code is updated to use a deferred inherit for the class extension inheriting so that it is still inherited last. (Bitbake rev: 29277cf4d88eb4dfa9572851177d009eab5afd0c) Signed-off-by: Richard Purdie

bitbake: parse/ConfHandler: Add warning for deprecated whitespace usage

2025-04-16T16:41:51+00:00

A lack of whitespace around variable assignment operators makes the files harder to read. There is a deeper issue in that a "+" character can sometimes be confused between the variable name and the assignment operator. Start showing warnings for such usage so we encourage people to use consistent whitespace which helps with file readability in general. (Bitbake rev: 24772dd2ae6c0cd11540a260f15065f906fb0997) Signed-off-by: Richard Purdie