On Tue, Jul 5, 2022 at 4:16 AM Alexander Kanavin <alex.kana...@gmail.com> wrote: > > On Tue, 5 Jul 2022 at 10:51, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > The challenge with your approach is that it is bolted directly onto > > bitbake-layers, which makes it not only OE-Core API but bitbake API > > too. There is a standard such changes need to reach and I'm not > > convinced that is doesn't tie our hands in future as is. > > > > I suspect in reality, we could probably have the same functionality in > > a separate script in OE-Core, maybe improving the APIs/library > > functions from bitbake-layers if needed. That would lower the bar and > > mean we could have something focused on eSDK needs rather than the > > wider problem. > > I added the layer config generator as a bitbake-layers plugin for these > reasons: > 1. It is layer management functionality, and so logically belongs in that > tool. > 2. It is more visible and discoverable when it is in there, as opposed > to all those executables in poky/scripts/ which most people have no > idea about. > 3. It needs to get a list of active layers and their locations > programmatically, which is trivial from a bitbake-layers plugin, less > so from other places. > 4. it can reuse code from meta/lib/oe if/when needed.
Focusing on the data model helps with that; as long as it's reasonable to maintain the configuration manually, having the tool to create the layer setup from your current layers is a useful way to initially populate/maintain that. An easily consumable data model makes it easier for 3rd party tools (e.g. kas) to pivot to using it instead of making their own ad hoc, and makes it possible for whatever flavor of other tooling to grow up around it. In that regard, I'd prefer that the JSON file be what defines a layer setup and included in layers. The setup python script is nice (and convenient), but I think it would be better as an additional file alongside the JSON file (or that someone can download independently if the layer doesn't have one). I think a few tweaks would make it possible to write the script so it can operate generically on any JSON file input without needing templating. I agree, it is harder to define a stable data model.... but probably worth it in the long run? Also, sticking to submodules doesn't mean I don't see the value here. We need something for layer CI, first-time startup guides, et al, and I think that either has to be "adopt kas", or take this approach. I _much_ prefer this approach to kas. I apologize if it came off that I didn't want to do this at all. > > There are a few things in there that I'd already like to do > differently, and there's also the 'save the active build/conf in > TEMPLATECONF format' piece missing, so there'll be a reworked version, > arriving in bite-sized chunks for easier review/discussion. > > Alex > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167660): https://lists.openembedded.org/g/openembedded-core/message/167660 Mute This Topic: https://lists.openembedded.org/mt/92117681/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
