From 4a3a747c77dfb180720b5bc41a41738d96b2db54 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 28 Mar 2014 15:46:58 -0600 Subject: ref-manual: Edits to the "Using" chapter. Along with some minor things I did the following: * Added a brief explanation and reference to the reporting error tool. It seemed like a good chapter to include it. I put it in the debugging section. * I added a pointer to the BitBake manual right at the top of a section that had many usages of the bitbake command. (From yocto-docs rev: 9317433bc715e9fdac2fc629ed659ac926d67531) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/usingpoky.xml | 38 +++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 8 deletions(-) (limited to 'documentation/ref-manual/usingpoky.xml') diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml index 5799b2b973..a8a6f3b92a 100644 --- a/documentation/ref-manual/usingpoky.xml +++ b/documentation/ref-manual/usingpoky.xml @@ -48,8 +48,6 @@ A common practice is to use a different Build Directory for different targets. For example, ~/build/x86 for a qemux86 target, and ~/build/arm for a qemuarm target. - See the "&OE_INIT_FILE;" - section for more information on this script. @@ -111,16 +109,30 @@ Debugging Build Failures - The exact method for debugging build failures depends on the nature of the - problem and on the system's area from which the bug originates. + The exact method for debugging build failures depends on the nature of + the problem and on the system's area from which the bug originates. Standard debugging practices such as comparison against the last - known working version with examination of the changes and the re-application of steps - to identify the one causing the problem are + known working version with examination of the changes and the + re-application of steps to identify the one causing the problem are valid for the Yocto Project just as they are for any other system. Even though it is impossible to detail every possible potential failure, this section provides some general tips to aid in debugging. + + A useful feature for debugging is the error reporting tool. + Configuring the Yocto Project to use this tool causes the + OpenEmbedded build system to produce error reporting commands as + part of the console output. + You can enter the commands after the build completes + to log error information + into a common database, that can help you figure out what might be + going wrong. + For information on how to enable and use this feature, see the + "Using the Error Reporting Tool" + section in the Yocto Project Development Manual. + + For discussions on debugging, see the "Debugging With the GNU Project Debugger (GDB) Remotely" @@ -129,6 +141,14 @@ sections in the Yocto Project Development Manual. + + The remainder of this section presents many examples of the + bitbake command. + You can learn about BitBake by reading the + BitBake User Manual. + + +
Task Failures @@ -137,7 +157,9 @@ For example, the compile task for the QEMU minimal image for the x86 machine (qemux86) might be tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830. - To see what BitBake runs to generate that log, look at the corresponding + To see what + BitBake + runs to generate that log, look at the corresponding run.do_taskname.pid file located in the same directory. @@ -285,7 +307,7 @@ This command form does not check for dependencies. Consequently, you should use it - only when you know dependencies already exist. + only when you know existing dependencies have been met. You can also specify fragments of the filename. In this case, BitBake checks for a unique match. -- cgit v1.2.3-54-g00ecf