yocto.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: Martin Weber <martin.weber@br-automation.com>
To: "yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: Building recipes in multiple flavors for differing images
Date: Thu, 28 Apr 2022 09:09:33 +0000	[thread overview]
Message-ID: <VI1PR0602MB3549F83AC93A53785DE48677D3FD9@VI1PR0602MB3549.eurprd06.prod.outlook.com> (raw)

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

Hi everybody!

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. We were wondering whether it would be possible to use three images instead, and build the recipes in differing ways depending on the image. The "cleanest" way we could think of to do this would be to use recipe.inc files for the basic setup of each recipe, and recipe-X.bb, recipe-Y.bb, recipe-Z.bb that customize the build for the various use cases. This works fine for recipes that we control, but we stumble over customizing re-used recipes from lower layers that way. For example take dropbear; we might want to enable or disable it by default depending on the use case; and build with or without systemd integration. We can't find a clean way to extend the recipe in the upper layer with, say, dropbear-sysv.bb, dropbear-systemd-disabled.bb, dropbear-systemd-enabled.bb because then we don't extend the underlying dropbear.bb; if we require/include the underlying recipe, we have a different $PN and now the FILES(EXTRA)PATH won't resolve properly (and all $PN overrides in dropbear.inc don't apply). If we force the original $PN, now we're building the "same" package three times..

Once more, we do have a working solution for this (use different build directories and different distros) that enable re-use of the base recipes (we use .bbappends to customize lower-layer recipes with OVERRIDEs in that scenario) and were mostly wondering whether there's a /c?leaner/ approach with more (CPU-cycle, harddisk space and package DB) re-use.

Thanks in advance for any input & Best regards,

Martin Weber
Research & Development - Embedded Software Engineer

B&R Industrial Automation GmbH, B&R Straße 1, 5142 Eggelsberg, Austria, www.br-automation.com<http://www.br-automation.com/>
Phone +43 7748 6586 - 0

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

             reply	other threads:[~2022-04-28  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28  9:09 Martin Weber [this message]
2022-04-28  9:17 ` [yocto] Building recipes in multiple flavors for differing images Alexander Kanavin
2022-04-28 12:13 ` Stefano Babic
2022-04-28 13:33 ` Mike Crowe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR0602MB3549F83AC93A53785DE48677D3FD9@VI1PR0602MB3549.eurprd06.prod.outlook.com \
    --to=martin.weber@br-automation.com \
    --cc=yocto@lists.yoctoproject.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).