[bitbake-devel] [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Chris Larson]

On Mon, Jun 27, 2011 at 6:49 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
>> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
>> > On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui at intel.com> wrote:
>> > > Martin Jansa wrote:
>> > >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui at intel.com>
>> > >> wrote:
>> > >>> This patch moves the logic of show_appends_with_no_recipes from
>> > >>> bitbake-layers into bitbake, and makes the script die with a fatal
>> > >>> error message printed.
>> > >>
>> > >> I agree that this is problem, but I'm not sure if it should be fatal.
>> > >>
>> > >> Imagine the case when you enable some layer managed by someone else
>> > >> (lets call it LS) and you're using different oe-core revision, maybe
>> > >> current HEAD and that LS wasn't updated for that or vice versa you're
>> > >> using some oe-core release version and you want to reuse some recipes
>> > >> from LS in current version.
>> > >>
>> > >> I think that big fat warning that some .bbappends does not match
>> > >> should be enough to decide if it's fatal for me (and I'll kill that
>> > >> build) or that's fine (when I'm not interested in those .bbappends
>> > >> from LS and I'm using only some other .bb files from LS).
>> > >>
>> > >> If we make it fatal then I would be forced to remove unmatched
>> > >> .bbappends from LS before build which can be difficult to share
>> > >> (unless I create own LS branch and use it in my distro).
>> > > Thanks a lot for the explanation!
>> > > So looks we may as well change the "bb.fatal" to "bb.error"(that is not
>> > > fatal and wouldn't be ignored by bitbake-layers).
>> > > This is the new patch (on a new branch dcui/bb-v2):
>> > > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
>> >
>> > Are you sure this shouldn't be a warning? Remember that any error
>> > displayed results in a non-zero exit code from bitbake.
>>
>> So, speaking of which - what is the practical use for bb.error? It gives an
>> error message, but doesn't stop the build. Although it returns a non-zero exit
>> code, which for most autobuilders indicate a failed build anyway... What's the
>> point?
>
> It denotes something which the user really needs to know about and fix.
> The sanity tests are good example and I'd really like to see sanity
> issues becoming bb.errors in most cases.
>
> You can also think about it as being a point on the error severity
> scale:
>
> Note: Information only
> Warning: Something happened which the user likely needs to fix
> Error: Something happened the user is strongly recommended to fix - set
>       exit code accordingly.
> Fatal: Something bad happened and there is no hope so stop.
>
> I think in the scheme of different error priorities and actions, it
> makes sense...

I really don't think they're very useful right now. If our UIs
actually captured the errors and summarized them at the end of the
build, as well as had them in a global log, then I could see them
being of use, but having an error message that might have scrolled
past an hour ago result in a non-zero exit code is far from ideal. As
a user, I have no idea why it seems to have failed.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics