On Wed, 21 Feb 2024 at 11:50, Richard Purdie <[email protected]> wrote: > > 2. There would be however a tool that allows standardized operations: > > add/remove/list/search. I'd suggest 'bitbake-config' or similar, > > which > > would basically reuse bitbake-layers infrastructure as much as > > possible. Bitbake-layers itself is already over-stuffed with various > > commands, and is more about layer management. > > I do have some concerns about "bitbake-config" since it sounds > potentially a lot more general purpose and we need to be careful about > that. Naming is important and hard and I don't think the name should > block this but I do want to be clear up front that this is a tricky > area.
Perhaps 'bitbake-build-config' then? > > 4. Each fragment must contain a description at the start, and the > > tooling would refuse to work with fragments without descriptions. > > Similar to machine configurations in oe-core. > > I'm concerned about the machine configuration descriptions as they > invent a new syntax which the rest of the system can't read. With > layer.conf we deliberately tried not to add magic comment syntax. > > Ideally here we'd wither use normal variables, or we write some kind of > dedicated markup which bitbake itself can understand. > > A key element of this will be knowing how to identify and specify a > specific fragment. This implies they should have "names" but we also > probably need to make it easy to know where a fragment comes from even > out of context of the layer. I don't have a specific proposal, just > mentioning thoughts at the moment. I thought the name of the fragment would simply be the part of it's path between conf/fragments/ and .inc. For example: core/no-gpl3 core/arch/x86-x32 core/autobuilder/esdk yocto/cdn-sstate yocto/distro/poky-altcfg Note that there can be nested categories this way. Each layer owns the top category, e.g. only oe-core is allowed to define core/ items. For things like descriptions, or dependencies (as suggested by Mark) I don't have a clear idea yet, and would like to ask the audience. If it's a bitbake variable, how would bitbake namespace the same variable being defined in several fragemnts - do we need to introduce 'file-specific' overrides or something of that kind? I would *not* want to spread this information across multiple files: if we can make a fragment file self-contained, we should. I also spent a bit of time if there's standard python markup for such 'metadata about files' and seems like there isn't. """-style doc-strings is all I could find. Alex > > 5. The eventual goal is to reduce a typical local.conf to > > distro+machine+fragments. Any other settings in it should be seen as > > 'local hacks' that never leave a developer's machine. > > > > 6. The testing ground for all of this would be transferring the > > fragments from > > https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json > > into oe-core/poky. So that when someone gets feedback that their > > change failed on multilib, they don't have to go through complicated > > investigation of how to reproduce that. There are also fragments all > > over selftest that could be consolidated this way. > > > > 7. Layers are welcome and encouraged to publish their own fragments > > inside the layer. I love copy-paste-tweak programming without having > > to fully understand what is being tweaked, and I find it superior to > > 'reading documentation', especially when such documentation spends > > pages after pages describing design principles, syntax intricacies or > > rarely used command line options, and doesn't get to something I can > > copy paste until the end (and in worst cases doesn't offer that at > > all). Such fragments don't have to be directly usable; they can serve > > as a set of starting points. > > > > Anything else? Anything controversial above? > > I'd like to understand more about the syntax used in the files and the > identification/naming of fragments. > > In the back of my mind is the idea that in some ways we need a table > operation. layer.conf files, machine conf files, distro configs and so > on are effectively rows in a "table" of data and this feels similar. > I've wondered if there is a better way to handle such things. > > Cheers, > > Richard > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1981): https://lists.openembedded.org/g/openembedded-architecture/message/1981 Mute This Topic: https://lists.openembedded.org/mt/104485443/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
