On Thu, 2021-02-11 at 13:10 +0100, Konrad Weihmann wrote: > > On 11.02.21 12:43, Richard Purdie wrote: > > On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: > > > After this patch got merged I notice some "noise" in my builds. > > > > > > For bbappends which inherit unrelated classes I get a lot of warning like > > > > > > Issue: nativesdk-openssh: native/nativesdk class is not inherited last, > > > this can result in unexpected behaviour. Classes inherited after > > > native/nativesdk: my-custom-class.bbclass [native-last] > > > > > > First it doesn't give any hint that this is caused by the bbappend and > > > secondly I have no idea how to fix that (if that is even possible). > > > > > > So I would like to have at least an option to ignore these warnings for > > > classes I'm sure don't cause any conflict - something more granular then > > > just to deactivate this pretty useful check. > > > > > > Thoughts? > > > > This shouldn't be too common as most recently use BBCLASSEXTEND which > > would ensure they're last. Which recipes are you running into this > > with? > > Sure, it does only affect recipes which are manually inheriting native > (I got a bunch of them, that's why I noticed).
Any reason they don't/can't use BBCLASSEXTEND? > A (unfortunately) common pattern I face is that ppl share variables > between recipes using bbclasses - which to my understanding shouldn't > cause any issues when being inherited after native. > And the same pattern is applied to recipes only being appended. You could use conf files for variables. That is something I'd like to try and encourage more of, I've been meaning to look at that for the core too. > > You really don't want your class coming after native/nativesdk, if you > > understand what that code is doing you'll realise it is rather risky :( > > Totally, that why I'm absolutely in favor of this patch. > > > > > You could turn off that warning for a set of recipes if you really > > don't care but I'd prefer not to make that too easy. > > But that would turn off the whole feature, which is bad IMO. > What I see (once that will be used by a wider audience in the wild) is > that this will lead to questions (consuming my time as an integrator) or > to the fact that this check will be turned off completely. > Either way not the best choice if you'd ask me. I'm hoping that people might fix the underlying issues. > That's why I asked for a more granular configuration, so that a person > who's able to understand the implications of a bbclass in relation to > native could turn it off on a distro/site config level. > > And just to be clear I wouldn't want that to be used widely, or even > being promoted. I can guarantee that making any such option available will just have people reach for it and use it. You clearly want to here when the changes needed to avoid it are probably not that difficult. > If that's not what the project wants, I'm also fine with it, but then it > would be really helpful to point to the bbappend as a culprit and not > the base recipe I understand why you'd want it, I'm just not sure if would encourage the right behaviour :(. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147949): https://lists.openembedded.org/g/openembedded-core/message/147949 Mute This Topic: https://lists.openembedded.org/mt/80075083/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
