Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Tell me your build error message annoyances!
Date: Wed, 01 Jun 2011 17:25:58 +0100	[thread overview]
Message-ID: <1306945558.27470.435.camel@rex> (raw)
In-Reply-To: <1306940803.2529.101.camel@phil-desktop>

On Wed, 2011-06-01 at 16:06 +0100, Phil Blundell wrote:
> On Tue, 2011-05-31 at 15:26 -0700, Scott Garman wrote:
> > I'd like to collect some feedback on error messages while building that 
> > you find confusing/annoying/unhelpful. I'm going to be working on trying 
> > to improve the situation and would like to hear from you about what 
> > could be more helpful.
> 
> Funnily enough we were just having a discussion about this on irc.  My
> personal top two least favourite diagnostics are:
> 
> a) "bitbake -b nonexistent-file" gives ten lines of so of python
> exception traceback and then prints "MultipleMatches".
> 
> b) "bitbake -b recipe.bb", with a recipe that skips (due to an
> inCOMPATIBLE_MACHINE or whatever) gives the traditional ten lines of
> traceback spew and then prints "TypeError: 'NoneType' object is not
> iterable".
> 
> This is with bitbake 1.13.0.

Agreed, these are issues.

I'd like to highlight that there is an underlying design issue in
bitbake which make these hard issues to fix. Its very hard for bitbake
to work out when it needs to show the traceback and when it doesn't.

If the user has been given an explanation of the problem we shouldn't
show the traceback but its hard to know that is the case.

Somehow we therefore need to improve the error infrastructure in bitbake
to be able to tell the difference between an unexpected error where a
traceback is useful and a known error which has been explained to the
user and no traceback is required.

Cheers,

Richard




  reply	other threads:[~2011-06-01 16:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-31 22:26 Tell me your build error message annoyances! Scott Garman
2011-06-01  1:34 ` mark gross
2011-06-01 15:06 ` Phil Blundell
2011-06-01 16:25   ` Richard Purdie [this message]
2011-06-01 16:58     ` Chris Larson
2011-06-03 14:35     ` mark gross
2011-06-03 14:48       ` Paul Eggleton
2011-06-02 14:17   ` Phil Blundell
2011-06-02  7:34 ` Martin Jansa
2011-06-03  6:10 ` Darren Hart
2011-06-03  8:11   ` Richard Purdie
2011-06-03 14:22   ` Mark Hatle
2011-06-03 15:43     ` Phil Blundell
2011-06-03 15:47       ` Chris Larson
2011-06-07  4:53         ` Darren Hart
2011-06-07  9:18           ` Richard Purdie
2011-06-06 21:13   ` Scott Garman
2011-06-03 14:57 ` Koen Kooi
2011-06-09 11:02 ` Phil Blundell
2011-06-09 11:17   ` Richard Purdie
2011-06-09 15:00 ` Scott Garman

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=1306945558.27470.435.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@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