documentation: Changes to Paul Eggleton's edits for various manuals.

Paul sent me a bunch of minor edits and technical corrections
for the ADT, BSP, Development, and YP reference manual.
Most changes were taken as he submitted them.  However, some
formatting conventions were not followed in the commits he made
to yocto-docs/paule/docs2.  After merging them to my yocto-docs/master
branch I fixed some issues.

(From yocto-docs rev: 93f4ea2dee976448f623953e801a80d59736450a)

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 2011-08-24 07:58:32 -07:00 committed by Richard Purdie
parent 88dfc936dc
commit d02e56fd14
11 changed files with 53 additions and 41 deletions

View File

@ -15,7 +15,7 @@
</imageobject>
</mediaobject>
<title>Yocto Application Development Tookit (ADT) User's Guide</title>
<title></title>
<authorgroup>
<author>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 17 KiB

View File

@ -15,7 +15,7 @@
</imageobject>
</mediaobject>
<title>Yocto Board Support Package (BSP) Development Guide</title>
<title></title>
<authorgroup>
<author>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 17 KiB

View File

@ -15,7 +15,7 @@
</imageobject>
</mediaobject>
<title>Yocto Project Development Manual</title>
<title></title>
<authorgroup>
<author>

View File

@ -1004,7 +1004,7 @@
<para>
Finally, don't forget to 'bump' the
<glossterm><link linkend='var-PR'>PR</link></glossterm> value in the same recipe since
<filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since
the resulting packages have changed.
</para>
</section>
@ -1015,7 +1015,7 @@
<para>
The license of an upstream project might change in the future. In order to prevent these changes
going unnoticed, the Yocto Project provides a
<glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm>
<filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
variable to track changes to the license text. The checksums are validated at the end of the
configure step, and if the checksums do not match, the build will fail.
</para>
@ -1060,8 +1060,8 @@
of <filename>S</filename>.
</para>
<para>
Note that this variable is mandatory for all recipes, unless the LICENSE variable is set to
"CLOSED".
Note that this variable is mandatory for all recipes, unless the
<filename>LICENSE</filename> variable is set to "CLOSED".
</para>
</section>
@ -1073,12 +1073,13 @@
important files that contain the license text for the source code.
It is possible to specify a checksum for an entire file, or a specific section of a
file (specified by beginning and ending line numbers with the "beginline" and "endline"
parameters respectively). The latter is useful for source files with license notice header,
README documents, etc.
parameters respectively).
The latter is useful for source files with a license notice header,
README documents, and so forth.
If you do not use the "beginline" parameter, then it is assumed that the text begins on the
first line of the file.
Similarly, if you do not use the "endline" parameter, it is assumed that the license text
ends as the last line of the file.
ends with the last line of the file.
</para>
<para>

View File

@ -15,7 +15,7 @@
</imageobject>
</mediaobject>
<title>Yocto Project Reference Manual</title>
<title></title>
<authorgroup>
<author>

View File

@ -81,7 +81,7 @@
<title>Alternatives - <filename>update-alternatives.bbclass</filename></title>
<para>
Several programs can fulfil the same or similar function and be installed with the same name.
Several programs can fulfill the same or similar function and be installed with the same name.
For example, the <filename>ar</filename> command is available from the
<filename>busybox</filename>, <filename>binutils</filename> and
<filename>elfutils</filename> packages.

View File

@ -95,11 +95,14 @@
</itemizedlist>
<tip>
From Yocto release 1.1 onwards, -live and -directdisk images have been replaced by a "live"
option in IMAGE_FSTYPES that will work with any image to produce an image file that can be
copied directly to a CD or USB device and run as is. To build a live image, simply add
"live" to IMAGE_FSTYPES within local.conf or whereever appropriate and then build the desired
image as normal.
From the Yocto Project release 1.1 onwards, <filename>-live</filename> and
<filename>-directdisk</filename> images have been replaced by a "live"
option in <filename>IMAGE_FSTYPES</filename> that will work with any image to produce an
image file that can be
copied directly to a CD or USB device and run as is.
To build a live image, simply add
"live" to <filename>IMAGE_FSTYPES</filename> within the <filename>local.conf</filename>
file or wherever appropriate and then build the desired image as normal.
</tip>
</appendix>
<!--

View File

