Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: bitbake does not fail when QA issues encountered
Date: Thu, 27 Jan 2011 08:02:44 -0700	[thread overview]
Message-ID: <4D418914.2030703@mentor.com> (raw)
In-Reply-To: <AANLkTimy4Q0Y_3Y-=8=QCifqQUYwWmFx4T0DH+dNXPeZ@mail.gmail.com>

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.

-- 
Tom Rini
Mentor Graphics Corporation



  reply	other threads:[~2011-01-27 15:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 19:37 bitbake does not fail when QA issues encountered Maupin, Chase
2011-01-25 20:58 ` Frans Meulenbroeks
2011-01-25 21:36   ` Khem Raj
2011-01-26 10:32     ` Martyn Welch
2011-01-26 15:03       ` Maupin, Chase
2011-01-26 15:27         ` Tom Rini
2011-01-27  9:38           ` Thomas Zimmermann
2011-01-27 11:27             ` Frans Meulenbroeks
2011-01-27 15:02               ` Tom Rini [this message]
2011-02-03  7:09                 ` Denys Dmytriyenko
2011-02-03 17:43                   ` Tom Rini
2011-02-03 22:20                     ` Denys Dmytriyenko
2011-02-03 23:09                       ` Tom Rini
2011-02-04  7:54                         ` Frans Meulenbroeks
2011-02-04  8:16                           ` Stefan Schmidt
2011-02-04  8:37                             ` Frans Meulenbroeks
2011-02-04  9:03                               ` Stefan Schmidt
2011-02-04  9:57                                 ` Frans Meulenbroeks
2011-02-04 12:42                                   ` Otavio Salvador
2011-02-04 13:10                                     ` Frans Meulenbroeks
2011-02-04 13:58                                       ` Andreas Mueller
2011-02-04 14:59                                   ` Tom Rini
2011-02-04 15:26                                     ` Frans Meulenbroeks
2011-02-04 15:52                                       ` Otavio Salvador
2011-02-05 13:35                                         ` Frans Meulenbroeks
2011-02-06  1:21                                           ` Otavio Salvador
2011-02-06 12:02                                             ` Frans Meulenbroeks
2011-02-09 20:02                                           ` Maupin, Chase
2011-02-09 20:13                                           ` Maupin, Chase
2011-02-10  6:32                                             ` Frans Meulenbroeks
2011-02-04 17:37                                       ` Tom Rini
2011-02-04 14:44                     ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D418914.2030703@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox