aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorChase Maupin <chasemaupin03@gmail.com>2010-05-26 03:09:35 +0000
committerDenys Dmytriyenko <denis@denix.org>2010-05-28 12:00:39 -0400
commita291b86743282ab9d7ea6c5363d77500ce89e7a3 (patch)
tree9906b6a316e8eebc98d4eb7420081e5ca314c7f3 /docs
parent2f165113a3f2ae28c7177063170efd2d7627aa72 (diff)
downloadopenembedded-a291b86743282ab9d7ea6c5363d77500ce89e7a3.tar.gz
docs/usage: Fix documentation errors
* Fixed up typos and other errors in the documentation. Acked-by: Koen Kooi <k-kooi@ti.com> Signed-off-by: Chase Maupin <chase.maupin@ti.com> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Diffstat (limited to 'docs')
-rw-r--r--docs/usermanual/chapters/usage.xml64
1 files changed, 32 insertions, 32 deletions
diff --git a/docs/usermanual/chapters/usage.xml b/docs/usermanual/chapters/usage.xml
index 1563dc3eac..9703e3677b 100644
--- a/docs/usermanual/chapters/usage.xml
+++ b/docs/usermanual/chapters/usage.xml
@@ -9,11 +9,11 @@
what OpenEmbedded is all about, which is taking a lot of software and
creating something that you can run on another device. This involves
downloading some source code, compiling it, creating packages (like .deb
- or .rpm) and/or creating boot images that can written to flash on the
+ or .rpm) and/or creating boot images that can be written to flash on the
device. The difficulties of cross-compiling and the variety of devices
which can be supported lead to a lot more complexity in an OpenEmbedded
based distribution than you'd find in a typical desktop distribution
- (for which cross-compiling isn't needed).</para>
+ (where which cross-compiling isn't needed).</para>
<para>A major part of OpenEmbedded deals with compiling source code for
various projects. For each project this generally requires the same basic
@@ -67,7 +67,7 @@
<listitem>
<para>Tool chains (compiler, linker etc) are often difficult to
compile. Cross tool chains are even more difficult. Typically you'd go
- out and download a tool chain made by someone else - but not when your
+ out and download a tool chain made by someone else - but not when you're
using OE. In OE the entire toolchain is built as part of the process.
This may make things take longer initially and may make it more
difficult to get started but makes it easier to apply patches and test
@@ -123,7 +123,7 @@
helping you understand how to debug and develop within
OpenEmbedded.</para>
- <para>You'll also not a lot of reference to variables that define specific
+ <para>You'll also note a lot of references to variables that define specific
directories or change the behaviour of some part of the build process. You
should refer to <xref linkend="chapter_recipes" /> for full details on
these variables.</para>
@@ -160,7 +160,7 @@
<listitem>
<para>This directory contains distribution related files. A
distribution decides how various activities are handled in the final
- image, such as how networking configured, if usb devices will be
+ image, such as how networking is configured, if usb devices will be
supported, what packaging system is used, which libc is used
etc.</para>
</listitem>
@@ -193,8 +193,8 @@
<section id="usage_workspace" xreflabel="workspace">
<title>Work space</title>
- <para>Let's start out by taking a look at a typically working area. Note
- that this may not be exactly what see - there are a lot of options that
+ <para>Let's start out by taking a look at a typical working area. Note
+ that this may not be exactly what you see - there are a lot of options that
can effect exactly how things are done, but it gives us a pretty good idea
of whats going on. What we are looking at here is the tmp directory (as
specified by TMPDIR in your local.conf):<screen>$ <command>find</command> tmp -maxdepth 2 -type d
@@ -303,10 +303,10 @@ tmp/deploy/images</screen></para>
</varlistentry>
<varlistentry>
- <term>staging</term>
+ <term>sysroots</term>
<listitem>
- <para>Contains the staging area, which is used to stored natively
+ <para>Contains the staging area, which is used to store natively
compiled tools and and libraries and headers for the target that are
required for building other software.</para>
</listitem>
@@ -324,9 +324,9 @@ tmp/deploy/images</screen></para>
</variablelist>
<para>When people refer to the <emphasis>"tmp directory"</emphasis> this
- is the directory them are talking about.</para>
+ is the directory they are talking about.</para>
- <para>To perform a complete rebuild from script you would usually rename
+ <para>To perform a complete rebuild from scratch you would usually rename
or delete tmp and then restart your build. I recommend keeping one old
version of tmp around to use for comparison if something goes wrong with
your new build. For example:<screen>$ <command>rm</command> -fr tmp.OLD
@@ -339,7 +339,7 @@ $ <command>bitbake</command> bootstrap-image</screen></para>
<para>The work directory is where all source code is unpacked into,
where source is configured, compiled and packaged. In other words this
is where all the action happens. Each bitbake recipe will produce a
- corresponding sub directory in the work directory. The sub directory
+ corresponding subdirectory in the work directory. The subdirectory
name will contain the recipe name, version and the release number (as
defined by the PR variable within the recipe).</para>
@@ -348,9 +348,9 @@ $ <command>bitbake</command> bootstrap-image</screen></para>
tmp/work
tmp/work/busybox-1.2.1-r13
tmp/work/libice-1_1.0.3-r0
-tmp/work/arpwatch-2.1a15-r2</screen>You can see that the first three (of
+tmp/work/arpwatch-2.1a15-r2</screen>You can see the first three (of
several hundred) recipes here and they are for release 13 of busybox
- 1.2.1, release 0 or libice 1.1.0.3 and release 2 of arpwatch 2.1a15.
+ 1.2.1, release 0 of libice 1.1.0.3 and release 2 of arpwatch 2.1a15.
It's also possible that you may just have a sub directory for your
targets architecture and operating system in which case these
directories will be in that additional subdirectory, as shown
@@ -446,7 +446,7 @@ tmp/work/lzo-1.08-r14/image</screen></para>
install into <emphasis role="bold">${D}/usr/bin</emphasis> and
<emphasis role="bold">${D}/usr/lib</emphasis> instead. When
installed on the target the ${D} will be not be included so
- they'll end up in the correct place. You definitely don't wont
+ they'll end up in the correct place. You definitely don't want
files on your host system being replaced by cross-compiled
binaries for your target!</para>
</listitem>
@@ -544,14 +544,14 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0</screen></para>
packages. You probably need to start out by downloading the source code,
then unpacking the source code. Maybe you need to apply some patches for
some reason. Then you might run the configure script of the package,
- perhaps passing it some options to configure it to your liking. The you
- might run "make install" to install the software. If your actually going
+ perhaps passing it some options to configure it to your liking. Then you
+ might run "make install" to install the software. If you're actually going
to make some packages, such as .deb or .rpm, then you'd have additional
tasks you'd perform to make them.</para>
<para>You find that building things in OpenEmbedded works in a similar way
- there are a number of tasks that are executed in a predefined order for
- each recipe. Any many of the tasks correspond to those listed above like
+ each recipe. Many of the tasks correspond to those listed above like
<emphasis>"download the source"</emphasis>. In fact you've probably
already seen some of the names of these tasks - bitbake displays them as
they are processed:<screen>$ <command>bitbake</command> lzo
@@ -718,7 +718,7 @@ NOTE: build 200705041709: completed</screen><note>
<para>The <emphasis>configure</emphasis> task takes care of the
configuration of the package. Running a configure script
(<emphasis>"./configure &lt;options&gt;"</emphasis>) is probably the
- form of configuration that is most recognised but it's not the only
+ form of configuration that is most recognized but it's not the only
configuration system that exists.</para>
</listitem>
</varlistentry>
@@ -748,7 +748,7 @@ NOTE: build 200705041709: completed</screen><note>
<para>This is different from the <emphasis>install</emphasis> task
in that this is responsible for making available libraries and
headers for use during build on the development host. Therefore
- it's libraries which normal have to stage things while
+ it is libraries which normally have to stage things while
applications normally don't need to. The
<emphasis>install</emphasis> task on the other hand is making
files available for packaging and ultimately installation on the
@@ -762,7 +762,7 @@ NOTE: build 200705041709: completed</screen><note>
<listitem>
<para>The <emphasis>install</emphasis> task is responsible for
- actually installing everything. Now this needs to install the
+ actually installing everything. This needs to install the
software into the destination directory, <emphasis
role="bold">D</emphasis>. This directory won't actually be a part of
the final package though. In other words if you install something
@@ -782,7 +782,7 @@ NOTE: build 200705041709: completed</screen><note>
package. It moves the files for the destination directory, <emphasis
role="bold">${D}</emphasis>, that they were installed in into the
appropriate packages subdirectory. Usually there will be a main
- package a separate documentation (-doc), development (-dev) and
+ package, a separate documentation (-doc), development (-dev) and
debugging packages (-dbg) for example.</para>
</listitem>
</varlistentry>
@@ -808,11 +808,11 @@ NOTE: build 200705041709: completed</screen><note>
<emphasis>install</emphasis>. This is slightly confusing but any task
<emphasis>x</emphasis> is implemented via a function called
<emphasis>do_x</emphasis> in the class or recipe where it is defined.
- See places refer to the tasks via their name only and some with the
+ Some places refer to the tasks via their name only and some with the
<emphasis>do</emphasis> prefix.</para>
</note>
- <para>You will almost certainly notice tasks beyond these ones - there are
+ <para>You will almost certainly notice tasks beyond the ones above - there are
various methods available to insert additional tasks into the tasks
sequence. As an example the <emphasis
role="bold">insane.bbclass</emphasis>, which performs various QA checks,
@@ -822,7 +822,7 @@ NOTE: build 200705041709: completed</screen><note>
another new task called <emphasis>qa_staging</emphasis> between
<emphasis>populate_sysroot</emphasis> and <emphasis>build</emphasis>
tasks. The former validates the result of the
- <emphasis>configure</emphasis> task and the late the results of the
+ <emphasis>configure</emphasis> task and the later the results of the
<emphasis>populate_sysroot</emphasis> task.</para>
<para>To determine the full list of tasks available for a specific recipe
@@ -943,8 +943,8 @@ $ <command>bitbake</command> -b &lt;bb-file&gt; -D</screen></para>
<listitem>
<para>Unpack the source file but don't apply the patches yet.
Sometimes you may want to look at the extracted, but not patched
- source code and that's what just unpacking will give you (some
- time's handy to get diffs generated against the original
+ source code and that's what just unpacking will give you
+ (sometimes handy to get diffs generated against the original
source).</para>
</listitem>
</varlistentry>
@@ -961,7 +961,7 @@ $ <command>bitbake</command> -b &lt;bb-file&gt; -D</screen></para>
<term>configure</term>
<listitem>
- <para>Performs and configuration that is required for the
+ <para>Performs any configuration that is required for the
software.</para>
</listitem>
</varlistentry>
@@ -1013,12 +1013,12 @@ $ <command>bitbake</command> -b &lt;bb-file&gt; -D</screen></para>
</varlistentry>
</variablelist>
- <para>Note that each of the actions that corresponds to task's will run
+ <para>Note that each of the actions that corresponds to a task will run
any preceding tasks that have not yet been performed. So starting with
compile will also perform the fetch, unpack, patch and configure
actions.</para>
- <para>A typically development session might involve editing files in the
+ <para>A typical development session might involve editing files in the
working directory and then recompiling until it all works:<screen>[<emphasis>... test ...</emphasis>]
$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c compile -D
@@ -1072,7 +1072,7 @@ $ <command>vi</command> recipes/testapp/testapp_4.3.bb</screen>At this stage you
build a specific recipe:<screen>BB&gt;&gt; build net-snmp</screen>If it
fails you may want to clean the build before trying again:<screen>BB&gt;&gt; clean net-snmp</screen>If
you update the recipe by editing the .bb file (to fix some issues) then
- you will want to clean the package, reparse the modified recipe, and the
+ you will want to clean the package, reparse the modified recipe, and then
build again:<screen>BB&gt;&gt; clean net-snmp
BB&gt;&gt; reparse net-snmp
BB&gt;&gt; build net-snmp</screen>Note that you can use wildcards in the
@@ -1088,7 +1088,7 @@ BB&gt;&gt; build net-snmp</screen>Note that you can use wildcards in the
various environment variables, such as <emphasis role="bold">CC</emphasis>
and <emphasis role="bold">PATH</emphasis> etc, to values suitable for
cross-compiling. If you wish to manually run configure scripts and compile
- file during development it would be nice to have all those values set for
+ files during development it would be nice to have all those values set for
you. This is what devshell does - it provides you with an interactive
shell with all the appropriate variables set for cross-compiling.</para>