sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

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>
This commit is contained in:
Scott Rifenbark 2014-06-11 10:46:05 +03:00 committed by Richard Purdie
parent 50af2dc537
commit a19f575cde
8 changed files with 88 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
documentation/dev-manual/dev-manual-common-tasks.xml
View File

@ -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

12
documentation/dev-manual/dev-manual-model.xml
View File

@ -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>

2
documentation/kernel-dev/kernel-dev-common.xml
View File

@ -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.

6
documentation/ref-manual/ref-classes.xml
View File

@ -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>

5
documentation/ref-manual/ref-structure.xml
View File

@ -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>

2
documentation/ref-manual/ref-variables.xml
View File

@ -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>

4
documentation/ref-manual/technical-details.xml
View File

@ -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.

35
documentation/ref-manual/usingpoky.xml
View File

@ -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>