Re: [bitbake-devel] [PATCH] toaster: Add recipe variables view
Richard Purdie <[email protected]>
| Newsgroups | org.openembedded.lists.bitbake-devel |
|---|---|
| Message-ID | <58e087a5908a808a3557f92d3844f79b1cce61cd.camel@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