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

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

On 4/27/26 2:35 PM, Quentin Schulz wrote:
> 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.
> 

Reading my mail backlog, I just stumbled upon 
https://lore.kernel.org/openembedded-core/CANPvuRk19e3PhcVXxLUJTjaPE9bMXO-04MLytqGNpA0=PEzeeA@mail.gmail.com/ 
where Jose links to 
https://git.openembedded.org/openembedded-core/commit/?id=6b553a5042b9d5828a9da675ede16e10f06dae90 
which does indeed mention this is a known limitation:

"""
Anonymous python is executed after all inherits including deferred 
inherits are processed.
"""

So this part is fine :)

Cheers,
Quentin