Patchwork [bitbake-devel] usermanual: Improve task dependency documentation to match reality

login
register
mail settings
Submitter Richard Purdie
Date July 2, 2012, 3:36 p.m.
Message ID <1341243368.23146.256.camel@ted>
Download mbox | patch
Permalink /patch/30981/
State New
Headers show

Comments

Richard Purdie - July 2, 2012, 3:36 p.m.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---

Patch

diff --git a/bitbake/doc/manual/usermanual.xml b/bitbake/doc/manual/usermanual.xml
index f894dfc..81b301a 100644
--- a/bitbake/doc/manual/usermanual.xml
+++ b/bitbake/doc/manual/usermanual.xml
@@ -228,7 +228,7 @@  addtask printdate before do_build</screen></para>
                 <para>'nostamp' - don't generate a stamp file for a task. This means the task is always rexecuted.</para>
                 <para>'fakeroot' - this task needs to be run in a fakeroot environment, obtained by adding the variables in FAKEROOTENV to the environment.</para>
                 <para>'umask' - the umask to run the task under.</para>
-                <para> For the 'deptask', 'rdeptask', 'recdeptask' and 'recrdeptask' flags please see the dependencies section.</para>
+                <para> For the 'deptask', 'rdeptask', 'depends', 'rdepends' and 'recrdeptask' flags please see the dependencies section.</para>
             </section>
 
             <section>
@@ -308,37 +308,35 @@  SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
         </section>
         <section>
             <title>Dependency handling</title>
-            <para>BitBake 1.7.x onwards works with the metadata at the task level since this is optimal when dealing with multiple threads of execution. A robust method of specifing task dependencies is therefore needed. </para>
+            <para>BitBake handles dependencies at the task level since to allow for efficient operation with multiple processed executing in parallel. A robust method of specifying task dependencies is therefore needed. </para>
             <section>
                 <title>Dependencies internal to the .bb file</title>
                 <para>Where the dependencies are internal to a given .bb file, the dependencies are handled by the previously detailed addtask directive.</para>
             </section>
 
             <section>
-                <title>DEPENDS</title>
+                <title>Build Dependencies</title>
                 <para>DEPENDS lists build time dependencies. The 'deptask' flag for tasks is used to signify the task of each item listed in DEPENDS which must have completed before that task can be executed.</para>
                 <para><screen>do_configure[deptask] = "do_populate_staging"</screen></para>
                 <para>means the do_populate_staging task of each item in DEPENDS must have completed before do_configure can execute.</para>
             </section>
             <section>
-                <title>RDEPENDS</title>
-                <para>RDEPENDS lists runtime dependencies. The 'rdeptask' flag for tasks is used to signify the task of each item listed in RDEPENDS which must have completed before that task can be executed.</para>
+                <title>Runtime Dependencies</title>
+                <para>The PACKAGES variable lists runtime packages and each of these can have RDEPENDS and RRECOMMENDS runtime dependencies. The 'rdeptask' flag for tasks is used to signify the task of each item runtime dependency which must have completed before that task can be executed.</para>
                 <para><screen>do_package_write[rdeptask] = "do_package"</screen></para>
                 <para>means the do_package task of each item in RDEPENDS must have completed before do_package_write can execute.</para>
             </section>
             <section>
-                <title>Recursive DEPENDS</title>
-                <para>These are specified with the 'recdeptask' flag and is used signify the task(s) of each DEPENDS which must have completed before that task can be executed. It applies recursively so the DEPENDS of each item in the original DEPENDS must be met and so on.</para>
-            </section>
-            <section>
-                <title>Recursive RDEPENDS</title>
-                <para>These are specified with the 'recrdeptask' flag and is used signify the task(s) of each RDEPENDS which must have completed before that task can be executed. It applies recursively so the RDEPENDS of each item in the original RDEPENDS must be met and so on. It also runs all DEPENDS first.</para>
+                <title>Recursive Dependencies</title>
+                <para>These are specified with the 'recrdeptask' flag which is used signify the task(s) of dependencies which must have completed before that task can be executed. It works by looking though the build and runtime dependencies of the current recipe as well as any inter-task dependencies the task has, then adding a dependency on the listed task. It will then recurse through the dependencies of those tasks and so on.</para>
+                <para>It may be desireable to recurse not just through the dependencies of those tasks but through the build and runtime dependencies of dependent tasks too. If that is the case, the taskname itself should be referenced in the task list, e.g. do_a[recrdeptask] = "do_a do_b".</para>
             </section>
             <section>
                 <title>Inter task</title>
-                <para>The 'depends' flag for tasks is a more generic form of which allows an interdependency on specific tasks rather than specifying the data in DEPENDS or RDEPENDS.</para>
+                <para>The 'depends' flag for tasks is a more generic form of which allows an interdependency on specific tasks rather than specifying the data in DEPENDS.</para>
                 <para><screen>do_patch[depends] = "quilt-native:do_populate_staging"</screen></para>
                 <para>means the do_populate_staging task of the target quilt-native must have completed before the do_patch can execute.</para>
+                <para>The 'rdepends' flag works in a similar way but takes targets in the runtime namespace instead of the build time dependency namespace.
             </section>
         </section>