yocto.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: Josef Holzmayr <jester@theyoctojester.info>
To: Karthik Poduval <karthik.poduval@gmail.com>
Cc: tomzy <tomasz.zyjewski@3mdeb.com>, yocto@lists.yoctoproject.org
Subject: Re: [yocto] On managing debug and production builds
Date: Wed, 2 Mar 2022 07:50:16 +0100	[thread overview]
Message-ID: <CAEt6NwrHXX_-F2o2_HLm-Gd_EBoxmd5CYKqi=D+zMFEvHy0=OA@mail.gmail.com> (raw)
In-Reply-To: <CAFP0Ok9==XqQNWoZs2xcF-fUu6Tc1zT-zTDKyE4OXGAA63heKg@mail.gmail.com>

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

Howdy!

Karthik Poduval <karthik.poduval@gmail.com> 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 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 ?


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


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.

Greetz


> --
> 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.
> You automatically follow any topics you start or reply to.
> View/Reply Online (#56346):
> https://lists.yoctoproject.org/g/yocto/message/56346
> Mute This Topic: https://lists.yoctoproject.org/mt/89469781/4689568
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [
> jester@theyoctojester.info]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

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

  reply	other threads:[~2022-03-02  6:50 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       ` [yocto] " Karthik Poduval
2022-03-02  6:50         ` Josef Holzmayr [this message]
     [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='CAEt6NwrHXX_-F2o2_HLm-Gd_EBoxmd5CYKqi=D+zMFEvHy0=OA@mail.gmail.com' \
    --to=jester@theyoctojester.info \
    --cc=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).