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

On Thu, 2026-08-13 at 11:31 -0400, Paolo Wattebled wrote:
> Thanks for raising this. I ran a quick comparison with and without the change.
> Toaster startup and recipe parsing were effectively unchanged (2m46.554s vs
> 2m46.835s). A cached imx-image-core build took 4m23.648s versus 4m07.387s,
> about 16 seconds slower. After vacuuming, both SQLite databases rounded to 74
> MiB, including 598 per-recipe variable snapshots. I understand that some of
> this data is stored twice. However, I only store variables changed by recipes
> or bbappends, and I compress them before saving them. In my test, this did not
> noticeably increase the database size.

This does raise a few more questions. I don't think you're covering all
the cases where variables change in recipes as *every* recipe will have
recipe specific values and 598 seems like a low number.

You appear to be only considering where overrides are used but
overrides aren't the only way variables can be changed as =+ and so on
are possible, or the value can just be overwritten.

I don't mind toaster reading out and storing the data but you may as
well just read the data, there is little point in changing the cache
structures to add/cache it?

It does also raise questions about whether you want the variable
history information too? (or will in future?)

> Our intended use of Toaster is as the backend for an MCP server for AI agents.
> Rather than having agents repeatedly parse and search recipe files or invoke
> bitbake-getvar, the server would expose resolved, build-specific metadata
> through a stable API. The MCP layer is still under development, but per-recipe
> variable values are one of its planned endpoints. We chose Toaster because it
> already models builds, recipes, packages and variables; extending it avoids
> creating a separate metadata store. It will run headlessly in this use case,
> with the MCP server translating between Toaster’s API and the agent.

Thanks for the info, that does sound like an interesting use case for
it. It is reasons like this I've pushed back against deleting toaster!
Knowing a bit about your plans here does help me keep fighting to keep
that code!

I'd also note that your original patch is quite large and really should
make more increamental separte changes given the breadth of what it is
doing.

Cheers,

Richard