On Mon, 2024-03-04 at 19:10 +0000, Peter Kjellerstedt wrote: > > > I mean something more like meta/conf/image-uefi.conf but kernel focused. > > Hmm, the naming of that file messes with the expectations I've learnt over > the years of working with OE. I've always thought that .conf files are > used for definitions that are part of the global configuration, and .inc > files are used for more local definitions. While I of course know that > there is no technical difference between the two, that kind of semantics > is helpful when looking at an individual file to know the context in which > it is used. > > > > > We need to do better about more focused conf/inc files. > > In that regard, kernel-module-dirs.bbclass was very focused. ;) > > Do you see a difference in, e.g., kernel-module-dirs.bbclass vs. > kernel-module-dirs.inc? I.e., why is an .inc (or .conf) file more suitable > than a .bbclass file in this case?
There is a big difference, please step back and try and think about the bigger picture on this and other variable definitions. > One reason I can see for why a .bbclass would be preferred, is because it > is only inherited once even if there are multiple inherits. E.g., say I > would take the proposed kernel-module-dirs.bbclass and turn it into a more > generic kernel-vars.inc file. This file would then most likely be needed > by, e.g., kernel.bbclass and module.bbclass. However, based on its current > contents, it would also be needed by kernel-module-split.bbclass that both > of them inherit. But since it is an .inc file, requiring it from both > kernel.bbclass and kernel-module-split.bbclass would result in a lot of > warnings about duplicate inclusion. On the other hand, having > kernel-module-split.bbclass rely on that whatever inherits it has already > required the kernel-vars.inc file seems wrong. What we have today with all the ever increasing maze of ever smaller bbclass files also seems very wrong. I'm trying to give some pointers about what I might find more acceptable since I very much doubt you'd accept an outright "no". Yes, what I'm proposing also isn't perfect and yes, we might need to work on actually improving some of the infrastructure if necessary but so be it, we need to try and improve this rather than making it worse. I'd also highlight that choosing to try and do this now at feature freeze is really not helpful. I do not have the time to spend on this right now. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196618): https://lists.openembedded.org/g/openembedded-core/message/196618 Mute This Topic: https://lists.openembedded.org/mt/104724883/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
