On Mon, 10 Jun 2024 at 16:51, Richard Purdie <[email protected]> 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? > 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 ? > > 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'? > 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. > 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? > 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. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200503): https://lists.openembedded.org/g/openembedded-core/message/200503 Mute This Topic: https://lists.openembedded.org/mt/106004166/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
