| Summary: | Recipe logging mechanisms and best practices are not documented | ||
|---|---|---|---|
| Product: | [Documentation] Quick Start | Reporter: | Darren Hart <dvhart> |
| Component: | quick-start | Assignee: | Scott Rifenbark <srifenbark> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | dvhart, poky.doc.watcher, poky.watcher, sgw |
| Version: | unspecified | ||
| Target Milestone: | 1.1 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| URL: | d67201e6003ad2be8ebcd9aaca9c8212cf8ca007 | ||
| Whiteboard: | 31-aug-2011: resolved/fixed | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
Hrm, for consistency, according to bitbake/lib/__init__.py, bb.fatal maps to CRITICAL logging level, and prints ERROR. bash should do the same, so:
if [ fatal_error ]; then
echo "FATAL: fatal_error detected"
fi
should become:
if [ fatal_error ]; then
echo "ERROR: fatal_error detected"
fi
This type of information (for now) can reside in the develop sections of the upcoming Yocto Project Development Manual. While tied to emulation, the actual steps the user would take to do this would be part of the development process. So, these types of tips and tricks are good for that. This will be documented in the YPDM. I set the component to "other". So I'm running into several issues trying to nail down proper usage. Some of it user error, some of it is just broken. I'm sorting it out and will post a more concise summary of usage. For now though, a couple updates:
Note that "plain" goes to the console, so the above is too chatty. The goal is to have informative logs and a mostly silent console. For status messages in the logs, use the debug level.
A better python example would be:
python do_listtasks() {
bb.debug(2, "Starting to do figure out the task list")
if noteworthy_condition:
bb.note("There are 47 tasks, felt you should know!")
bb.debug(2, "got to point xyz")
if warning_trigger:
bb.warn("detected warning_trigger, this may cause problems later")
if recoverable_error:
bb.error("hit recoverable_error, you really need to fix this!")
if fatal_error:
bb.fatal("fatal_error detected, unable to print the task list")
bb.plain("The tasks present are abc")
bb.debug(2, "Finished figuring out the tasklist")
}
As for echo, it only goes to the log. There are oenote() oedebug() functions which provide a similar interface (instead of "echo"), but I've having trouble with oedebug() at the moment...
These are now documented in the source of meta/classes/logging.bbclass. I have added a new section in the YP dev manual that covers this information. I added the commit ID in the URL above. I forgot to put YOCTO #1001 in the commit for the fix on this bug. |
As part of our howto write recipes, we should encourage users to make proper use of the existing output mechanisms to aid in debugging and for reasonably informative task logging. For python functions, bitbake offers the following loglevels, in order of severity: bb.fatal bb.error bb.warn bb.note bb.plain bb.debug Use them as follows: python do_my_function() { bb.plain("Running do_my_function()") if exceptional_condition: bb.note("Hit exception_condition") bb.debug("got to point xyz") if warning_trigger: bb.warn("detected warning_trigger, this may cause problems later") if recoverable_error: bb.error("hit recoverable_error, correcting") if fatal_error: bb.fatal("fatal_error detected") bb.plain("Completed do_my_function") } For bash functions, use "echo" and prepend the string with the appropriate loglevel followed by a colon: do_my_function() { echo "Running do_my_function()" if [ exceptional_condition ]; then echo "NOTE: it exception_condition" fi echo "DEBUG: got to point xyz" if [ warning_trigger ]; then echo "WARNING: detected warning_trigger, this may cause problems later" fi if [ recoverable_error ]; then echo "ERROR: hit recoverable_error, correcting" fi if [ fatal_error ]; then echo "FATAL: fatal_error detected" fi echo "Completed do_my_function" }