Re: Building recipes in multiple flavors for differing images

Richard Purdie

On Thu, 2022-04-28 at 09:09 +0000, Martin Weber wrote:
We use yocto to build the system for some of our devices. Given we have
multiple use-cases for differing partitions on the device (rescue system; main
system in “release” flavor; main system in “development & debug” flavor), we
use different custom distros for our build.
With this mail we would like to ask the community what the best practice for
our use case are, describe our current approach, and ask whether we can do
things in a better way.
The software we use (machine/bsp layer level; software level) in principal is
the same (same upstream, internal or 3rd party), but we need to build them in
different ways (e.g., one uses system V init, one uses systemd init; one uses
optimized-non-logging versions of the software, another ships debug symbols
and enables logging during buildtime; one installs and enables various systemd
units, another doesn’t, etc.).
Our solution to this problem is that we have (three) different distros, and
use distro overrides to enable/disable/patch/append/delete various bits and
pieces throughout the otherwise shared recipes. The “problem” with this is
that we need to use different build environments to build our three distros,
i.e., we cannot re-use otherwise identical packages.
If you share sstate between these three builds, bitbake knows whether they
really are the same or not and will reuse as appropriate.

The challenge is that when you change something like init manager, it changes
glibc. If glibc changes, most of the system is then rebuilt.

I suspect you don't realise the extend of your changes and if you share sstate,
the system should be reusing much of the shared pieces.

We were wondering whether it would be possible to use three images instead,
and build the recipes in differing ways depending on the image.
You're effectively trying to reinvent sstate there and I think you'll find there
are more differences than you first realise.

You may be better off trying to more closely align the pieces of your three
builds so sstate is reused efficiently, it is designed to make that work flow
fast where it can. As an example, try building three similar but different
images (say one added recipe differently to each) in three different build
directories with sstate shared between the two. I believe that will be very



Join to automatically receive all group messages.