On Tue, 2022-07-05 at 10:34 +0200, Alexander Kanavin wrote: > On Tue, 5 Jul 2022 at 05:09, Andre McCurdy <[email protected]> wrote: > > My proposal would be to try to reuse Linux kconfig. Users know how to > > run "make oldconfig", "make menuconfig", etc and I believe all key > > distro / machine configuration along with which meta layers should be > > enabled, which branch to use, etc can all be captured within a kconfig > > .config file. The task at hand would then become writing a tool to > > translate from a .config file to a set of distro, machine, local.conf > > config files (and an image recipe?) + drive whichever tool will be > > used to fetch meta layer git repos. > > At this point, I have to remind everyone about our harsh reality. > Which is having lots of core pieces without maintainers: > https://git.yoctoproject.org/poky/tree/MAINTAINERS.md#n45 > > Let's focus on adding foundational pieces of layer and configuration > management in a controlled, testable and tested manner for now. Which > is what I am trying to do. I think discussing grandiose designs for > things that try to please everybody is just a bit premature, honestly.
There is a time and a place for incremental improvement and also a time and a place where we need to step back, look at the bigger picture/problem and try and design for that. It is no secret that I've been avoiding the layer setup issue, I know it is a painful topic and will be hard to solve. I'm also acutely aware that we can't ignore it for that much longer, we need to do something about it. 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. Of course that potentially misses an opportunity to potentially address the wider issue. I did at least take the time (on a weekend) to write down my thoughts, which wasn't particularly easy. As for kconfig, I don't think we need another config file format. I have proven that json can encapsulate all the complexities of the configurations of the autobuilder and kas has also proven the same think with yaml. Yes, the menus are nice but at some point users will need to see our config files so I don't think its a much of a win as people think, unless the entire project used it which it doesn't and is unlikely to. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#167643): https://lists.openembedded.org/g/openembedded-core/message/167643 Mute This Topic: https://lists.openembedded.org/mt/92117681/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
