From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: bitbake-dev <bitbake-dev@lists.berlios.de>
Cc: openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Bitbake task logging
Date: Sat, 01 Jan 2011 18:14:37 +0000 [thread overview]
Message-ID: <1293905677.17519.16909.camel@rex> (raw)
I've been looking at the changes in bitbake master and those in Poky.
Both are trying to improve the logging situation but I think we need to
discuss/agree what we're trying to achieve.
I'm trying to think about this from the user point of view. What does a
user need and expect from bitbake to be as easy to use as possible and
figure out whats going on. New users often ask "what is it doing? what
functions does it run?" and its hard to work out for someone new to it.
Some of the list below works today, some is close, some doesn't but I'm
looking to work out what the experience should be, then we can figure
out how to get there technically.
The things I think we need are:
a) A logfile per task.
b) All output from the task should end up in the logfile, copied or
otherwise, be it bitbake LogRecords, output to stdout, stderr or
anything else.
c) The logfile should be able to include different output from that
shown in the UI console. For example, I think "note" output in the
logfiles might be useful all the time, I'm wondering if it ever is
useful on the UI console. Turning off "note" for the console but keeping
it and maybe using it more in tasks could be useful. For example,
exec_func() could note which functions are being executed and I can
imagine a user finding that very useful in the log file for debugging
(which is when a user would look there). Debug output is probably too
verbose even for the log files in general but I'm open to persuasion one
way or another on that.
d) Handling of the default stdout is a tricky one. I think it makes most
sense to redirect this to the logfile always, for both python and shell
tasks. For bitbake itself, nothing in bitbake should be putting output
there though IMO. This makes sense since we can control stdout from
within bitbake itself but from within generic tasks we cannot make
guarantees. Python tasks may make os.system calls, or run binaries and
it would make sense for stdout to just work for these rather than need
special handling or wrapper functions especially for log handling (they
could be a good idea for other reasons).
e) I'm not 100% on this yet but I'm wondering if we should scrap
stdout/stderr output to the UI console in debug mode, just make it clear
where the output went on the console? If you ever have two tasks running
the output is unreadable anyway.
Thoughts/Comments/Suggestions?
Cheers,
Richard
next reply other threads:[~2011-01-01 18:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-01 18:14 Richard Purdie [this message]
2011-01-02 7:16 ` Bitbake task logging Esben Haabendal
2011-01-12 10:27 ` Aeschbacher, Fabrice
2011-01-12 12:35 ` Frans Meulenbroeks
2011-01-04 15:30 ` Chris Larson
2011-01-04 18:02 ` [Bitbake-dev] " Richard Purdie
2011-01-04 21:40 ` Yury Bushmelev
2011-01-05 0:45 ` Richard Purdie
2011-01-05 18:30 ` [Bitbake-dev] " Chris Larson
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=1293905677.17519.16909.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-dev@lists.berlios.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.