Re: [bitbake-devel] [docs] [PATCH 1/1] doc: bitbake-user-manual-metadata: fix inherit_defer documentation
Dawid Bijak <[email protected]>
| Newsgroups | org.openembedded.lists.bitbake-devel,org.yoctoproject.lists.docs |
|---|---|
| Message-ID | <qwehgszst3cphuw4jqsj2u36333p2lpo6cytkdcx22prjmxrdx@acnraxmxwfl5> |
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.
Greets,
Dawid