Re: On managing debug and production builds

Josef Holzmayr


Karthik Poduval <karthik.poduval@...> schrieb am Mi. 2. März 2022 um 04:23:
This concept of user vs debug builds is there in Android and any
Android developer who gets introduced to yocto may look for these
options. There seem to be many implementation choices here, trying to
summarize some of the options here.

1. use different image recipes vs but this still poses a problem for kernel
recipes as kernel needs to have different config fragments or
different defconfig for debug vs user variants. One possible option is
to use KTYPE to select tiny vs standard or define own for custom BSP
layers. What about other recipes like u-boot or firmware for other
remote processors, how to percolate the debug vs user options to those
recipes via just an image recipe ?

As a recipe cannot affect another recipe, and image recipes are obviously recipes too, this is usually not useful.

2. use different configs using multiconfig. Base config (which is
debug) also selects the user config hence always building both build
variants in different tmp directories. Kernel, remote firmware and
image recipes use variables from the multiconfig cof files to decide
whether to build debug or user variants.

The whole point of multiconfig is builds depending on each other. I don’t think it applies here.

3. use different distros. DSITRO=user bitbake example-image,
DISTRO=debug example-image. Kernel and remote firmware recipes use
variables from the distro to decide whether to build debug or user

This is clearly the standard way.

Which is the best method ?
All these options seem very BSP layer specific, is there something
more generic and better than the above options ?
If not, should this be a feature request to the Yocto project ?

NOTE: debug variants may include the following.
- more debug related kernel configs and security loosened and UART
ports disabled
- image recipe debug variant may include debug utilities absent from
the user variant

Easily archived with 3.

There could be more than just debug and user variants. Android has
engineering, tests, user, tiny and user-debug.

See 3. You can have an arbitrary number of distros, interrelated however you wish.


Karthik Poduval

On Tue, Mar 1, 2022 at 1:26 AM tomzy <tomasz.zyjewski@...> wrote:
> Thanks Tomasz. I will check kas.
> No problem
> Yes, for selecting some of the packages I have created prod and debug image
> recipes.But this did not work for the kernel as the kernel recipe is picked
> as part of PROVIDERin machine conf.
> What are the difference there? You want to use different config on prod and debug images?
> Maybe add it as config fragments? Then you would need to add some global variable to
> distinguish when use given .cfg file.
> [1]
> SoI had to use 2 conf to have the
> IMAGE_FEATURES (orany other var)set differently for prod and debug. This is for
> building the kernelrecipie differently for prodand debug. Setting the
> IMAGE_FEATURES in the image recipe (and not inconf) causes2 problems. One is
> that kernel and other bootloaders recipes arepicked early via PROVIDER in conf
> and not as packages included in image recipe.
> Is that a problem?
> Secondly,setting the var in the
> image recipe breaks this command for e.g.
> "bitbake".
> Didn't you want to distinguish this to builds to be able to run `bitbake base-image-prod` or
> `bitbake base-image-debug`?
> Since the command parses the recipes only once for both image creation.
> Nevertheless I would greatly recommend you to use kas. In simple .yml file you
> could prepare different `local.conf` per configuration prod/debug.
> [2]
> Regards,
> Tomasz Żyjewski
> Embedded Systems Engineer
> | @3mdeb_com

Join to automatically receive all group messages.