aboutsummaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2014-06-11 10:46:05 +0300
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-06-18 10:30:48 +0100
commita19f575cde39917e4632dab1e813d84402f95937 (patch)
tree856fc2d185f4eef07af46a14f1e659285793e42b /documentation/dev-manual
parent50af2dc53778c712c21538f82025427d558cba63 (diff)
downloadopenembedded-core-contrib-a19f575cde39917e4632dab1e813d84402f95937.tar.gz
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>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.xml79
-rw-r--r--documentation/dev-manual/dev-manual-model.xml12
2 files changed, 58 insertions, 33 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>