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. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2031): https://lists.openembedded.org/g/openembedded-architecture/message/2031 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]] -=-=-=-=-=-=-=-=-=-=-=-
