Re: [docs] [PATCH 1/1] doc: bitbake-user-manual-metadata: fix inherit_defer documentation

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Dawid,

On 4/24/26 8:23 AM, Dawid Bijak via lists.yoctoproject.org wrote:
> [You don't often get email from bijak.dawid=gmail.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> The documentation for inherit_defer contained the claim
> 
> "If VARNAME is going to be set, it needs to be set before the
> inherit_defer statement is parsed"
> 
> which is incorrect and contradicts the purpose of inherit_defer.
> The wrong claim is replaced with an example which demonstrates
> the contrast between a plain defer statement and the inherit_defer
> statement by using an override assignment placed after inherit_defer
> 
> Additionally the inline python expression examples have been
> moved from the inherit_defer section up to the inherit section, since
> they apply to both directives
> 

I'm pretty sure the whole inherit_defer thing started because an inline 
Python expression didn't work. I vaguely remember a bbappend either 
adding this new inherit based on PACKAGECONFIG containing a value, or 
having the main recipe with this inherit <PACKAGECONFIG.contains> and a 
bbappend modify PACKAGECONFIG. See commit 5c2e840eafeb ("ast/BBHandler: 
Add inherit_defer support") in BitBake.

So I'm very skeptical this is correct.

> Also add an anti-example showing that the previously documented
> pattern of setting the inherited class name from an anonymous
> Python function does not work with inherit_defer.
> 
> Signed-off-by: Dawid Bijak <bijak.dawid@gmail.com>
> ---
>   .../bitbake-user-manual-metadata.rst          | 61 ++++++++++---------
>   1 file changed, 32 insertions(+), 29 deletions(-)
> 
> diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
> index 40cae6b05..38efe6b11 100644
> --- a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
> +++ b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
> @@ -803,7 +803,17 @@ An advantage with the inherit directive as compared to both the
>   :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` and :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
>   directives is that you can inherit class files conditionally. You can
>   accomplish this by using a variable expression after the ``inherit``
> -statement.
> +statement, as in::
> +
> +   inherit ${@'classname' if condition else ''}
> +
> +Or::
> +
> +   inherit ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)}
> +
> +In both cases, if the expression evaluates to an
> +empty string, the statement does not trigger a syntax error because it
> +becomes a no-op.
> 
>   For inheriting classes conditionally, using the :ref:`inherit_defer
>   <ref-bitbake-user-manual-metadata-inherit-defer>` directive is advised as
> @@ -827,39 +837,32 @@ the variable after the line is parsed will take effect. With the :ref:`inherit
> 
>   Here is an example::
> 
> -   inherit_defer ${VARNAME}
> -
> -If ``VARNAME`` is
> -going to be set, it needs to be set before the ``inherit_defer`` statement is
> -parsed. One way to achieve a conditional inherit in this case is to use
> -overrides::
> -
>      VARIABLE = ""
> -   VARIABLE:someoverride = "myclass"
> -
> -Another method is by using :ref:`anonymous Python
> -<bitbake-user-manual/bitbake-user-manual-metadata:Anonymous Python Functions>`.
> -Here is an example::
> +   inherit_defer ${VARIABLE}
> +   VARIABLE:someoverride = "someclass"
> +
> +:ref:`inherit_defer <ref-bitbake-user-manual-metadata-inherit-defer>`
> +defers the evaluation of ``${VARIABLE}`` until the end of
> +parsing. Assuming ``someoverride`` is in :term:`OVERRIDES`, ``${VARIABLE}``
> +expands to ``someclass``, which is then inherited. Contrast this with a plain
> +:ref:`inherit <ref-bitbake-user-manual-metadata-inherit>`, which would evaluate
> +``${VARIABLE}`` immediately, before the ``VARIABLE:someoverride`` assignment
> +is parsed. ``${VARIABLE}`` would expand to an empty string and the statement
> +would become a no-op.
> +
> +Note that assigning the variable from an
> +:ref:`anonymous Python function <bitbake-user-manual/bitbake-user-manual-metadata:Anonymous Python Functions>`
> +does *not* work, because deferred inherits are resolved before anonymous
> +Python functions run::
> 

I vaguely remember reading on IRC we're having some issues with 
anonymous Python functions and parsing lately, so that may be related to 
that. I haven't followed anything in that area so maybe I'm wrong or it 
has already been fixed. So I'm not sure if you just happen to try this 
when things were broken in BitBake or if it's really intended to work 
that way.

Cheers,
Quentin