On Mon, 2024-09-09 at 12:36 +0200, Alexander Kanavin wrote: > On Fri, 23 Aug 2024 at 13:18, Richard Purdie > <[email protected]> wrote: > > I think that if we implement BB_CONF_FRAGMENTS in bitbake itself, > > we > > will remove the need for the actual fragments file. > > I struggle to understand what this means. Can you elaborate please? > What are option A and option B that seem to be compared here?
Sorry for the delay in replying, I've lost track of a few things. To put this back in the original context of what I wrote: > > 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. I was saying that with dedicated fragment support in bitbake, the need for the fragment *configuration* file (fragments.conf) would be removed. The decision we then have to make is where would bitbake add the fragment files during the parsing process. Before or after anonymous python fragments (probably before?). Before or after key expansion? Those decisions are often really tricky and putting the include in the metadata at a certain point (e.g. the lines in bitbake.conf) is one easier way to make that clear. Despite that, I am leaning to a more dedicated mechanism in bitbake than a fragments.conf file as it gives us a more precise API in many ways. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2052): https://lists.openembedded.org/g/openembedded-architecture/message/2052 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]] -=-=-=-=-=-=-=-=-=-=-=-
