[OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors

Koen Kooi koen at dominion.thruhere.net
Fri Jul 1 15:09:25 UTC 2011


Op 1 jul 2011, om 16:55 heeft Phil Blundell het volgende geschreven:

> On Thu, 2011-06-30 at 17:49 +0200, Koen Kooi wrote:
>> It's a white list, so:
>> 
>> # 0 - non dev contains .so
>> # 5 - .la contains installed=yes or reference to the workdir
>> # 7 - the desktop file is not valid
>> # 8 - .la contains reference to the workdir
>> # 9 - LDFLAGS ignored
>> 
>> Are warnings and
>> 
>> # 1 - package contains a dangerous RPATH
>> # 2 - package depends on debug package
>> # 3 - non dbg contains .so
>> # 4 - wrong architecture
>> # 6 - .pc contains reference to /usr/include or workdir
>> # 10 - Build paths in binaries
>> # 11 - package depends on devel package
>> 
>> Are fatal errors. The splits seems arbitrary to me, but it that's how it was last year before RP disabled all fatal errors.
> 
> I guess the split does make some sense as it is, although I can't see
> any reason for #8 not to be in the fatal set.  #5 also seems like it
> would belong there except that, as far as I can tell, that test doesn't
> actually exist in the code so it's a bit academic how the results are
> treated.
> 
> #7 is, in the scheme of things, a relatively minor infringement (and
> usually an upstream bug anyway) so probably oughtn't to make a package
> unshippable.  #9 is potentially a nuisance but in most cases doesn't
> cause any actual problems, so again I think it's fair for this to be a
> warning. 
> 
> Incidentally, it seems that the description for #6 is a bit wrong: it
> doesn't actually do any checking for /usr/include.  And #3 should
> obviously be talking about .debug not .so.

I use #9 as a red flag for broken buildsystems, so having it fatal has helped me a lot. But with RPs insane rework I can easily override the set from DISTRO.conf or local.conf



More information about the Openembedded-core mailing list