1
0
mirror of https://git.yoctoproject.org/poky synced 2026-06-03 13:49:49 +00:00

ref-manual: Scrubbed for variable (user) input.

Throughout the manual I had been using angled bracket sets to
denote user-supplied input.  This is confusing and better shown
by using the <replaceable></replaceable> tags.  I scrubbed all
the chapters and replaced as needed.

Some other minor formatting changes were caught and fixed during
the scrub as well.

(From yocto-docs rev: 9a668574dd18828a750cfa2e8c28e1f089a19609)

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-10-16 16:31:19 -07:00
committed by Richard Purdie
parent b96378eb6b
commit 2eaf7e6e75
13 changed files with 166 additions and 160 deletions
+16 -16
View File
@@ -255,7 +255,7 @@
<para>
When you launch your build with the
<filename>bitbake &lt;target&gt;</filename> command, BitBake
<filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
sorts out the configurations to ultimately define your build
environment.
</para>
@@ -351,7 +351,7 @@
Best practices dictate that you isolate these types of
configurations into their own layer.
Settings you provide in
<filename>conf/distro/&lt;distro&gt;.conf</filename> override
<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename> override
similar
settings that BitBake finds in your
<filename>conf/local.conf</filename> file in the Build
@@ -375,7 +375,7 @@
This area holds configuration files for the
layer (<filename>conf/layer.conf</filename>),
the distribution
(<filename>conf/distro/&lt;distro&gt;.conf</filename>),
(<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename>),
and any distribution-wide include files.
</para></listitem>
<listitem><para><emphasis>recipes-*:</emphasis>
@@ -408,7 +408,7 @@
<para>
The BSP Layer's configuration directory contains
configuration files for the machine
(<filename>conf/machine/&lt;machine&gt;.conf</filename>) and,
(<filename>conf/machine/<replaceable>machine</replaceable>.conf</filename>) and,
of course, the layer (<filename>conf/layer.conf</filename>).
</para>
@@ -1145,7 +1145,7 @@
<para>
Images are written out to the
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
inside the <filename>tmp/deploy/images/&lt;machine&gt;/</filename>
inside the <filename>tmp/deploy/images/<replaceable>machine</replaceable>/</filename>
folder as shown in the figure.
This folder contains any files expected to be loaded on the
target device.
@@ -1157,43 +1157,43 @@
variable points to the appropriate directory containing images for
the current configuration.
<itemizedlist>
<listitem><para><filename>&lt;kernel-image&gt;</filename>:
<listitem><para><filename><replaceable>kernel-image</replaceable></filename>:
A kernel binary file.
The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
variable setting determines the naming scheme for the
kernel image file.
Depending on that variable, the file could begin with
a variety of naming strings.
The <filename>deploy/images/&lt;machine&gt;</filename>
The <filename>deploy/images/<replaceable>machine</replaceable></filename>
directory can contain multiple image files for the
machine.</para></listitem>
<listitem><para><filename>&lt;root-filesystem-image&gt;</filename>:
<listitem><para><filename><replaceable>root-filesystem-image</replaceable></filename>:
Root filesystems for the target device (e.g.
<filename>*.ext3</filename> or <filename>*.bz2</filename>
files).
The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
variable setting determines the root filesystem image
type.
The <filename>deploy/images/&lt;machine&gt;</filename>
The <filename>deploy/images/<replaceable>machine</replaceable></filename>
directory can contain multiple root filesystems for the
machine.</para></listitem>
<listitem><para><filename>&lt;kernel-modules&gt;</filename>:
<listitem><para><filename><replaceable>kernel-modules</replaceable></filename>:
Tarballs that contain all the modules built for the kernel.
Kernel module tarballs exist for legacy purposes and
can be suppressed by setting the
<link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
variable to "0".
The <filename>deploy/images/&lt;machine&gt;</filename>
The <filename>deploy/images/<replaceable>machine</replaceable></filename>
directory can contain multiple kernel module tarballs
for the machine.</para></listitem>
<listitem><para><filename>&lt;bootloaders&gt;</filename>:
<listitem><para><filename><replaceable>bootloaders</replaceable></filename>:
Bootloaders supporting the image, if applicable to the
target machine.
The <filename>deploy/images/&lt;machine&gt;</filename>
The <filename>deploy/images/<replaceable>machine</replaceable></filename>
directory can contain multiple bootloaders for the
machine.</para></listitem>
<listitem><para><filename>&lt;symlinks&gt;</filename>:
The <filename>deploy/images/&lt;machine&gt;</filename>
<listitem><para><filename><replaceable>symlinks</replaceable></filename>:
The <filename>deploy/images/<replaceable>machine</replaceable></filename>
folder contains
a symbolic link that points to the most recently built file
for each machine.
@@ -1280,7 +1280,7 @@
part of the SDK (i.e. the part that runs on
the <filename>SDKMACHINE</filename>).
When you use
<filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>
<filename>bitbake -c populate_sdk <replaceable>imagename</replaceable></filename>
to create the SDK, a set of default packages
apply.
This variable allows you to add more packages.