All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frederic Martinsons" <frederic.martinsons@gmail.com>
To: Jonas Vautherin <jonas.vautherin@gmail.com>
Cc: Yocto-mailing-list <yocto@lists.yoctoproject.org>
Subject: Re: [yocto] Would COMPATIBLE_IMAGE make sense?
Date: Tue, 29 Jun 2021 07:26:57 +0200	[thread overview]
Message-ID: <CA+cAkeoqEV_u0SKVX+QYLZdwmXthOg_kJsYRGUOVAXY+e=jZZA@mail.gmail.com> (raw)
In-Reply-To: <CAEyb4nEiwzVnrqHGob-ioo0iwT+NNA_uCXFMejoYfAdnnQpH5A@mail.gmail.com>

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

Hello, instead of creating a new variable (don't sure of its possible
usefulness), you can use BBMASK or review dependencies between your layer

PS: I did a similar answer on your stackoverflow question.

On Tue, 29 Jun 2021 at 01:29, Jonas Vautherin <jonas.vautherin@gmail.com>
wrote:

> I was thinking about my issue described here [1], and discovered the
> variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use
> to stop recipes from being built for machines (/hosts) with which the
> recipes are not compatible". And so I wondered if it would make sense to
> add COMPATIBLE_IMAGE, for a similar purpose.
>
> Let me explain my issue: I define different images in different layers
> (say `first-project-image` and `second-project-image`), and in each of
> those layers I create `.bbappends` to configure some packages. Typically
> `hostapd` is used by both images, but with a different config file.
>
> The thing is that when I run `bitbake first-project-image`, because
> `second-project-image` is part of my bblayers.conf, then the
> hostapd_%.bbappend from `second-project-image` is used and may have an
> impact on `first-project-image`, which I don't want. I really want this
> bbappend to only affect the image `second-project-image`.
>
> One way I can see to deal with that is to realize that
> `first-project-image` and `second-project-image` are two different
> projects, and build them from two different BUILDDIRs. The thing I don't
> like here is that all the packages are therefore downloaded and built
> twice, which seems like a loss of time and space.
>
> That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
> of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> 'second-project-image'". So that I could still share a BUILDDIR between
> different projects.
>
> How bad of an idea is that?
>
> Thanks in advance,
> Jonas
>
> [1]: https://stackoverflow.com/questions/68167244/image-specific-layers
>
> 
>
>

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

  reply	other threads:[~2021-06-29  5:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 23:28 Would COMPATIBLE_IMAGE make sense? Jonas Vautherin
2021-06-29  5:26 ` Frederic Martinsons [this message]
2021-06-29  6:41 ` [yocto] " Josef Holzmayr
2021-06-29 11:44   ` Erik Boto
2021-06-29 11:52   ` Bruce Ashfield
2021-06-30 22:42     ` Jonas Vautherin

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='CA+cAkeoqEV_u0SKVX+QYLZdwmXthOg_kJsYRGUOVAXY+e=jZZA@mail.gmail.com' \
    --to=frederic.martinsons@gmail.com \
    --cc=jonas.vautherin@gmail.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 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.