From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by mx.groups.io with SMTP id smtpd.web09.4252.1625092966379571378 for ; Wed, 30 Jun 2021 15:42:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NyZ0FJjU; spf=pass (domain: gmail.com, ip: 209.85.222.170, mailfrom: jonas.vautherin@gmail.com) Received: by mail-qk1-f170.google.com with SMTP id v139so4172843qkb.9 for ; Wed, 30 Jun 2021 15:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HKPG3K5P8iCwF9gWUfsDPZrCgSVVIwpOo7iWDCXMRxE=; b=NyZ0FJjU6EHWstNUj/4HeC66YiSKgTYgl04jF8JHAQYLtX6zIz+p5MNDi2tprA3Rj5 ISXeXWbKChMjs9Ht9F1b0f38v4+nXFiiZf2zEv6z3BAVop7X0sCgtew2Xp79b8pA05xE O4+9EuyUzLoLQ38DO1h+pqrWmtpTFzwz4gFYgCWfYWqe4ipNoXhP9tm5s348doGxZ933 7x4vTAkTu+yaM6XgXI5pw6z/rbSfpZi6pF2s/5arDUT0xb8/9SsGAnGgnFifI8Ts8Kd5 NtYJtsvuHzQ2SrW7Oxmh0rcotlN2WRgKdCIG1ChUDrQ0tOqpdxAcYAlgMmsS+W12K4tM Gkdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HKPG3K5P8iCwF9gWUfsDPZrCgSVVIwpOo7iWDCXMRxE=; b=XJzZxn5g8YoziWSpPNf3CSndG4KCDBoV1Gtqf2PQ/STe1z7DrIO12ZZ5RZDhG9Z7qD 5JJP9h/7nW29vN92y0rnMrInP3Kyki7uQmFXvs5EHyjTcr27H886xdr8UlRGCC/SZ2qQ E+QNDlaVb24dfKu0a66kS6IHfdnIuBwZB5S2zqWFhFCD3JdcJS0Tvc2dkykvjF8saijR s7AGUf5B4ISv9sFT/wRuMj8ZfViL+sLC4k9QpbxBI5U730l3FgXtk+pjOY6FsLC1nlPR H/jkuoAmzYOYaS1SlLjTyGK8N1TYBSWgsOvpm1EnbJVcR4OuRYT07V5y6Ohca0LP9jsN OdJw== X-Gm-Message-State: AOAM533w/vi3ZsgZjf51+uq7tAAeQxeJI54WCD/L2LEWjwA6IzvE5e0g vFCvXEdmGAHHVlEIlDH46F619XiCATo2zWmCLUE= X-Google-Smtp-Source: ABdhPJwGxFhzMv3Is5JnhA3fp4xWhO7y6cEY5qnV2xhJyAkRFJS0T2ZXIGtu4uxbrJUey/3Hafx3jnjSQBO3aGufdJk= X-Received: by 2002:a37:6cd:: with SMTP id 196mr30695757qkg.5.1625092965601; Wed, 30 Jun 2021 15:42:45 -0700 (PDT) MIME-Version: 1.0 References: <68074a59-650c-c02a-b05b-855b43171c50@theyoctojester.info> In-Reply-To: From: "Jonas Vautherin" Date: Thu, 1 Jul 2021 00:42:34 +0200 Message-ID: Subject: Re: [yocto] Would COMPATIBLE_IMAGE make sense? To: Bruce Ashfield Cc: Josef Holzmayr , yocto Content-Type: multipart/alternative; boundary="000000000000f115f205c60370cf" --000000000000f115f205c60370cf Content-Type: text/plain; charset="UTF-8" Thanks a lot for the answers, that's really helpful! Seems like I should have a closer look at the distros. I'll need some time to test it, I'll update here when that is done! On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfield wrote: > On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr > wrote: > > > > Howdy! > > > > Am 29.06.2021 um 01:28 schrieb Jonas Vautherin: > > > 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. > > > > Yocto chant #1 applies: "Recipe data is local, configuration data is > > global." Means: the recipe does not see at all which image it is being > > built for. So it also can't react to it - you can't check a variable > > against something you do not even see. > > > > > How bad of an idea is that? > > > > It just doesn't work. If that counts as "bad" is left for you to decide > :) > > > > What you actually might use is using different DISTROs for the images, > > because that actually what they mean to do: you change the ABI/API of > > the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO > > derivatives, so its all there already. It just cannot be triggered from > > the image, because, well.. see first pragraph of the answer. > > I was also going to suggest distros. > > And also, if the concern really is about builds reusing downloads, > etc, then by all means configure those different distro builds to > share download and sstate directories. > > Bruce > > > > > Greetz > > > > > Thanks in advance, > > > Jonas > > > > > > [1]: > https://stackoverflow.com/questions/68167244/image-specific-layers > > > > > > > > > > > > > > > > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > > --000000000000f115f205c60370cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for the answers, that's really helpf= ul!

Seems like I should have a closer look at= the distros.
I'll need some time to test it, I'll update= here when that is done!

On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfie= ld <bruce.ashfield@gmail.com= > wrote:
= On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
<jester= @theyoctojester.info> wrote:
>
> Howdy!
>
> Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > I was thinking about my issue described here [1], and discovered= the
> > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which &= quot;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 wo= uld 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 e= ach of
> > those layers I create `.bbappends` to configure some packages. T= ypically
> > `hostapd` is used by both images, but with a different config fi= le.
> >
> > The thing is that when I run `bitbake first-project-image`, beca= use
> > `second-project-image` is part of my bblayers.conf, then the
> > hostapd_%.bbappend from `second-project-image` is used and may h= ave an
> > impact on `first-project-image`, which I don't want. I reall= y 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 differe= nt
> > 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 hostap= d_%.bbappend
> > of `first-project-image`, I would set "COMPATIBLE_IMAGE =3D=
> > 'first-project-image'", and similarly for "COM= PATIBLE_IMAGE =3D
> > 'second-project-image'". So that I could still shar= e a BUILDDIR between
> > different projects.
>
> Yocto chant #1 applies: "Recipe data is local, configuration dat= a is
> global." Means: the recipe does not see at all which image it is= being
> built for. So it also can't react to it - you can't check a v= ariable
> against something you do not even see.
>
> > How bad of an idea is that?
>
> It just doesn't work. If that counts as "bad" is left f= or you to decide :)
>
> What you actually might use is using different DISTROs for the images= ,
> because that actually what they mean to do: you change the ABI/API of=
> the image. And you can also define a base DISTRO and COMPATIBLE_DISTR= O
> derivatives, so its all there already. It just cannot be triggered fr= om
> the image, because, well.. see first pragraph of the answer.

I was also going to suggest distros.

And also, if the concern really is about builds reusing downloads,
etc, then by all means configure those different distro builds to
share download and sstate directories.

Bruce

>
> Greetz
>
> > Thanks in advance,
> > Jonas
> >
> > [1]: https://stackoverf= low.com/questions/68167244/image-specific-layers
> > <https://stackoverfl= ow.com/questions/68167244/image-specific-layers>
> >
> >
> >
> >
>
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



--000000000000f115f205c60370cf--