On 11.02.21 14:04, Richard Purdie wrote:
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 :(.
Fair enough - guess I will go with the educating ppl (including myself)
path then
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147953):
https://lists.openembedded.org/g/openembedded-core/message/147953
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]]
-=-=-=-=-=-=-=-=-=-=-=-
