| Message ID | 20260501091418.76994-5-bijak.dawid@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | doc: bitbake-user-manual-metadata: clarify inherit_defer documentation | expand |
Hi Dawid, On 5/1/26 11:14 AM, Dawid Bijak wrote: > The two inline Python examples, > > inherit_defer ${@'classname' if condition else ''} > inherit_defer ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)} > > are presented as inherit_defer-specific techniques, but they work > with plain inherit too. Their placement under > inherit_defer suggests deferred evaluation is required, which is > not the case: the ${@...} expression is evaluated when the > inherit line is parsed in both forms. > > Move the inline Python expression examples from the inherit_defer section > up to the inherit section, since they apply to both directives. > As said in V1 and in this form: NACK. What's the raison d'être of inherit_defer if inherit "works just as well"? To quote Richard in v1: """ 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. """ The commit introducing inherit_defer in BitBake is also pretty explicit why it was added, see 5c2e840eafeb ("ast/BBHandler: Add inherit_defer support"). So it may appear to work for you in your specific usecase, but it doesn't always. We are very careful to not add unnecessary complexity, be it operators or directives so I trust Richard to not have merged something that does nothing that isn't already supported by another directive or operator. Yes, inherit_defer is useful for the native class which we always want to be last, but it's not why this directive was added in the first place, it's only piggy-backing there. So, as said in v1, we are not using footguns as examples. We can however say that something may appear to work but is a footgun, as suggested in v1 where I said "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.". Cheers, Quentin
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst index 0c7c3ff99..4b1aeedc1 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 @@ -840,19 +850,6 @@ defers the evaluation of ``${VARNAME}`` until the end of parsing. Assuming ``someoverride`` is in :term:`OVERRIDES`, ``${VARNAME}`` expands to ``myclass``, which is then inherited. -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. - See also :term:`BB_DEFER_BBCLASSES` for automatically promoting classes ``inherit`` calls to ``inherit_defer``.
The two inline Python examples, inherit_defer ${@'classname' if condition else ''} inherit_defer ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)} are presented as inherit_defer-specific techniques, but they work with plain inherit too. Their placement under inherit_defer suggests deferred evaluation is required, which is not the case: the ${@...} expression is evaluated when the inherit line is parsed in both forms. Move the inline Python expression examples from the inherit_defer section up to the inherit section, since they apply to both directives. Signed-off-by: Dawid Bijak <bijak.dawid@gmail.com> --- .../bitbake-user-manual-metadata.rst | 25 ++++++++----------- 1 file changed, 11 insertions(+), 14 deletions(-)