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.
Greetz
Thanks in advance,
Jonas
[1]: https://stackoverflow.com/questions/68167244/image-specific-layers
<https://stackoverflow.com/questions/68167244/image-specific-layers>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54003): https://lists.yoctoproject.org/g/yocto/message/54003
Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
