All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre McCurdy <armccurdy@gmail.com>
To: "Joao Carlos Cabral (P)" <Joao.CCabral@parceiros.nos.pt>
Cc: "bitbake-devel@lists.openembedded.org"
	<bitbake-devel@lists.openembedded.org>
Subject: Re: [HELP] Create a new image recipe based on a (changed) existing one
Date: Fri, 14 Feb 2020 15:33:04 -0800	[thread overview]
Message-ID: <CAJ86T=WszRq0ff8uqn+afu5Eag8UNNxLL_=5LXRWUw3y5pyFTA@mail.gmail.com> (raw)
In-Reply-To: <3cb24a9342e09cea61c0bde03c26d165588faf96.camel@parceiros.nos.pt>

On Thu, Feb 13, 2020 at 9:34 AM Joao Carlos Cabral (P)
<Joao.CCabral@parceiros.nos.pt> wrote:
>
> Thanks for your answer.
>
> Using your method, how could I create the normal image and the dev one?
>
> * bitbake product - would produce the normal one?
> * bitbake my-image - would produce the dev one?
>
> I still need to create the "normal" when ending a develop phase.

Assuming that you can't change layers 1 or 2 then the ONLY thing you
can build which will include both the my-image recipe in layer 1 and
its .bbappend in layer 2 is the my-image recipe itself. If the
development image is created by adding to the contents of my-image by
using a .bbappend in layer 3 then to switch back to the normal image
you would need to disable that .bbappend. e.g. If you have a .bbappend
which adds to a package group under the control of a variable then you
could switch between production and development by setting that
variable from a global config file (e.g. local.conf) and rebuilding
my-image.

A different approach which _would_ allow you to switch between
production and development by building a different image would be to
duplicate the .bbappend from layer 2 in your layer 3. In layer 3 you
could then have a new image recipe which directly includes the layer 1
recipe (ie what you tried originally) plus a new .bbappend which makes
the same changes to your new image recipe as the .bbappend in layer 2
makes to the layer 1 image recipe. If the contents of the .bbappend
don't need to be changed then you could perhaps make the layer 3
.bbappend a symlink pointing back to the layer 2 .bbappend, rather
than just copying and renaming the whole file.


      reply	other threads:[~2020-02-14 23:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-09 23:17 [HELP] Create a new image recipe based on a (changed) existing one Joao Carlos Cabral (P)
2020-02-09 23:26 ` Joao Carlos Cabral (P)
2020-02-10 21:12   ` Andre McCurdy
2020-02-13 17:34     ` Joao Carlos Cabral (P)
2020-02-14 23:33       ` Andre McCurdy [this message]

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='CAJ86T=WszRq0ff8uqn+afu5Eag8UNNxLL_=5LXRWUw3y5pyFTA@mail.gmail.com' \
    --to=armccurdy@gmail.com \
    --cc=Joao.CCabral@parceiros.nos.pt \
    --cc=bitbake-devel@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.