public inbox for docs@lists.yoctoproject.org
 help / color / mirror / Atom feed
From: Dawid Bijak <bijak.dawid@gmail.com>
To: bitbake-devel@lists.openembedded.org
Cc: docs@lists.yoctoproject.org, Dawid Bijak <bijak.dawid@gmail.com>
Subject: [PATCH 1/1] doc: bitbake-user-manual-metadata: fix inherit_defer documentation
Date: Fri, 24 Apr 2026 08:23:27 +0200	[thread overview]
Message-ID: <20260424062327.820993-2-bijak.dawid@gmail.com> (raw)
In-Reply-To: <20260424062327.820993-1-bijak.dawid@gmail.com>

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

Also add an anti-example showing that the previously documented
pattern of setting the inherited class name from an anonymous
Python function does not work with inherit_defer.

Signed-off-by: Dawid Bijak <bijak.dawid@gmail.com>
---
 .../bitbake-user-manual-metadata.rst          | 61 ++++++++++---------
 1 file changed, 32 insertions(+), 29 deletions(-)

diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
index 40cae6b05..38efe6b11 100644
--- a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
+++ b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
@@ -803,7 +803,17 @@ An advantage with the inherit directive as compared to both the
 :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` and :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
 directives is that you can inherit class files conditionally. You can
 accomplish this by using a variable expression after the ``inherit``
-statement.
+statement, as in::
+
+   inherit ${@'classname' if condition else ''}
+
+Or::
+
+   inherit ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)}
+
+In both cases, if the expression evaluates to an
+empty string, the statement does not trigger a syntax error because it
+becomes a no-op.
 
 For inheriting classes conditionally, using the :ref:`inherit_defer
 <ref-bitbake-user-manual-metadata-inherit-defer>` directive is advised as
@@ -827,39 +837,32 @@ the variable after the line is parsed will take effect. With the :ref:`inherit
 
 Here is an example::
 
-   inherit_defer ${VARNAME}
-
-If ``VARNAME`` is
-going to be set, it needs to be set before the ``inherit_defer`` statement is
-parsed. One way to achieve a conditional inherit in this case is to use
-overrides::
-
    VARIABLE = ""
-   VARIABLE:someoverride = "myclass"
-
-Another method is by using :ref:`anonymous Python
-<bitbake-user-manual/bitbake-user-manual-metadata:Anonymous Python Functions>`.
-Here is an example::
+   inherit_defer ${VARIABLE}
+   VARIABLE:someoverride = "someclass"
+
+:ref:`inherit_defer <ref-bitbake-user-manual-metadata-inherit-defer>`
+defers the evaluation of ``${VARIABLE}`` until the end of
+parsing. Assuming ``someoverride`` is in :term:`OVERRIDES`, ``${VARIABLE}``
+expands to ``someclass``, which is then inherited. Contrast this with a plain
+:ref:`inherit <ref-bitbake-user-manual-metadata-inherit>`, which would evaluate
+``${VARIABLE}`` immediately, before the ``VARIABLE:someoverride`` assignment
+is parsed. ``${VARIABLE}`` would expand to an empty string and the statement
+would become a no-op.
+
+Note that assigning the variable from an
+:ref:`anonymous Python function <bitbake-user-manual/bitbake-user-manual-metadata:Anonymous Python Functions>`
+does *not* work, because deferred inherits are resolved before anonymous
+Python functions run::
 
    python () {
-       if condition == value:
-           d.setVar('VARIABLE', 'myclass')
-       else:
-           d.setVar('VARIABLE', '')
+       if d.getVar('SOMETHING') == 'value':
+           d.setVar('VARIABLE', 'someotherclass')
    }
 
-Alternatively, you could use an inline Python expression in the
-following form::
-
-   inherit_defer ${@'classname' if condition else ''}
-
-Or::
-
-   inherit_defer ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)}
-
-In all cases, if the expression evaluates to an
-empty string, the statement does not trigger a syntax error because it
-becomes a no-op.
+The conditional assignment of ``someotherclass`` has no effect on the
+``inherit_defer`` statement, which has already been resolved by the time
+the anonymous Python function runs.
 
 See also :term:`BB_DEFER_BBCLASSES` for automatically promoting classes
 ``inherit`` calls to ``inherit_defer``.
-- 
2.48.1



  reply	other threads:[~2026-04-24  6:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-24  6:23 [PATCH 0/1] doc: bitbake-user-manual-metadata: clarify inherit_defer documentation Dawid Bijak
2026-04-24  6:23 ` Dawid Bijak [this message]
2026-04-27 12:35   ` [docs] [PATCH 1/1] doc: bitbake-user-manual-metadata: fix " Quentin Schulz
2026-04-27 12:47     ` Quentin Schulz
2026-04-27 18:14     ` Dawid Bijak
2026-04-28 20:42       ` [bitbake-devel] " Richard Purdie
2026-04-29 14:11         ` Dawid Bijak
2026-04-29 14:24           ` Quentin Schulz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260424062327.820993-2-bijak.dawid@gmail.com \
    --to=bijak.dawid@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=docs@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox