> -----Original Message----- > From: [email protected] <openembedded- > [email protected]> On Behalf Of Richard Purdie > Sent: den 23 augusti 2024 13:19 > To: [email protected]; openembedded-architecture <openembedded- > [email protected]> > Subject: Re: [Openembedded-architecture] [OE-core] [PATCH] bitbake-config- > build: add a plugin for config fragments > > On Tue, 2024-06-11 at 14:18 +0200, Alexander Kanavin via > lists.openembedded.org wrote: > > the discussion after submitting a prototype for configuration > > fragments [1] raised some design points, which I'd like to list here, > > with the goal of getting approval/consensus on them, before I write > > any further code: > > > > 1. There is a dedicated file for listing what fragments are enabled > > in a build, something like build/conf/fragments.conf. > > > > The prototype writes into local.conf, but writing into that with > > tooling is undesirable. We already do it elsewhere, and it's all > > hacks. > > I think that if we implement BB_CONF_FRAGMENTS in bitbake itself, we > will remove the need for the actual fragments file. The main decision > at that point would be exactly where we include the fragments files. > > What we could do is actually code this explicitly with a line like: > > include_fragments BB_CONF_FRAGMENTS <pattern> > > in bitbake.conf. > > That does mean adding syntax to bitbake but that isn't too hard to do > with a well defined "command" like this. The <pattern> would be the > glob used to find possible fragments within the conf dirs. > > > 2. The actual > > listing is in a BB_CONF_FRAGMENTS variable that contains > > a space separated list of what is enabled. Bitbake will have special > > handling of these, and will read and process the fragment file, same > > as if they were included with a 'require' statement. > > > > The prototype is using direct 'require', which means it's not > > possible to tell what is an (enabled) fragment and what is just a > > regular file include. > > Agreed. > > > 3. Fragments will contain metadata about themselves, the first use > > case for it will be summary/description, with > > dependencies/ordering/conflicts to be defined later on: > > > > CONFFRAG[summary] = "some summary" > > CONFFRAG[description] = "Longer description with \ > > multiple \ > > lines \ > > " > > The above means that to obtain the full set of metadata the tooling > > will have to parse each fragment individually, rather than rely on > > bitbake's configuration parser. It's a compromise between readability > > and having a strictly defined machine-readable syntax. > > > > The prototype uses #-comments for summary/description. > > We have this issue in a few places so I'm wondering if there is any > syntax we could use/add that would say "this is markup about the file". > > The "few" places I'm thinking about are distro, machine and layer conf > files to list just a few. What we want is some way to have a data > structure of fragment names with their summary/desc and possibly more.
Don't forget BSP files. Replacing the current #@FOO with something that ends up in the datastore would be nice, so that the information can be used in, e.g., the `bitbake-layers show-machines` command. > I think this is an important enough thing to consider if there is a > specific markup we could use, that would translate into the data store > well. > > I do really want a proper language/syntax for this rather than magic > comments. > > Looking at this from a difference direction, another possible options > might be if the fragment conf file does something like: > > addfragment <name> CONFFRAG_SUMMARY CONFFRAG_DESC before XXX after YYY > > So bitbake could parse all the globbed fragments and construct data > about the possible options (summaries/descriptions) with the advantage > we can then cover ordering constraints. > > Or, continuing to think out loud: > > SOMEFRAGMENT[summary] = "xxx" > SOMEFRAGMENT[desc] = "yyy" > SOMEFRAGMENT[after] = "aaa" > SOMEFRAGMENT[before] = "bbb" > SOMEFRAGMENT[conflicts] = "ccc" > > addfragment name SOMEFRAGMENT > > again, with the magic then being for the addfragment directive to turn > the variable into the data structures we need. > > I'm wondering if we can do something for distro/machine file, with the > differences that we don't want to encode knowledge of the idea of a > machine or a distro within bitbake and in those cases, only one should > ever get selected. I'm not sure how exactly we'd do that with syntax > but I feel something is possible. > > > > 4. There are open questions around ordering/dependencies/conflicts: > > > > How do you control ordering between the fragments? Do we need > > dependencies? How does layer ordering or dependencies affect > > anything? > > Can fragments conflict? > > > > The implementation to handle these can be added later, but the > > concerns can be raised now. We only need to ensure nothing in the > > initial implementation that lands in master locks into a specific > > choice around those. > > > > The prototype doesn't do anything around those; it enables a single > > fragment when being asked to do so. If the build later fails, it's a > > 'user error'. > > See above, I think there are ideas worth giving more thought here with > a lot of potential if we get this right. We just need to think about > what small additions to the syntax we could add that would give us the > capability we need without over complicating things. > > Cheers, > > Richard Being able to order the fragments is important. For reference, we have a simple solution in our current platform where our oe-init-build-env has support for gathering local.conf.sample.XX files (where XX is a number between 00 and 99) from all layers specified in BBLAYERS and concatenating them based on the XX numbers (local.conf.sample from meta-poky is given XX == 50). This way the local.conf.sample files can be ordered based on functionality, regardless of what layers are included and in what order they are listed in bblayers.conf. Looking at the proposals above, I would go with SOMEFRAGMENT[...] rather than arguments to the addfragment command simply because the former is easier to extend if new needs arise. //Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2032): https://lists.openembedded.org/g/openembedded-architecture/message/2032 Mute This Topic: https://lists.openembedded.org/mt/106611931/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
