Re: bitbake does not fail when QA issues encountered

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Jan 27, 2011 at 08:02:44AM -0700, Tom Rini wrote:
> On 01/27/2011 04:27 AM, Frans Meulenbroeks wrote:
>> 2011/1/27 Thomas Zimmermann<ml@vdm-design.de>:
>>> On Wednesday 26 January 2011 16:27:43 Tom Rini wrote:
>>>> I believe, from talking with Chris Larson about this before, in 1.8.x
>>>> the error wasn't being populated upwards, but that got fixed.  At heart
>>>> the problem is that QA errors aren't throwing a "kill the build" type
>>>> error.  This should be changeable (and would cause 1.8.x to fail too, if
>>>> someone backported this change to a 1.8.x using OE) to insane.bbclass.
>>>
>>> I don't think that a QA error should "kill the build" because then no 
>>> build
>>> from scratch would be possible.
>>> We have a QA error in coreutils-native because it doesn't inherit 
>>> gettext. But
>>> adding this inherit would result in a dependencie loop.
>>>
>>> So if a QA error would stop build we would need something for those
>>> situations.
>>>
>>> And additionally i think that most QA errors aren't fatal because most of 
>>> them
>>> are for non-standard .desktop files.
>>
>> If it is not a fatal it should probably be given as a warning
>> (especially the non-std .desktop things)
>> If corutils-native has a problem becuase it does not inherit gettext,
>> then maybe (if possible) it should be added or alternately if this is
>> not a problem it definitely should not be an error but a warning.
>>
>> For me an error indicates something is broken and needs fixing.
>> Reverting that: if a condition does not break things it is not an
>> error (and yes, I know this is quite a black and white view, and that
>> there are situations this is not true).
>>
>> Generally masking errors does not make them go away.
>
> The problem is that today we have QA Errors that are warnings 
> (coreutils-native) and QA Errors that result in a non-zero exit code but 
> also don't "kill the build" nor make it obvious at the end that there is a 
> non-zero exit code (GNU_HASH, RPATH).  Finally we do have "kill the build" 
> fatal checks in insane.bbclass, namely the do_qa_configure tests.

Actually, I believe there was a simple error in the code which made QA Error 
on RPATH not kill the build[1]. BTW, GNU_HASH QA Error does stop the build.

[1] http://thread.gmane.org/gmane.comp.handhelds.openembedded/42168

-- 
Denys