yocto.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: Karthik Poduval <karthik.poduval@gmail.com>
To: tomzy <tomasz.zyjewski@3mdeb.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] On managing debug and production builds
Date: Tue, 1 Mar 2022 19:22:59 -0800	[thread overview]
Message-ID: <CAFP0Ok9==XqQNWoZs2xcF-fUu6Tc1zT-zTDKyE4OXGAA63heKg@mail.gmail.com> (raw)
In-Reply-To: <19024.1646126763231751613@lists.yoctoproject.org>

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 example-image-user.bb vs
example-image-debug.bb 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
variants.

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.

--
Regards,
Karthik Poduval

On Tue, Mar 1, 2022 at 1:26 AM tomzy <tomasz.zyjewski@3mdeb.com> 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] https://docs.yoctoproject.org/singleindex.html#creating-configuration-fragments
>
> 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 base-image-prod.bbbase-image-debug.bb".
>
> 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] https://kas.readthedocs.io/en/latest/userguide.html#project-configuration
>
> Regards,
> Tomasz Żyjewski
> Embedded Systems Engineer
> GPG: 5C495EA3EBEECA59
> https://3mdeb.com | @3mdeb_com
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#56335): https://lists.yoctoproject.org/g/yocto/message/56335
> Mute This Topic: https://lists.yoctoproject.org/mt/89469781/3618339
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [karthik.poduval@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


  reply	other threads:[~2022-03-02  3:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01  5:06 On managing debug and production builds Vinayak Menon
2022-03-01  7:04 ` tomzy
2022-03-01  8:52   ` [yocto] " Vinayak Menon
2022-03-01  8:58     ` Alexander Kanavin
2022-03-01  9:26     ` tomzy
2022-03-02  3:22       ` Karthik Poduval [this message]
2022-03-02  6:50         ` [yocto] " Josef Holzmayr
     [not found]       ` <CAH9dsRgmBt-Y-P0P+1o1u6RC2WqFXH03nURMnaDpZJjNH_nE0Q@mail.gmail.com>
2022-03-02  6:29         ` Vinayak Menon

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAFP0Ok9==XqQNWoZs2xcF-fUu6Tc1zT-zTDKyE4OXGAA63heKg@mail.gmail.com' \
    --to=karthik.poduval@gmail.com \
    --cc=tomasz.zyjewski@3mdeb.com \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).