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>
Cc: Chris Larson <clarson@kergoth.com>
Subject: Re: Tell me your build error message annoyances!
Date: Tue, 07 Jun 2011 10:18:11 +0100	[thread overview]
Message-ID: <1307438291.15712.16.camel@rex> (raw)
In-Reply-To: <4DEDAEBE.8080404@linux.intel.com>

On Mon, 2011-06-06 at 21:53 -0700, Darren Hart wrote:
> On 06/03/2011 08:47 AM, Chris Larson wrote:
> > Heh, I used to have a personal branch where I dropped those, and also
> > removed the unnecessary NOTE: prefix. I think its a given that
> > something that doesn't indicate a warning or an error is simply
> > informative :) The problem with dropping those messages is for
> > postprocessing scripts, which may well want/need to know when a task
> > completes, not just when it starts. Still, yet another case of
> > something we could drop as long as we log it. We need to add a main
> > bitbake execution log that captures everything, including debug
> > messages, whether the user specifies -D or not.
> 
> In most systems, running with -D implies not only greater verbosity, but
> also reduced performance. I haven't checked, but I expect that is the
> case with bitbake as well. I don't think we want to enable all of -D and
> log it by default.

I'm not sure the performance hit of this would be that great to be
honest, particularly if we localised the output to the tasks and didn't
hit the IPC mechanism for all the messages. It certainly could be
valuable to have more robust logfiles on disk so that when things do
break we can dive into them and get full debug info rather than the
current partial info.

The main cost would be increased disk space but disks are cheap
comparatively and the IO is minor compared to other things we do...

Cheers,

Richard






  reply	other threads:[~2011-06-07  9:21 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
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 [this message]
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=1307438291.15712.16.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=clarson@kergoth.com \
    --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