[OE-core] [PATCH] allarch: Add warning about packagegroup

Richard Purdie richard.purdie at linuxfoundation.org
Wed Aug 27 23:03:15 UTC 2014


On Wed, 2014-08-27 at 13:20 -0400, Bob Cochran wrote:
> On 08/19/2014 08:35 AM, Richard Purdie wrote:
> > Since we want to start including this class conditionally, detect cases
> > where packagegroup files use the old ordering and inform the user they
> > need to update this.
> >
> > Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> >
> > diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
> > index c953e7c..4bc9927 100644
> > --- a/meta/classes/allarch.bbclass
> > +++ b/meta/classes/allarch.bbclass
> > @@ -37,5 +37,7 @@ python () {
> >           d.setVar("EXCLUDE_FROM_SHLIBS", "1")
> >           d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
> >           d.setVar("INHIBIT_PACKAGE_STRIP", "1")
> > +    elif bb.data.inherits_class('packagegroup', d) and not bb.data.inherits_class('nativesdk', d):
> > +        bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" % d.getVar("FILE", True))
> 
> 
> I'm reviewing my recipes today to make sure everything conforms with 
> this methodology.
> 
> This is minor, but I'm curious about something with this patch regarding 
> warnings & errors:
> 
> Should I care that this commit says 'add warning' but the implementation 
> calls bb.error()?

"warning" in this sense was intended to stop the build. In order to do
that, it would have needed to be a bb.fatal though. Hindsight is
great...

> It looks like neither warning nor error throws an exception, so are they 
> interchangeable, both really warnings?
> 
> Although my build this morning produced an image, I had a couple of 
> these errors, or were they just warnings?

They aren't interchangeable. The error will have set the exit code of
bitbake which a warning wouldn't have done. Bitbake will also have
reported an error exit code. So being an error did make some difference,
just not as much as a bb.fatal would have :/

Cheers,

Richard




More information about the Openembedded-core mailing list