10292 2016-09-16 23:03:00 +0000 Suggested addition to complete the description of 'bitbake -e' 2016-09-22 23:02:21 +0000 1 1 9 Documentation Reference handbook 2.2 x86 Multiple RESOLVED FIXED 22 Sept 2016: RESOLVED Medium normal 2.2 M4 1 ulfalizer srifenbark bluelightning poky.doc.watcher poky.watcher srifenbark --- --- Done (doc changes complete) oldest_to_newest 66270 0 ulfalizer 2016-09-16 23:03:00 +0000 Hello, 'bitbake -e' includes some other information in addition to variable values. I suggest adding the following to the end of '2.3.2. Viewing Variable Values' to complete the description: In addition to variable values, the following information is included in the output of 'bitbake -e' and 'bitbake -e <recipe>': * The output starts with a tree listing all configuration files and classes included globally, recursively listing the files they include or inherit in turn. Much of the behavior of the OpenEmbedded build system (including the behavior of the [normal recipe build tasks](http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#normal-recipe-build-tasks)) is implemented in [base.bbclass] and the classes it inherits, rather than being built into BitBake itself. * After the variable values, all functions are listed. For shell functions, variables referenced within the function body are expanded. If a function has been modified using overrides or override-style operators like "_append" and "_prepend", then the final assembled function body is shown. Cheers, Ulf 66436 1 srifenbark 2016-09-21 20:54:54 +0000 Ulf, See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values for the additional information. I did a bit of word-smithing to try and get as much active voice as I could. Thanks, Scott 66456 2 ulfalizer 2016-09-22 04:45:03 +0000 Looks good to me. I agree that active voice sounds a bit more natural. Just hadn't thought about it much until now. :) Cheers, Ulf 66528 3 srifenbark 2016-09-22 23:02:21 +0000 Ulf, Thanks. Active voice is a standard we try to strive for in technical writing. I think it stems from the content being "bone dry" in most cases :) haha. I am closing this bug. Thanks, Scott