dev-manual, kernel-dev, ref-manual: Updated task name usage.

There was inconsistency on how we refer to a task name throughout
the YP manual set.  The proper way is "do_<taskname>".  Some
occurrences did not include the "do_" prefix.  These have been
fixed.

(From yocto-docs rev: b32821bb0d3e6de7bca68b25c662a023526a10c4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

8 files changed, 88 insertions, 57 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 0c66a7c232..3922c8f0f4 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3548,7 +3548,7 @@
 
             <para>
                 As part of the kernel build process, the
-                <filename>kernel_configcheck</filename> task runs.
+                <filename>do_kernel_configcheck</filename> task runs.
                 This task validates the kernel configuration by checking the final
                 <filename>.config</filename> file against the input files.
                 During the check, the task produces warning messages for the following
@@ -3565,8 +3565,9 @@
                         In other words, the option does not appear anywhere.</para></listitem>
                 </itemizedlist>
                 <note>
-                    The <filename>kernel_configcheck</filename> task can also optionally report
-                    if an option is overridden during processing.
+                    The <filename>do_kernel_configcheck</filename> task can
+                    also optionally report if an option is overridden during
+                    processing.
                 </note>
             </para>
 
@@ -3580,29 +3581,45 @@
             <para>
                 To streamline the configuration, do the following:
                 <orderedlist>
-                    <listitem><para>Start with a full configuration that you know
-                        works - it builds and boots successfully.
-                        This configuration file will be your baseline.</para></listitem>
-                    <listitem><para>Separately run the <filename>configme</filename> and
-                        <filename>kernel_configcheck</filename> tasks.</para></listitem>
+                    <listitem><para>Start with a full configuration that you
+                        know works - it builds and boots successfully.
+                        This configuration file will be your baseline.
+                        </para></listitem>
+                    <listitem><para>Separately run the
+                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configcheck</filename> tasks.
+                        </para></listitem>
                     <listitem><para>Take the resulting list of files from the
-                        <filename>kernel_configcheck</filename> task warnings and do the following:
+                        <filename>do_kernel_configcheck</filename> task
+                        warnings and do the following:
                         <itemizedlist>
-                            <listitem><para>Drop values that are redefined in the fragment but do not
-                                change the final <filename>.config</filename> file.</para></listitem>
-                            <listitem><para>Analyze and potentially drop values from the
-                                <filename>.config</filename> file that override required
-                                configurations.</para></listitem>
-                            <listitem><para>Analyze and potentially remove non-board specific options.
+                            <listitem><para>
+                                Drop values that are redefined in the fragment
+                                but do not change the final
+                                <filename>.config</filename> file.
+                                </para></listitem>
+                            <listitem><para>
+                                Analyze and potentially drop values from the
+                                <filename>.config</filename> file that override
+                                required configurations.
+                                </para></listitem>
+                            <listitem><para>
+                                Analyze and potentially remove non-board
+                                specific options.
+                                </para></listitem>
+                            <listitem><para>
+                                Remove repeated and invalid options.
                                 </para></listitem>
-                            <listitem><para>Remove repeated and invalid options.</para></listitem>
                         </itemizedlist></para></listitem>
-                    <listitem><para>After you have worked through the output of the kernel configuration
-                        audit, you can re-run the <filename>configme</filename>
-                        and <filename>kernel_configcheck</filename> tasks to see the results of your
-                        changes.
-                        If you have more issues, you can deal with them as described in the
-                        previous step.</para></listitem>
+                    <listitem><para>
+                        After you have worked through the output of the kernel
+                        configuration audit, you can re-run the
+                        <filename>do_configme</filename> and
+                        <filename>do_kernel_configcheck</filename> tasks to
+                        see the results of your changes.
+                        If you have more issues, you can deal with them as
+                        described in the previous step.
+                        </para></listitem>
                 </orderedlist>
             </para>
 
@@ -5149,14 +5166,18 @@ Gateways via their Web Interfaces</ulink>"</emphasis>
         <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
             <title>Handling a Package Name Alias</title>
             <para>
-                Sometimes a package name you are using might exist under an alias or as a similarly named
-                package in a different distribution.
-                The OpenEmbedded build system implements a <filename>distro_check</filename>
+                Sometimes a package name you are using might exist under
+                an alias or as a similarly named package in a different
+                distribution.
+                The OpenEmbedded build system implements a
+                <filename>do_distro_check</filename>
                 task that automatically connects to major distributions
                 and checks for these situations.
-                If the package exists under a different name in a different distribution, you get a
-                <filename>distro_check</filename> mismatch.
-                You can resolve this problem by defining a per-distro recipe name alias using the
+                If the package exists under a different name in a different
+                distribution, you get a <filename>distro_check</filename>
+                mismatch.
+                You can resolve this problem by defining a per-distro recipe
+                name alias using the
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</ulink></filename>
                 variable.
             </para>
@@ -6922,7 +6943,7 @@ Gateways via their Web Interfaces</ulink>"</emphasis>
                             Returns "True" if <filename>pkg</filename> is in the
                             installed package list of the image, which is based
                             on the manifest file that is generated during the
-                            <filename>do.rootfs</filename> task.
+                            <filename>do_rootfs</filename> task.
                             </para></listitem>
                         <listitem><para><emphasis><filename>hasFeature(feature)</filename>:</emphasis>
                             Returns "True" if the feature is in
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index 4fd4c4e1e3..59e19a2bae 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -1773,8 +1773,10 @@
                     Make your changes in the temporary source code to the files you added
                     to the patch.</para></listitem>
                 <listitem><para><emphasis>Test Your Changes:</emphasis>
-                    Once you have modified the source code, the easiest way to test your changes
-                    is by calling the <filename>compile</filename> task as shown in the following example:
+                    Once you have modified the source code, the easiest way to
+                    your changes is by calling the
+                    <filename>do_compile</filename> task as shown in the
+                    following example:
                     <literallayout class='monospaced'>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
@@ -1870,8 +1872,10 @@
                 <listitem><para><emphasis>Edit the Files:</emphasis>
                     Make your changes to the temporary source code.</para></listitem>
                 <listitem><para><emphasis>Test Your Changes:</emphasis>
-                    Once you have modified the source code, the easiest way to test your changes
-                    is by calling the <filename>compile</filename> task as shown in the following example:
+                    Once you have modified the source code, the easiest way
+                    to test your changes is by calling the
+                    <filename>do_compile</filename> task as shown in the
+                    following example:
                     <literallayout class='monospaced'>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index b3f4c438d7..31ffa5c83c 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -445,7 +445,7 @@
                 You can edit the sources as you would any other Linux source
                 tree.
                 However, keep in mind that you will lose changes if you
-                trigger the <filename>fetch</filename> task for the recipe.
+                trigger the <filename>do_fetch</filename> task for the recipe.
                 You can avoid triggering this task by not issuing BitBake's
                 <filename>cleanall</filename>, <filename>cleansstate</filename>,
                 or forced <filename>fetch</filename> commands.
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index 3653edd916..e7e9942b3b 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -569,7 +569,7 @@
 
     <para>
         The <filename>devshell</filename> class adds the
-        <filename>devshell</filename> task.
+        <filename>do_devshell</filename> task.
         Distribution policy dictates whether to include this class.
         See the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
@@ -606,8 +606,8 @@
         provides for automatic checking for upstream recipe updates.
         The class creates a comma-separated value (CSV) spreadsheet that
         contains information about the recipes.
-        The information provides the <filename>distrodata</filename> and
-        <filename>distro_check</filename> tasks, which do upstream checking
+        The information provides the <filename>do_distrodata</filename> and
+        <filename>do_distro_check</filename> tasks, which do upstream checking
         and also verify if a package is used in multiple major distributions.
     </para>
 
diff --git a/documentation/ref-manual/ref-structure.xml b/documentation/ref-manual/ref-structure.xml
index c849dbda33..389e75ad97 100644
--- a/documentation/ref-manual/ref-structure.xml
+++ b/documentation/ref-manual/ref-structure.xml
@@ -800,8 +800,9 @@
         <para>
             This directory contains general logs that are not otherwise placed using the
             package's <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
-            Examples of logs are the output from the <filename>check_pkg</filename> or
-            <filename>distro_check</filename> tasks.
+            Examples of logs are the output from the
+            <filename>do_check_pkg</filename> or
+            <filename>do_distro_check</filename> tasks.
             Running a build does not necessarily mean this directory is created.
         </para>
     </section>
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 518dc2e3f6..6fae9f735e 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7796,7 +7796,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         Instead, files should be installed to
                         <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
                         within your recipe's
-                        <link linkend='ref-tasks-install'><filename>install</filename></link>
+                        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
                         task and then the OpenEmbedded build system will
                         stage a subset of those files into the sysroot.
                     </note>
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 319795f672..ee08831c42 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -442,11 +442,11 @@
             works on a per-task basis rather than a per-recipe basis.
             You might wonder why using a per-task basis is preferred over a per-recipe basis.
             To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
-            In this case,
+            In this case, the
             <link linkend='ref-tasks-install'><filename>do_install</filename></link>
             and
             <link linkend='ref-tasks-package'><filename>do_package</filename></link>
-            outputs are still valid.
+            task outputs are still valid.
             However, with a per-recipe approach, the build would not include the
             <filename>.deb</filename> files.
             Consequently, you would have to invalidate the whole build and rerun it.
diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml
index 3748ac21bb..3c82d8185b 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -173,17 +173,20 @@
 
         <para>
             Any given package consists of a set of tasks.
-            The standard BitBake behavior in most cases is: <filename>fetch</filename>,
-            <filename>unpack</filename>,
-            <filename>patch</filename>, <filename>configure</filename>,
-            <filename>compile</filename>, <filename>install</filename>, <filename>package</filename>,
-            <filename>package_write</filename>, and <filename>build</filename>.
-            The default task is <filename>build</filename> and any tasks on which it depends
-            build first.
-            Some tasks, such as <filename>devshell</filename>, are not part of the
-            default build chain.
-            If you wish to run a task that is not part of the default build chain, you can use the
-            <filename>-c</filename> option in BitBake.
+            The standard BitBake behavior in most cases is:
+            <filename>do_fetch</filename>,
+            <filename>do_unpack</filename>,
+            <filename>do_patch</filename>, <filename>do_configure</filename>,
+            <filename>do_compile</filename>, <filename>do_install</filename>,
+            <filename>do_package</filename>,
+            <filename>do_package_write</filename>, and
+            <filename>do_build</filename>.
+            The default task is <filename>do_build</filename> and any tasks
+            on which it depends build first.
+            Some tasks, such as <filename>do_devshell</filename>, are not part
+            of the default build chain.
+            If you wish to run a task that is not part of the default build
+            chain, you can use the <filename>-c</filename> option in BitBake.
             Here is an example:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
@@ -210,14 +213,16 @@
         <para>
             This sequence first builds and then recompiles
             <filename>matchbox-desktop</filename>.
-            The last command reruns all tasks (basically the packaging tasks) after the compile.
-            BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
-            understands that the other tasks also need to be run again.
+            The last command reruns all tasks (basically the packaging tasks)
+            after the compile.
+            BitBake recognizes that the <filename>do_compile</filename>
+            task was rerun and therefore understands that the other tasks
+            also need to be run again.
         </para>
 
         <para>
             You can view a list of tasks in a given package by running the
-            <filename>listtasks</filename> task as follows:
+            <filename>do_listtasks</filename> task as follows:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c listtasks
             </literallayout>