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 <[email protected]> wrote: > On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr > <[email protected]> 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 > > > <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 > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54027): https://lists.yoctoproject.org/g/yocto/message/54027 Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
