Re: [yocto] Finer build time dependencies to optimize sysroot preparation time
Francesco Valla <[email protected]> Sat, 7 Mar 2026 17:50:31 +0100
| Newsgroups | org.yoctoproject.lists.yocto |
|---|---|
| Message-ID | <aaxQ9lsb9v0LDnAV@bywater> |
Hello Jocelyn,
On Fri, Mar 06, 2026 at 03:17:24AM -0800, Jocelyn Meyron via lists.yoctoproject.org wrote:
> Hello everyone,
>
> I'm trying to solve the following problem (I'm using the latest scarthgap release):
> - I have a recipe A whose job is to aggregate libraries produced by multiple recipes (basically aggregate a bunch of static libraries into a shared one to reduce the file system size).
> - Right now, I added the list of recipes into the "DEPENDS" variable of recipe A. This works but this implies that all the files installed by the other recipes are copied into the sysroot of recipe A. The issue is that the other recipes package also header filers, source files, and other libraries, leading to slow downs in the build process (especially when ran under a static analysis tool).
>
> I could have packaged the relevant files of the recipes into dedicated subpackages but the main recipe A can't depend on those packages (since only recipes can be used for build time dependencies).
>
> Does someone have a proposal to work around this issue? Or maybe I need to redesign this "aggregation" recipe?
The sanest solution would probably be to reconsider some of the design
choices, e.g.:
- design the "multiple recipes" to produce only the relevant files
(e.g.: why are there source files installed in the sysroot of recipe
A?)
- tune the static analyzer to exclude some components, rather than
considering the whole sysroot
This considered, as a workaround you can remove unwanted components from
the sysroot of recipe A *after* this has been created, for example
through a postfunc:
remove_unwanted_components () {
# remove X, Y and Z
rm ${RECIPE_SYSROOT}${datadir}/my-unwanted-data
}
do_prepare_recipe_sysroot[postfuncs] += " remove_unwanted_components"
This is obviously absolutely non portable and does not scale well, but
should be functional.
>
> Thank you in advance.
Regards,
Francesco