On Tue, 2024-06-11 at 12:45 +0200, Alexander Kanavin wrote: > On Mon, 10 Jun 2024 at 16:51, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > > I don't quite follow. If BB_CONF_FRAGMENTS value is a space separated > > > list of fragments, then how would the tooling > > > > > > - add to it? > > > - remove from it? > > > > bb.utils.edit_metadata()/bb.utils.edit_metadata_file() ? > > Right, I had no idea this exists :) > > > I'm wondering about whether having a variable makes it easier to users > > to understand/edit. > > I think there's benefit in having a variable that makes it separate > and distinct from regular 'require' statements, but I can't form a > clear preference for either option. Should this be taken to some kind > of decision forum, e.g. oe-architecture or TSC?
oe-arch is the right place to discuss with the OE TSC being the ultimate decision maker if needed. > > I meant to also mention that I'm a bit concerned about using local.conf > > specifically in the tool, I'd prefer not to require a specific conf > > file. > > I agree that local.conf should be left alone. It's something coming > from templates and I would rather never touch it with tools after the > fact. > > But either the 'require' statements or the variable containing the > fragment list has to be written into something that bitbake can see. > Should they go to build/conf/fragments.conf ? I'd wondered about a dedicated file, yes. Perhaps with locked sigs also becoming a dedicated conf file for similar reasons. > > > Another option is to copy/symlink the fragments into > > > build/conf/fragments/ and have bitbake pick them up with a glob. > > > > I don't like the copy idea, the symlink approach is interesting. The > > main downside there is capturing the give config and ordering. > > 'give config'? Sorry, it was meant to read "given config". > > > That seems reasonable but I wanted to avoid every layer needing to nest > > by a directory level to make it clear where the fragments come from. I > > think some kind of naming standard might ultimately make things clearer > > to the user? > > > > Requiring the first entry be a layer name doesn't preclude the rest... > > Okay, I'll rework to include the layer name upfront. > > > I ask the questions since we have been trapped by choices in the past > > and it since these are likely things which will arise, we might want to > > at least consider them now. > > Hopefully the current code makes no choices for these things. It just > adds/removes requested fragments, nothing else. But it can be extended > to read fragment metadata, and armed with that (and the list of > fragments already enabled) make decisions about what the new list > should be, or whether the request should be declined. I'd like to explore these issues a little bit further now before we lock in on a format as I think their need is probably inevitable. > > > We do have our parser which can easily handle: > > > > CONFFRAG[summary] = "some summary" > > CONFFRAG[description] = "Longer description with \ > > multiple \ > > lines \ > > " > > I must be missing something here. If this is defined in two different > fragments and both are included, how would one not step on the other > with these assignments? They would overwrite each other but you can still parse the data from each file in turn. layer.conf files did give bitbake a similar challenge. It gives more readability at the cost of not being able to store all the data in the same data store. > > or > > > > CONFFRAGS += "myfragment_name" > > > > myfragment_name[summary] = "some summary" > > myfragment_name[description] = "Longer description with \ > > multiple \ > > lines \ > > " > > Okay, this one in my opinion is a big readability (and write-ability) > regression compared to #-comments. For extended metadata (such as > dependencies/conflicts) something like this would be needed, but I'd > rather not use it for summary/description. I'm not happy with the above either but I do think we should fine a format which is parsable as I really dislike 'magic' comments (similarly in machine conf files too). They don't scale and have machine readability issues. I'm open to other other ideas. I'd even consider some kind of new syntax if needed and we can't make the existing syntax work. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200507): https://lists.openembedded.org/g/openembedded-core/message/200507 Mute This Topic: https://lists.openembedded.org/mt/106004166/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
