Finer build time dependencies to optimize sysroot preparation time

Finer build time dependencies to optimize sysroot preparation time

[Jocelyn Meyron]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

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?

Thank you in advance.

[-- Attachment #2: Type: text/html, Size: 1171 bytes --]

Re: [yocto] Finer build time dependencies to optimize sysroot preparation time

[Francesco Valla]

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

Re: [yocto] Finer build time dependencies to optimize sysroot preparation time

[Alexander Kanavin]

On Sat, 7 Mar 2026 at 17:50, Francesco Valla via
lists.yoctoproject.org <francesco=valla.it@lists.yoctoproject.org>
wrote:
> 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.

There are standard variables that can be used per-recipe to control
what gets installed into a sysroot, so they can be set to install less
than default (or more):
SYSROOT_DIRS
SYSROOT_DIRS_NATIVE
SYSROOT_DIRS_IGNORE

There's plenty of examples in oe-core of how to use them. Defaults are
defined in meta/classes-global/staging.bbclass.

Alex