On Mon, 10 Jun 2024 at 12:08, Richard Purdie <[email protected]> wrote:
> b) The code adding/removing require lines from local.conf seems a > little fragile. I did wonder if we wanted a higher level bitbake API to > this, for example a BB_CONF_FRAGMENTS variable which basically tagges a > set of config files onto the end of the base configuration parsing? > This wouldn't be hard to implement in bitbake and would then make the > tooling easier and less fragile. 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? It would still need to look for an assignment to that variable in a 'standard location' (e.g. conf/local.conf), and then rewrite the file with the new assignment. That doesn't seem any easier to me than just using 'require path/to/fragment'. On the other hand, there could be qa checks for presence of a certain fragment(s) in that variable. E.g. a layer could stop a build if it detects that something is not there. Another option is to copy/symlink the fragments into build/conf/fragments/ and have bitbake pick them up with a glob. > c) Do we want to have the config fragment name as a > "<layername>/<fragementname>" pair and have the fragments live directly > in conf/fragments in a layer? The idea is to allow deep slash-separated hierarchies here to be used as categories, and map their names directly to file paths (stripping the conf/fragments/ prefix and .inc suffix in the tooling UI). Think of something like meta-yocto-bsp/conf/fragments/machines/arm/beaglebone.inc that would be presented as 'machines/arm/beaglebone' in the UI. Conversely, what layer it's in is not relevant in the tooling UI. If someone wants to enable systemd, they wouldn't care which layer would give them that. This would come particularly handy in interactive UIs (e.g. something curses-driven and mimicking buildroot). > d) How do you control ordering between the fragments? Do we need > dependencies? How does layer ordering or dependencies affect anything? > Can fragments conflict? I deliberately kept all of this out of scope to avoid going crazy with thought experiments and resulting over-engineering. I feel we need to start using the fragments in practice, particularly eat our own dog food on the autobuilder with them, and then problems and answers to them will arise from that practice. > e) You've used comments at the start of the files as > summary/description. Should we use some kind of more variable like > syntax which allows for other information in the future? I'm open to proposals, but this was by far the easiest and most straightforward and obvious to anyone reading the fragment. Python has no support for 'metadata in comments' that we can reuse. If there's need for other metadata about fragments we can invent special syntax for it, but summary/description pair can stay as #-comments. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200469): https://lists.openembedded.org/g/openembedded-core/message/200469 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]] -=-=-=-=-=-=-=-=-=-=-=-
