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

Paolo Wattebled <[email protected]>
Newsgroups org.openembedded.lists.bitbake-devel
Message-ID <1319358081.1239871.1787166966997.JavaMail.zimbra@savoirfairelinux.com>
Hi Richard,

Thank you for the feedback, and sorry—the previous approach was too intrusive
in BitBake’s parsing and cache machinery.

I have reworked it so that no recipe-variable data is added to BitBake’s parse
cache or dependency events. Toaster now records the recipe files selected for
the runqueue and, after the build completes, acts as a client of the BitBake
server. It calls a new read-only command for each recipe, which uses BitBake’s
normal parser to create a temporary recipe datastore and returns the resolved
variables to Toaster. Toaster then compresses and stores the result in its own
database.

The history-based selection has also been removed, so indirect changes such as
X = "${Y}" are represented correctly. Functions and values requiring inline
Python expansion are currently omitted to avoid execution side effects, so the
result is a safely expanded subset rather than a byte-for-byte equivalent of
bitbake -e.

This approach does require reparsing the runqueue recipes after the build. In a
preliminary cached imx-image-core test, it added approximately 42 seconds
compared with unmodified Toaster. I am continuing to evaluate that cost.

I hope this provides a better compromise by keeping the data out of BitBake’s
normal cache and build flow while allowing Toaster to query BitBake through a
defined API. I do not currently see a less intrusive way for Toaster to obtain
build-specific recipe values.

If the general approach seems viable to you, I can send the incremental changes
for review.

Thank you again for your feedback.

Have a great day,  
Paolo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.