On 05/31/2011 03:26 PM, Scott Garman wrote:
> Hey folks,
>
> 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.
>
> I'm starting to track some of these situations with the following bugs:
>
> http://bugzilla.pokylinux.org/show_bug.cgi?id=542
>
> http://bugzilla.pokylinux.org/show_bug.cgi?id=1127
>
> http://bugzilla.pokylinux.org/show_bug.cgi?id=1128
>
> I can't promise to fix everything you come up with, but I'd like to try
> to make a dent in some of these issues and improve the usability of our
> build system.
>
> Thanks,
>
> Scott
>
These are maybe a bit off topic, but I'll leave it to you to decide if
they meet the criteria for this effort.
o bb.debug messages are not logged anywhere nor do they appear on the
console with -DDD during recipe parsing (while bb.note messages do
make it to the console).
o I'm seeing duplicate messages lately - no examples handy, I'll post
or open a bug next time.
o The bash logging facility (logging.bbclass) is still a second class
citizen and probably needs a bitbake server hook so bbnote, bbplain,
bbdebug, etc. can call into bitbake proper and use the python
equivalents and therefor also make it to the proper destination
(console or log).
o It's been mentioned, but I'd like to second that most of the time,
getting a traceback is really not very helpful. Chris Larson mentioned
moving the exception handling higher up the stack - I think that
makes a lot of sense. I'd also suggest not printing a traceback unless
running with at least -D. A catchall try block that only
does:
print "Unhandled exception:", e
under normal conditions and prints a trace with -D enabled would clean
things up a lot I think.
o In general I find the default UI to be exceedingly noisy. It feels
very much like what I would write for something I was actively
developing - ie, something I expect to break a lot! I don't think
that's the sort of impression we want users to have while building a
release (for example).
I'd prefer if what we currently get today was the output of -D. The
current output could instead be something a lot more in the vein of
what we see with recipe parsing. Perhaps one line per
BB_NUMBER_TREADS (N), maybe something like:
Task 2300/4600 [#################### ]
0: linux-yocto: do_compile
1: matchbox: do_fetch
...
N: dbus: do_configure
It would of course update the current lines and not scroll. Most of
the time, this would be plenty information. Upon failure we stop
updating the "UI" and print something like:
ERROR: An unhandled exception occured while processing
linux-yocto: do_fetch
Exception: No such file or directory.
Run with -D for a more detailed error report or consult the
appropriate log file:
$(pwd)/tmp/work/$machine/linux-yocto-$HASH-$HASH \
/temp/log.do_fetch.$PID
Or something along those lines.
Thanks for collecting these Scott, great idea!
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel