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

[Cui, Dexuan]

Chris Larson wrote:
> 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.

I noticed in poky bb.error() doesn't cause bitbake to return a non-zero exit code.

Thanks,
-- Dexuan