On Mon, 11 Jul 2022 at 17:46, Joshua Watt <[email protected]> wrote: > I did think of one way in which the order matters: If you are planning > on populating BBLAYERS from this list, the order would matter. If you > are doing that (or we want to allow it at all) it would need to be a > list instead of a dictionary.
This would not be allowed at all. This dict is strictly for checkout, actual BBLAYERS is set in bblayers.conf.sample coming from a configuration template pointed to by the json or from some other description in the json or elsewhere. > > They're not quite same as machines or distros, as they can be anywhere > > in the layer. This saves you the trouble of walking over the layer > > tree, especially when look at the layer repo through the browser. > > Configuring _what_ you want to build is probably even more contentious > that describing how to fetch your layers, so for starters I'd really > like to just focus on the layer fetching; TEMPLATECONF is far from the > only method for doing build configuration and I don't think we should > bake it into the "layer setup" piece at this point (same for machine & > distro, although they aren't generally contentious, see below). What are those other methods? TEMPLATECONF is contentious if you have ugly legacy scripts (understood by no one) that write into local.conf, and don't want to replace that with a clean set of templates. For new projects or teaching beginners I really would want to encourage only static, prefabricated templates that restrict local.conf to just two lines: distro and machine. Describing where templateconfs are is not mandatory in the scheme; if you don't want them, no one forces you to have the respective items in the json or use them if they're there. But they are standard, simple, and part of the core, and they work. I don't see why we can't have them now, and then argue about those other ways, what use cases they serve (that static templates cannot), and how to integrate them into the schema and tools. > I suspect that not including the machine/distro/template stuff for now > might give us better adoption as standard way to describe layers, > which is another reason I'm a little hesitant to include them (in > addition to duplicating information available in the layer itself) None of these are mandatory properties. You do not have to write them into actual jsons, and if they are present, you are free to ignore them. But I do want them, as I want something that can be used to actually set up a build all the way to bitbake, instead of just going halfway, and not being as functional as kas. We can make disclaimers in the schema description fields. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167877): https://lists.openembedded.org/g/openembedded-core/message/167877 Mute This Topic: https://lists.openembedded.org/mt/92259024/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
