Re: [bitbake-devel] [docs] [PATCH 1/1] doc: bitbake-user-manual-metadata: fix inherit_defer documentation
Richard Purdie <[email protected]>
| Newsgroups | org.openembedded.lists.bitbake-devel,org.yoctoproject.lists.docs |
|---|---|
| Message-ID | <eeab5758b01722f5474855d21f718ea2d5cabff8.camel@linuxfoundation.org> |
On Mon, 2026-04-27 at 20:14 +0200, Dawid Bijak via lists.openembedded.org wrote: > On Mon, Apr 27, 2026 at 02:35:45PM +0200, 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 [email protected]. 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. > > 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. Cheers, Richard