[oe] [PATCHv2 6/7] recipes: Fix documentation errors
Chase Maupin
chasemaupin03 at gmail.com
Wed May 26 13:09:34 UTC 2010
* Fixed up typos and other errors in the documentation.
Signed-off-by: Chase Maupin <chase.maupin at ti.com>
---
docs/usermanual/chapters/recipes.xml | 66 +++++++++++++++++-----------------
1 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
index 6a574d8..0bbc05f 100644
--- a/docs/usermanual/chapters/recipes.xml
+++ b/docs/usermanual/chapters/recipes.xml
@@ -154,7 +154,7 @@ VAR2 = "The version is ${PV}"</screen></para>
<para>The following example:<screen>VAR1 ?= "New value"</screen>will
set <emphasis role="bold">VAR1</emphasis> to <emphasis>"New
- value"</emphasis> if its currently empty. However if it was already
+ value"</emphasis> if it is currently empty. However if it was already
set it would be unchanged. In the following <emphasis
role="bold">VAR1</emphasis> is left with the value
<emphasis>"Original value"</emphasis>:<screen>VAR1 = "Original value"
@@ -290,7 +290,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
</variablelist>
<para>For a detailed description of the syntax for the bitbake recipe
- files you should refer to the bitbake use manual.</para>
+ files you should refer to the bitbake user manual.</para>
</section>
<section id="recipes_versioning" xreflabel="versioning">
@@ -418,7 +418,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
<section id="recipes_variables" xreflabel="variables">
<title>Variables</title>
- <para>One of the most confusing part of bitbake recipes for new users is
+ <para>One of the most confusing parts of bitbake recipes for new users is
the large amount of variables that appear to be available to change and/or
control the behaviour of some aspect of the recipe. Some variables, such
as those derived from the file name are reasonably obvious, others are not
@@ -503,7 +503,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
<para>Practically all recipes start with a header section which describes
various aspects of the package that is being built. This information is
typically used directly by the package format (such as ipkg or deb) as
- its meta data used to describe the package.</para>
+ meta data used to describe the package.</para>
<para>Variables used in the header include:</para>
@@ -536,7 +536,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
<term>SECTION</term>
<listitem>
- <para>The section is used to categorise the application into a
+ <para>The section is used to categorize the application into a
specific group. Often used by GUI based installers to help users
when searching for software.</para>
@@ -625,7 +625,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
file or a compressed archive file, such as .tar.gz or .zip, then the files
will be uncompressed and extracted from the archive automatically.</para>
- <para>Archive files will be extracted from with the working directory,
+ <para>Archive files will be extracted from within the working directory,
<emphasis role="bold">${WORKDIR}</emphasis> and plain files will be copied
into the same directory. Patches will be applied from within the unpacked
source directory, <emphasis role="bold">${S}</emphasis>. (Details on these
@@ -722,7 +722,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
<listitem>
<para>This is where patches are applied and where the program is
- expected to be compiled in.</para>
+ expected to be compiled.</para>
</listitem>
</varlistentry>
@@ -790,7 +790,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
file://watchquagga.default"</screen>The recipe has two init files
and two configuration files, which are not patches, but are actually
files that it wants to include in the generated packages. Bitbake will
- copy these files into the work directory. So to access them during the
+ copy these files into the working directory. So to access them during the
install task we refer to them via the <emphasis
role="bold">WORKDIR</emphasis> variable:<screen>do_install () {
# Install init script and default settings
@@ -809,7 +809,7 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>
directory called <emphasis
role="bold"><packagename>-<version></emphasis> in the
<emphasis role="bold">WORKDIR</emphasis> directory. This is the
- directory in which it will change into before patching, compiling and
+ directory it will change into before patching, compiling and
installing the package.</para>
<para>For example, we have a package called <emphasis
@@ -875,7 +875,7 @@ S = "${WORKDIR}/widgets"</screen></para>
<title>Staging directories</title>
<para>Staging is used to make libraries, headers and binaries available
- for the build of one recipe for use by another recipe. Building a
+ from the build of one recipe for use by another recipe. Building a
library for example requires that packages be created containing the
libraries and headers for development on the target as well as making
them available on the host for building other packages that need the
@@ -1339,7 +1339,7 @@ $</screen>This shows us that the helloworld program is for an SH
programs that you need to run a configure script for, passing various
parameters, and then make. To make these work when cross-compiling you
need to provides a lot of variables to the configure script. But all the
- hard work as already been done for you. There's an <xref
+ hard work has already been done for you. There's an <xref
linkend="autotools_class" /> which takes care of most of the complexity
of building an autotools based package.</para>
@@ -1387,7 +1387,7 @@ inherit autotools</screen></para>
</listitem>
<listitem>
- <para>Make modifications to prevent the configure script from tying
+ <para>Make modifications to prevent the configure script from trying
to compile and run programs - any programs it compiles will be for
the target and not the host and so cannot be run.</para>
</listitem>
@@ -1519,7 +1519,7 @@ inherit autotools</screen></para>
role="bold">.so</emphasis>, <emphasis role="bold">.a</emphasis> and
associated libtool <emphasis role="bold">.la</emphasis> libraries.
It will determine the appropriate libraries to install and take care
- of any modifications that may be require for <emphasis
+ of any modifications that may be required for <emphasis
role="bold">.la</emphasis> files.</para>
<para>This function supports the following options:</para>
@@ -1839,7 +1839,7 @@ NOTE: package helloworld-0.1-r0: task do_package_write: completed</screen>We
<section>
<title>Default packages and files</title>
- <para>The defaults package settings are defined in <emphasis
+ <para>The default package settings are defined in <emphasis
role="bold">conf/bitbake.conf</emphasis> and are suitable for a lot of
recipes without any changes. The following list shows the default values
for the packaging related variables:</para>
@@ -2363,7 +2363,7 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
<para>Often a certain pattern is followed in more than one recipe, or
maybe some complex python based functionality is required to achieve the
desired end result. This is achieved through the use of classes, which can
- be found in the classes subdirectory at the top-level of on OE
+ be found in the classes subdirectory at the top-level of an OE
checkout.</para>
<para>Being aware of the available classes and understanding their
@@ -2390,7 +2390,7 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
<para>A class is used via the inherit method. The following is an example
for the <emphasis>curl</emphasis> recipe showing that it uses three
classes:<screen>inherit autotools pkgconfig binconfig</screen>In this case
- it is utilising the services of three separate classes:</para>
+ it is utilizing the services of three separate classes:</para>
<variablelist>
<varlistentry>
@@ -2443,7 +2443,7 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
libraries, available for use by other recipes. This is different to
installing because installing is about making things available for
packaging and then eventually for use on the target device. Staging on the
- other hand is about making things available on the host system for use by
+ other hand is about making things available on the host system for use in
building later applications.</para>
<para>Taking bzip2 as an example you can see that it stages a header file
@@ -2463,7 +2463,7 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
<term>STAGING_INCDIR</term>
<listitem>
- <para>The directory into which staged headers files should be
+ <para>The directory into which staged header files should be
installed. This is the equivalent of the standard <emphasis
role="bold">/usr/include</emphasis> directory.</para>
</listitem>
@@ -2531,7 +2531,7 @@ EXTRA_OECONF = "--disable-ldap \
script of the package. In the gnupg case it needs to be told where
the bzip2 headers and libraries are, and this is done via the
<emphasis>--with-bzip2</emphasis> option. In this case it points to
- the directory which include the lib and include subdirectories.
+ the directory which includes the lib and include subdirectories.
Since OE doesn't define a variable for one level above the include
and lib directories <emphasis role="bold">..</emphasis> is used to
indicate one directory up. Without this, gnupg would search the host
@@ -2717,9 +2717,9 @@ pkg_postinst_${PN}-rdisc6 () {
<listitem>
<para>This class is used when installing and/or removing qpf fonts.
- It register scripts to update the font paths and font cache
+ It registers scripts to update the font paths and font cache
information to ensure that the font information is kept up to date
- as fonts and installed and removed.</para>
+ as fonts are installed and removed.</para>
</listitem>
</varlistentry>
@@ -2972,7 +2972,7 @@ fi</screen></para>
</listitem>
<listitem>
- <para>How do handle incrementally creating patches</para>
+ <para>How to handle incrementally creating patches</para>
</listitem>
<listitem>
@@ -3025,7 +3025,7 @@ fi</screen></para>
</orderedlist>
<para>This results in the packaging system, such as ipkg, considering
- the released version to be older then the rc version.</para>
+ the released version to be older than the rc version.</para>
<para>In OpenEmbedded the correct naming of pre and rc versions is to use
the previous version number followed by a + followed by the new version
@@ -3138,7 +3138,7 @@ do_configure() {
role="bold">0_9_0</emphasis>.</para>
<para>Some of the more common python code in use in existing recipes is
- shown in the following table:</para>
+ shown in the following list:</para>
<variablelist>
<varlistentry>
@@ -3389,7 +3389,7 @@ $</screen>then we would expect it to select version
(since all of the existing versions have a preference of 0). Note that you
can still call bitbake directly on the recipe:<screen>bitbake -b recipes/procps/procps_4.0.0.bb</screen>This
enables you to test, and fix the package manually without having bitbake
- automatically select normally.</para>
+ automatically select it normally.</para>
<para>By using this feature in conjunction with overrides you can also
disable (or select) specific versions based on the override. The following
@@ -3418,7 +3418,7 @@ $</screen>then we would expect it to select version
</listitem>
<listitem>
- <para>samlpe/standard script?</para>
+ <para>sample/standard script?</para>
</listitem>
<listitem>
@@ -3445,13 +3445,13 @@ $</screen>then we would expect it to select version
from other packages.</para>
<para>The most common reason for alternatives is to reduce the size of the
- binaries. But cutting down on features, built in help and error messages
+ binaries. By cutting down on features, built in help, error messages
and combining multiple binaries into one large binary it's possible to
save considerable space. Often users are not expected to use the commands
interactively in embedded appliances and therefore these changes have no
visible effect to the user. In some situations users may have interactive
access, or they may be more advanced users who want shell access on
- appliances that normal don't provide it, and in these cases they should be
+ appliances that normally don't provide it, and in these cases they should be
able to install the full functional version if they desire.</para>
<section>
@@ -3478,7 +3478,7 @@ update-alternatives: Linking //usr/bin/find to find.findutils
update-alternatives: Linking //usr/bin/xargs to xargs.findutils</screen></para>
<para>Then we see that the standard version of find changes to the full
- featured implement ion:<screen>root at titan:~$ find --version
+ featured implementation:<screen>root at titan:~$ find --version
find --version
GNU find version 4.2.29
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION
@@ -3576,7 +3576,7 @@ which find
</listitem>
<listitem>
- <para>even if your distro don't use /var in tmpfs, others do</para>
+ <para>even if your distro doesn't use /var in tmpfs, others do</para>
</listitem>
<listitem>
@@ -3588,7 +3588,7 @@ which find
<section>
<title>Logging and log files</title>
- <para>As a consequence of the non-volatile and/or small capacity of the
+ <para>As a consequence of the volatile and/or small capacity of the
<emphasis role="bold">/var</emphasis> file system some distributions
choose methods of logging other than writing to a file. The most typical
is the use of an in-memory circular log buffer which can be read using
@@ -3616,7 +3616,7 @@ which find
</listitem>
<listitem>
- <para>Don't include any <command>/var</command> directories, file or
+ <para>Don't include any <command>/var</command> directories, files or
symlinks in packages. They would be lost on a reboot and so should
not be included in packages.</para>
</listitem>
@@ -3643,7 +3643,7 @@ which find
<itemizedlist>
<listitem>
- <para>about optimisation</para>
+ <para>about optimization</para>
</listitem>
<listitem>
--
1.6.0.4
More information about the Openembedded-devel
mailing list