Re: [yocto] Building recipes in multiple flavors for differing images

[Mike Crowe <mac@mcrowe.com>]

On Thursday 28 April 2022 at 09:09:33 +0000, Martin Weber wrote:
> 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.).

We do switching between debug/release (and in the past one other similar
configuration option) by changing PACKAGE_ARCH. We set OUR_DEBUG in the
build environment, then have:

 DISTROOVERRIDES = "${DISTRO}:${@['ourdebug0', 'ourdebug1'][d.getVar('OUR_DEBUG') == '1']}"
 OUR_DEBUG_SUFFIX = "${@oe.utils.conditional('OUR_DEBUG', '1', '-debug', '', d)}"
 MACHINE_ARCH_DEBUG = "${MACHINE_ARCH}${OUR_DEBUG_SUFFIX}"
 PACKAGE_EXTRA_ARCHS_append_ourdebug1 = " ${MACHINE_ARCH_DEBUG}"

and then in any recipes that behave differently between debug and release
we have something like:

 PACKAGE_ARCH = "${MACHINE_ARCH_DEBUG}"
 RECIPE_SPECIFIC_VARIABLE_ourdebug1 = "-DENABLE_DEBUG_STUFF"
 RECIPE_SPECIFIC_VARIABLE_ourdebug0 = "-DNDEBUG"

(You may find that you need to create a parallel set of infrastructure
using an equivalent TUNE_PKGARCH_DEBUG too if you have non-MACHINE-specific
packages that conditionally enable debug.)

This mostly works, and it works a lot better now than it did when we first
started doing it about a decade ago. I still think there's a risk of
getting the non-debug package in a "debug" rootfs if things go a bit wrong,
but this isn't something we've seen for a long time. If it comes back then
I'd try using a "-nodebug" alternative in OUR_DEBUG_SUFFIX too in order to
avoid that possibility. (That way, a package would either have a
PACKAGE_ARCH that matched ${MACHINE_ARCH} or ${MACHINE_ARCH_DEBUG}, but
not both.)

This method was originally created by Phil Blundell. I don't necessarily
recommend doing it, but it does seem to have worked for us. We started with
something simpler, and when we ran into problems I ended up learning a lot
more about how Bitbake worked in order to solve them which was beneficial
in the long run. :)

In theory it ought to be possible to use multiconfig to build both debug
and non-debug variants at the same time, but this isn't something we've
tried.

HTH.

Mike.