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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.