On 02/03/2011 10:43 AM, Tom Rini wrote:
On 02/03/2011 12:09 AM, Denys Dmytriyenko wrote:
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<[email protected]>:
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
Good spotting. But.. GNU_HASH QA error will give you a non-zero exit
code and not kill the build so we're back where we started, albeit with
a less often hit in the community trigger (but I bet more often hit in
private / 3rd party collections).
I think what we need to do is take what I think the poky approach is
which is to change QA Error to QA Warning for things we aren't willing
"kill the build" on. And given existing user bases we should (per
Stefan's suggestion later) make anything that doesn't kill the build
really today into a warning and change it post-release, or in
meta-openembedded. I'll try and get to this today and RFC the change.
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
