BitBake Deferred Inheritance: Resolve a Conditional Class at the Right Parse Stage

A conditional class name is empty when an inherit statement is encountered, but a later recipe assignment supplies the intended name. The final environment may look correct while the class's functions are absent. The problem is when the class expression was resolved, not whether the variable eventually acquired a value.

The examined BitBake 2.8 maintenance code supports inherit_defer for this timing problem. Its boundary matters: deferred inheritance is processed during finalization, before anonymous Python runs. It is not an instruction to wait until every possible metadata mutation has finished.

Contrast immediate class selection with a queued expression

The ordinary inherit documentation says a variable used for conditional inheritance must be available when that directive is parsed. An empty expression performs no inheritance.

The examined recipe parser recognizes inherit_defer separately. Both paths ultimately use the class loader, which expands the requested names and resolves their class files. The difference is when that loader is invoked.

For an illustrative selector, inherit_defer ${REPORT_CLASS} can appear before an ordinary REPORT_CLASS = "reportstage" assignment. Provided that value is established before the deferred queue is processed and the class is discoverable, the loader sees the later value. An ordinary inherit at the earlier position would resolve the selector then.

Check your actual checkout before using the syntax. This article relies on the linked maintenance-branch implementation; it does not assume every older BitBake installation recognizes the directive merely because a newer class file uses it.

Follow the finalization boundary precisely

The AST finalization code stores deferred inheritance requests with their originating filename and line. Finalization removes queued requests in order and passes them to the class loader. Recipe appends are handled before this finalization stage.

Later in the same routine, BitBake runs anonymous Python. Consequently, setting REPORT_CLASS only inside an anonymous Python function is too late for an already processed deferred request. Moving that anonymous function visually above the directive does not change its execution phase.

Use an ordinary assignment or an appropriate inline expression whose inputs are ready at the deferred boundary. Do not rely on a late anonymous mutation to repair a missing inheritance and then diagnose the resulting absence as a class-path problem.

Recognize why an image class uses the mechanism

The examined Scarthgap image class assembles IMGCLASSES from several image choices and invokes inherit_defer ${IMGCLASSES}. This is a concrete use of late class selection, rather than a requirement for authors to convert all inheritance statements.

For a custom image extension, inspect which variable contributes the class and when it is assigned. Appending a class name after an ordinary inherit already resolved an empty selector will not revisit that earlier decision. Conversely, changing a value after finalization is not supported by the deferred mechanism either.

Deferred processing can also expose ordering assumptions within your classes. If one deferred class changes a selector used by a later queued request, inspect the order and the resulting definitions. Prefer explicit inputs over a chain whose meaning depends on incidental class side effects.

Diagnose timing separately from discovery and implementation

Build a minimal parse-only example using a class that sets a distinctive marker variable. Compare ordinary and deferred directives with the same later assignment, then inspect the marker's origin and final function definitions using bitbake -e for the test recipe.

If inheritance is attempted but fails to locate the class, investigate BBPATH and the class layout. If the class is found but a function is replaced later, inspect that function's assignment history. Neither failure is corrected simply by adding more deferred directives.

Accept the change when the intended class is selected at the intended parse phase and its required definitions survive finalization. Keep that claim separate from whether its tasks execute correctly: class selection is a metadata result, not a build or target-runtime test.