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

Hi Dawid,

On 4/29/26 4:11 PM, Dawid Bijak wrote:
> Hi,
> 
> On Tue, Apr 28, 2026 at 09:42:28PM +0100, Richard Purdie wrote:
>> On Mon, 2026-04-27 at 20:14 +0200, Dawid Bijak via lists.openembedded.org wrote:
>>> Hi Quentin,
>>> Thanks for your response.
>>> I'm afraid I don't quite follow your point about PACKAGECONFIG.contains.
>>> I'm not sure what you're referring to exactly.
>>> But, as far as I can tell, the inherit statement works fine with inline python expressions.
>>> I think, it evaluates the expression in place, much like := would.
>>>
>>> For example, on current master I tried the following:
>>>   COND = ""
>>>   COND:append = " x"
>>>   inherit ${@bb.utils.contains('COND', 'x', 'foo', 'bar', d)}
>>> This inherits foo.
>>>
>>> However, if I move the :append below the inherit directive:
>>>   COND = ""
>>>   inherit ${@bb.utils.contains('COND', 'x', 'foo', 'bar', d)}
>>>   COND:append = " x"
>>> it inherits bar.
>>
>> It works, as long as you are sure that COND won't be changed after the
>> inherit. When mutliple files altering the variables are involved, that
>> is often unclear. I think the doc's intent is therefore to recommend
>> anything with variable accesses is therefore deferred, unless the user
>> is sure they know what they're doing.
> 
> Richard, thanks for chiming in. Your explanation reassures me that my understanding
> of inherit_defer was correct.
> 
> In summary, I believe the 3 issues with the current documentation that I identified
> in the cover letter are still valid, and my patch still applies.
> 

1) The sentence should only apply to the inherit statement, and not 
inherit_defer as that's the point of inherit_defer. So this is fine.

2) NACK. We're deliberately not documenting footguns. You can provide an 
example if you really want to in the inherit section, and add a big fat 
warning after it that it'll break in some scenario so you really 
shouldn't do that and instead use inherit_defer.

3) This is fine, thanks for the fix.

I would suggest to make three separate commits, with 2) last, that way 
we can pick 1) and 3) (which will become 1) and 2)) and argue on 2) 
(which will become 3)) without hindering merging of the other commits.

Cheers,
Quentin