On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
I was thinking about my issue described here , and discovered theYocto chant #1 applies: "Recipe data is local, configuration data is
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
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.
Thanks in advance,
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II