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

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 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

bitbake: codeparser: Add function decorators for vardeps

2025-04-10T10:07:38+00:00

Adds bb.parse.vardeps bb.parse.excludevardeps function decorators that can be used to explicitly add or exclude variables from a python function parsed by bitbake (Bitbake rev: 030fb3dee067640a3a50f24a53d200bdb5048376) Signed-off-by: Joshua Watt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

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