Re: [bitbake-devel] [PATCH] toaster: Add recipe variables view

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

On Tue, 2026-08-18 at 14:33 -0400, Paolo Wattebled wrote:
> Hi Richard,
> 
> > For example if the core metadata has:
> > 
> > X = "${Y}"
> > Y = "Z"
> > 
> > then the recipe sets Y = "A", the variable history for X doesn't change
> > but the value does.
> 
> You are right. My filtering happened before expansion and relied on
> `VariableHistory`, which records direct operations but not changes caused by
> references to other variables. It could therefore omit `X`, even though its
> effective value had changed.
> 
> I removed this history-based filter. The implementation now iterates the
> parsed recipe datastore and stores the expanded value of each included
> variable. I added your example as a regression test, and the snapshot contains
> both `X = "A"` and `Y = "A"`.
> 
> Variables marked as functions and explicit override keys are not stored.
> Active overrides are represented under their logical variable names, and
> non-function flags are stored as `VAR[flag]` entries. Values detected as
> involving inline Python are also omitted to avoid expansion side effects.
> 
> On an `imx-image-core` build, Toaster persisted 598 recipe snapshots with an
> average of 1663 entries, a minimum of 1627 and a maximum of 1944. The compressed
> payload was about 86 MB in total, or 145 kB per recipe on average.
> 
> If you agree with the current scope and semantics, I will generate and send a
> v3 of the series.
> 
> Thanks for pointing this out.

My big concern is that this was the simple example of a problem with
these patches I could find and easily demonstrate. I've tried to hint
at the bigger architecture issues with them but that is a lot harder
for me to try and explain but I don't think you're seeing it.

It leaves me with a dilemma as I doubt the patches are right in their
current form but we're at an impasse over addressing the concerns
without me doing a lot more work.

Not really sure what to do from here.

Cheers,

Richard