Re: [bitbake-devel][PATCH V2] lib/bb/parse/ast.py: error out for internal fragment in case of a previous value

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2025-11-14 at 14:02 +0800, Qi.Chen@windriver.com wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
> 
> When an internal fragment is enabled, and there's already a value
> for the corresponding variable, we should error out to avoid any
> confusion.
> 
> For example, when 'machine/qemux86-64' fragement is enabled, and
> we get some "MACHINE = xxx" in local.conf or env, we should error
> out and recomment users to use 'bitbake-config-build disable-fragment'.
> 
> We should be tolerating weak assignments. For example, DISTRO defaults
> to "nodistro", and when 'distro/poky" fragment is enabled, there should
> be no confusion.
> 
> The implementation hacks the environment variable as a way to tell
> bitbake that we're using 'bitbake-config-build'. Because we recommend
> users to use bitbake-config-build, then it should not error out.
> 
> Fixes [YOCTO #16060]
> 
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  bin/bitbake-layers  | 3 +++
>  lib/bb/parse/ast.py | 7 +++++++
>  2 files changed, 10 insertions(+)

Thanks, I think this is a step in the right direction but I can see the
challenge you're facing with the parsing. There are probably other bugs
in this area, for example what if there is an invalid fragment set (you
delete a fragment file, then try to disable it with bitbake-build-
config?).

What might be a slightly "nicer" approach would be to pass the toolname
into the bitbake datastore as some variable (BB_TOOLNAME?) from
tinfoil, then we might want to skip all of the fragment code if
bitbake-config-build is in use?

We'd have to check what other implications that might have, for
example, does bitbake-build-config need a full datastore? What are the
implications for bitbake's cache files and cache file hashes?

Cheers,

Richard