mbox series

[0/1] doc: bitbake-user-manual-metadata: clarify inherit_defer documentation

Message ID 20260424062631.821571-1-bijak.dawid@gmail.com
Headers show
Series doc: bitbake-user-manual-metadata: clarify inherit_defer documentation | expand

Message

Dawid Bijak April 24, 2026, 6:26 a.m. UTC 
Hi,
I've been reading through the inherit_defer documentation, and granted my limited knowledge of bitbake,
I think the current documentation is incorrect or misleading in a few places:

1)
    The sentence "If VARNAME is going to be set, it needs to be set before the inherit_defer statement is parsed"
    seems plainly wrong and defeats the purpose of inherit_defer.
    As I understand it, the whole point of deferred evaluation is that assignments made after the directive are taken into account.

2)
    The examples using inline Python, e.g. inherit_defer ${@'classname' if condition else ''},
    are not specific to inherit_defer - they would work equally well with plain inherit.
    They probably belong in the inherit section.

3)
    The suggested technique of assigning the class name from an anonymous Python function does not appear to work:

    python () {
        if d.getVar('SOMETHING') == 'value':
            d.setVar('VARIABLE', 'someclass')
        else:
            d.setVar('VARIABLE', '')
    }
    inherit_defer ${VARIABLE}

    From my experiments, inherit_defer is resolved before anonymous Python functions run, so ${VARIABLE} always expands to empty
    and the inherit is a no-op.

    Is that the intended order and the documentation is wrong, or is this a bug in bitbake, or did I just get it wrong?

Anyway, just in case, the attached patch rewords the documentation to address points 1 and 2, and adds a note about point 3.
Happy to revise if I've misunderstood any of it.

Thanks,
Dawid

Dawid Bijak (1):
  doc: bitbake-user-manual-metadata: fix inherit_defer documentation

 .../bitbake-user-manual-metadata.rst          | 61 ++++++++++---------
 1 file changed, 32 insertions(+), 29 deletions(-)