Re: On managing debug and production builds

Karthik Poduval

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 ?
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.
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

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

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

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.


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.

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.


Tomasz ┼╗yjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59 | @3mdeb_com

Join { to automatically receive all group messages.