@ -468,7 +468,8 @@
Any distribution-specific configuration is controlled from this directory.
The Yocto Project only contains the Yocto Project distribution so
<filename>defaultsetup.conf</filename> is the main file here.
This directory includes the versions and SRCDATEs for applications that are configured here.
This directory includes the versions and the
<filename>SRCDATE</filename> variables for applications that are configured here.
An example of an alternative configuration is <filename>poky-bleeding.conf</filename>
although this file mainly inherits its configuration from the Yocto Project itself.
</para>

View File

@ -74,8 +74,10 @@
<glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
<glossdef>
<para>Lists the names of configured layers. These names are used to find the other BBFILE_*
variables. Typically each layer will append its name to this variable in its
<para>Lists the names of configured layers.
These names are used to find the other <filename>BBFILE_*</filename>
variables.
Typically, each layer will append its name to this variable in its
<filename>conf/layer.conf</filename> file.
</para>
</glossdef>
@ -105,14 +107,16 @@
lower precedence.</para>
<para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
precedence.
For example, the value 6 has a higher precedence than the
value 5.
If not specified, the BBFILE_PRIORITY variable is set based on layer
dependencies (see LAYERDEPENDS below). Tdefault priority if unspecified
for a layer with no dependencies is the lowest defined priority + 1
For example, the value 6 has a higher precedence than the value 5.
If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
dependencies (see the
<filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
more information.
The default priority, if unspecified
for a layer with no dependencies, is the lowest defined priority + 1
(or 1 if no priorities are defined).</para>
<tip>
You can use the command "bitbake-layers show_layers" to list
You can use the command <filename>bitbake-layers show_layers</filename> to list
all configured layers along with their priorities.
</tip>
</glossdef>
@ -552,14 +556,14 @@
<glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
<glossdef>
<para>Lists the layers that this recipe depends upon, separated by spaces.
Optionally a specific layer version may be specified for a dependency
by adding it to the end of the layer name with a colon, e.g. "anotherlayer:3"
(to be compared against LAYERVERSION_anotherlayer in this example).
Optionally, you can specify a specific layer version for a dependency
by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
to be compared against <filename>LAYERVERSION_anotherlayer</filename> in this case).
An error will be produced if any dependency is missing or
the version numbers do not match exactly (if specified).
This variable is used in the <filename>conf/layer.conf</filename> file
and must be suffixed with the name of the specific layer (e.g.
LAYERDEPENDS_mylayer).</para>
<filename>LAYERDEPENDS_mylayer</filename>).</para>
</glossdef>
</glossentry>
@ -577,11 +581,11 @@
<glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
<glossdef>
<para>Optionally specifies the version of a layer as a single number.
This may be used within LAYERDEPENDS for another layer in order to
You can use this within <filename>LAYERDEPENDS</filename> for another layer in order to
depend on a specific version of the layer.
This variable is used in the <filename>conf/layer.conf</filename> file
and must be suffixed with the name of the specific layer (e.g.
LAYERVERSION_mylayer).</para>
<filename>LAYERVERSION_mylayer</filename>).</para>
</glossdef>
</glossentry>
@ -600,7 +604,7 @@
failure, which gives the developer an opportunity to review any
license change.</para>
<para>
This variable must be defined for all recipes (unless LICENSE
This variable must be defined for all recipes (unless <filename>LICENSE</filename>
is set to "CLOSED")</para>
<para>For more information, see the
<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
@ -970,10 +974,11 @@
<para>
The revision of the source code used to build the package.
This variable applies to Subversion, Git, Mercurial and Bazaar
only. Note that if you wish to build a fixed revision and you wish
only.
Note that if you wish to build a fixed revision and you wish
to avoid performing a query on the remote repository every time
BitBake parses your recipe, you should specify a SRCREV that is a
full revision identifier (and not just a tag).
BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
full revision identifier and not just a tag.
</para>
</glossdef>
</glossentry>
@ -1070,14 +1075,16 @@
By default, the variable is set to "xterm" but it can
be any X11 terminal application or a terminal multiplexer such as screen.
</para>
<para>
NOTE: whilst KONSOLE_TERMCMD and KONSOLE_TERMCMDRUN are provided
<note>
While <filename>KONSOLE_TERMCMD</filename> and
<filename>KONSOLE_TERMCMDRUN</filename> are provided
and will work with KDE's Konsole terminal application Konsole from KDE 3,
Konsole in KDE 4.0 and later will no longer work here due to the fact
Konsole in KDE 4.0 and later versions will no longer work here due to the fact
that it now launches in the background by default, and it is not practically
possible to wait until it has terminated. It is hoped that this can be fixed
possible to wait until it has terminated.
It is hoped that this can be fixed
in a future version.
</para>
</note>
</glossdef>
</glossentry>