> -----Original Message----- > From: Richard Purdie <[email protected]> > Sent: den 17 mars 2026 09:22 > To: Peter Kjellerstedt <[email protected]>; > [email protected] > Subject: Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package > architectures into layer.conf settings > > On Mon, 2026-03-16 at 13:03 +0000, Peter Kjellerstedt wrote: > > > > Wouldn't it be more appropriate to use += for these two? > > > > Otherwise one will have to use :append to add to them in other > > > > layers. > > > > > > That depends on whether your layer is included after core or not. > > > I'd have thought including before core would be potentially > > > problematic anyway... > > > > Sure, but with += the order does not matter. > > > > We have "meta" as the last layer in BBLAYERS in our setup. E.g., > > these are the external layers I have in one of our configurations: > > > > BBLAYERS ?= " \ > > ... > > .../meta-virtualization \ > > .../meta-webserver \ > > .../meta-multimedia \ > > .../meta-filesystems \ > > .../meta-networking \ > > .../meta-python \ > > .../meta-oe \ > > .../meta-poky \ > > .../meta \ > > " > > > > We have them configured like this to as best as possible match the > > layer priorities. It is not perfect (e.g., meta-poky prepends to > > BBPATH instead of appending like all the other layers do), but it > > has resulted in the least surprises regarding things that are based > > on BBPATH and things that are based on layer priorities. > > We need to rewrite how this all works and remove some of the options as > it is all too complex and everyone is putting it together differently > and hoping for the best :(. > > Trying to "support" the number of possible combinations that people > might put things together is problematic. The ask is that everything > works regardless of how you configure it and nobody even > understands/agrees on the basic rules.
I think one of the biggest problems here actually is the freedom provided by the current solution for how layers are added and configured, and I believe we actually want to make it much more rigid. Which of course will make people scream (possibly including myself). > If you don't understand my concern, think about how you'd recreate that > setup just starting from core and using bitbake-layers add-layer. I > don't think you can. Well, actually, I do have some experience in the area. While we do not use bitbake-layers add-layer, but rather use the layers as specified in our repo manifests, this still means we have a different set of layers for each manifest that needs to be put into the correct order in BBLAYERS. In a perfect world, this would be done by taking layer priorities and layer dependencies into consideration. However, we have cheated in our current solution, so instead we have a static list for the order of known layers, and any unknown layers go on top (in our case these are typically project layers that depend on the known layers anyway). > > It is too late to do anything about it right now and I've put off > trying to improve things as I know the shear amount of complaints I'll > get but there is a problem here. I expect you to have given this a lot more thought over the years than I have, so please take my naïve ideas below for what they are. > > Cheers, > > Richard I would love to see an addlayer command (or something similar) that would hide all the gory details of layer priorities, dependencies, and making sure it is consistent when applying bbappends and the order .conf files are read, etc, and avoids problems with different layers having their own ideas about how to do things. Unfortunately, I do realize this is an enormous job, and getting all the details right will probably be near impossible, especially as everyone undoubtedly have their own ideas about how layer configuration should be done (I know I do). And, unfortunately, I also have a pretty good idea of who would have to do most work to make anything like this happen. (I have a feeling I'm not selling this idea very well... ☹) Another thing I would like to see is that the order in BBLAYERS does not matter. Instead, the layer dependencies should determine the order, pretty much like how the task dependencies decide the order the tasks are executed. Unfortunately, I do not know if even this is possible, or if my view of how the layers are configured is too simple. And if I may be a bit adventurous, I could even see the BBLAYERS variable being removed altogether (or at least not used as input), and instead be replaced by, e.g., a drop directory where you create links to the layers you want to use in a specific configuration. Then adding/removing a layer to the build is just a matter of adding/removing a link, which is easily done by tools like bitbake-setup, bitbake-layers, kas, repo, or even just ln -s, without having to manipulate an actual configuration file, which is always error prone. //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233330): https://lists.openembedded.org/g/openembedded-core/message/233330 Mute This Topic: https://lists.openembedded.org/mt/118311664/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
