CaROS/poky
3
1
Fork 0
mirror of https://git.yoctoproject.org/git/poky synced 2026-01-01 13:58:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
documentation/ref-manual/closer-look.xml
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.

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

@ -321,7 +321,7 @@
<qandaentry>
<question>
<para>
What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
What’s the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>?
</para>
</question>
<answer>

8
documentation/ref-manual/introduction.xml
View File

@ -402,14 +402,14 @@
choose the installation directory.
For example, you could choose the following:
<literallayout class='monospaced'>
/home/your-username/buildtools
/home/<replaceable>your-username</replaceable>/buildtools
</literallayout>
</para></listitem>
<listitem><para>
Source the tools environment setup script by using a
command like the following:
<literallayout class='monospaced'>
$ source /home/your-username/buildtools/environment-setup-i586-poky-linux
$ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
</literallayout>
Of course, you need to supply your installation directory and be
sure to use the right file (i.e. i585 or x86-64).
@ -488,14 +488,14 @@
choose the installation directory.
For example, you could choose the following:
<literallayout class='monospaced'>
/home/your-username/buildtools
/home/<replaceable>your-username</replaceable>/buildtools
</literallayout>
</para></listitem>
<listitem><para>
Source the tools environment setup script by using a
command like the following:
<literallayout class='monospaced'>
$ source /home/your-username/buildtools/environment-setup-i586-poky-linux
$ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
</literallayout>
Of course, you need to supply your installation directory and be
sure to use the right file (i.e. i585 or x86-64).

25
documentation/ref-manual/migration.xml
View File

@ -110,7 +110,7 @@
appended to the path used to access the mirror.
Here is an example:
<literallayout class='monospaced'>
SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
SSTATE_MIRRORS = "file://.* http://<replaceable>someserver</replaceable>.tld/share/sstate/PATH"
</literallayout>
</para>
</section>
@ -375,10 +375,11 @@
<listitem><para><emphasis>Shared State Code:</emphasis>
The shared state code has been optimized to avoid running
unnecessary tasks.
For example,
<filename>bitbake -c rootfs some-image</filename> from
shared state no longer populates the target sysroot
since that is not necessary.
For example, the following no longer populates the target
sysroot since that is not necessary:
<literallayout class='monospaced'>
$ bitbake -c rootfs <replaceable>some-image</replaceable>
</literallayout>
Instead, the system just needs to extract the output
package contents, re-create the packages, and construct
the root filesystem.
@ -832,7 +833,7 @@
This directory is located under
<filename>sysroots</filename> and uses a machine-specific
name (i.e.
<filename>tmp/sysroots/&lt;machine&gt;/pkgdata</filename>).
<filename>tmp/sysroots/<replaceable>machine</replaceable>/pkgdata</filename>).
</para></listitem>
</itemizedlist>
</para>
@ -1100,7 +1101,7 @@
</para></listitem>
<listitem><para>
<filename>base-files</filename>: Remove the unnecessary
<filename>media/xxx</filename> directories.
<filename>media/</filename><replaceable>xxx</replaceable> directories.
</para></listitem>
<listitem><para>
<filename>alsa-state</filename>: Provide an empty
@ -1228,7 +1229,7 @@
value against the branch.
You can specify the branch using the following form:
<literallayout class='monospaced'>
SRC_URI = "git://server.name/repository;branch=&lt;branchname&gt;"
SRC_URI = "git://server.name/repository;branch=<replaceable>branchname</replaceable>"
</literallayout>
If you do not specify a branch, BitBake looks
in the default "master" branch.
@ -1305,10 +1306,10 @@
</section>
<section id='migration-1.6-task-taskname-overrides'>
<title><filename>task-&lt;taskname&gt;</filename> Overrides</title>
<title><filename>task-</filename><replaceable>taskname</replaceable> Overrides</title>
<para>
<filename>task-&lt;taskname&gt;</filename> overrides have been
<filename>task-</filename><replaceable>taskname</replaceable> overrides have been
adjusted so that tasks whose names contain underscores have the
underscores replaced by hyphens for the override so that they
now function properly.
@ -1932,8 +1933,8 @@
</para></listitem>
<listitem><para>
Package QA checks are now performed during a new
<filename>do_package_qa</filename> task rather
than being part of the
<link linkend='ref-tasks-package_qa'><filename>do_package_qa</filename></link>
task rather than being part of the
<link linkend='ref-tasks-package'><filename>do_package</filename></link>
task.
This allows more parallel execution.

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

@ -1947,7 +1947,7 @@
You can create a recipe that builds tools that run natively on the
host a couple different ways:
<itemizedlist>
<listitem><para>Create a <filename>myrecipe-native.bb</filename>
<listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-native.bb</filename>
that inherits the <filename>native</filename> class.
If you use this method, you must order the inherit statement
in the recipe after all other inherit statements so that the
@ -1988,7 +1988,7 @@
You can create a recipe that builds tools that run on the SDK machine
a couple different ways:
<itemizedlist>
<listitem><para>Create a <filename>myrecipe-nativesdk.bb</filename>
<listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-nativesdk.bb</filename>
recipe that inherits the <filename>nativesdk</filename> class.
If you use this method, you must order the inherit statement
in the recipe after all other inherit statements so that the
@ -2915,37 +2915,37 @@
<para>
The class supports the following variables:
<itemizedlist>
<listitem><para><emphasis><link linkend='var-INITRD'><filename>INITRD</filename></link>:</emphasis>
<listitem><para><link linkend='var-INITRD'><filename>INITRD</filename></link>:
Indicates list of filesystem images to concatenate and use as
an initial RAM disk (initrd).
This variable is optional.</para></listitem>
<listitem><para><emphasis><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:</emphasis>
<listitem><para><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:
Indicates a filesystem image to include as the root filesystem.
This variable is optional.</para></listitem>
<listitem><para><emphasis><link linkend='var-AUTO_SYSLINUXMENU'><filename>AUTO_SYSLINUXMENU</filename></link>:</emphasis>
<listitem><para><link linkend='var-AUTO_SYSLINUXMENU'><filename>AUTO_SYSLINUXMENU</filename></link>:
Enables creating an automatic menu when set to "1".
</para></listitem>
<listitem><para><emphasis><link linkend='var-LABELS'><filename>LABELS</filename></link>:</emphasis>
<listitem><para><link linkend='var-LABELS'><filename>LABELS</filename></link>:
Lists targets for automatic configuration.
</para></listitem>
<listitem><para><emphasis><link linkend='var-APPEND'><filename>APPEND</filename></link>:</emphasis>
<listitem><para><link linkend='var-APPEND'><filename>APPEND</filename></link>:
Lists append string overrides for each label.
</para></listitem>
<listitem><para><emphasis><link linkend='var-SYSLINUX_OPTS'><filename>SYSLINUX_OPTS</filename></link>:</emphasis>
<listitem><para><link linkend='var-SYSLINUX_OPTS'><filename>SYSLINUX_OPTS</filename></link>:
Lists additional options to add to the syslinux file.
Semicolon characters separate multiple options.
</para></listitem>
<listitem><para><emphasis><link linkend='var-SYSLINUX_SPLASH'><filename>SYSLINUX_SPLASH</filename></link>:</emphasis>
<listitem><para><link linkend='var-SYSLINUX_SPLASH'><filename>SYSLINUX_SPLASH</filename></link>:
Lists a background for the VGA boot menu when you are using the
boot menu.</para></listitem>
<listitem><para><emphasis><link linkend='var-SYSLINUX_DEFAULT_CONSOLE'><filename>SYSLINUX_DEFAULT_CONSOLE</filename></link>:</emphasis>
<listitem><para><link linkend='var-SYSLINUX_DEFAULT_CONSOLE'><filename>SYSLINUX_DEFAULT_CONSOLE</filename></link>:
Set to "console=ttyX" to change kernel boot default console.
</para></listitem>
<listitem><para><emphasis><link linkend='var-SYSLINUX_SERIAL'><filename>SYSLINUX_SERIAL</filename></link>:</emphasis>
<listitem><para><link linkend='var-SYSLINUX_SERIAL'><filename>SYSLINUX_SERIAL</filename></link>:
Sets an alternate serial port.
Or, turns off serial when the variable is set with an
empty string.</para></listitem>
<listitem><para><emphasis><link linkend='var-SYSLINUX_SERIAL_TTY'><filename>SYSLINUX_SERIAL_TTY</filename></link>:</emphasis>
<listitem><para><link linkend='var-SYSLINUX_SERIAL_TTY'><filename>SYSLINUX_SERIAL_TTY</filename></link>:
Sets an alternate "console=tty..." kernel boot argument.
</para></listitem>
</itemizedlist>

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

@ -42,7 +42,7 @@
changed based on a given feature:
<literallayout class='monospaced'>
$ cd poky
$ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
$ git grep 'contains.*MACHINE_FEATURES.*<replaceable>feature</replaceable>'
</literallayout>
</para>

46
documentation/ref-manual/ref-images.xml
View File

@ -38,9 +38,9 @@
</para>
<para>
Following, is a list of supported recipes:
Following is a list of supported recipes:
<itemizedlist>
<listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
<listitem><para><filename>build-appliance-image</filename>:
An example virtual machine that contains all the pieces required to
run builds using the build system as well as the build system itself.
You can boot and run the image using either the
@ -49,18 +49,18 @@
For more information on this image, see the
<ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
the Yocto Project website.</para></listitem>
<listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
<listitem><para><filename>core-image-base</filename>:
A console-only image that fully supports the target device hardware.</para></listitem>
<listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
<listitem><para><filename>core-image-clutter</filename>:
An image with support for the Open GL-based toolkit Clutter, which enables development of
rich and animated graphical user interfaces.</para></listitem>
<listitem><para><emphasis><filename>core-image-directfb</filename>:</emphasis>
<listitem><para><filename>core-image-directfb</filename>:
An image that uses <filename>directfb</filename> instead of X11.
</para></listitem>
<listitem><para><emphasis><filename>core-image-full-cmdline</filename>:</emphasis>
<listitem><para><filename>core-image-full-cmdline</filename>:
A console-only image with more full-featured Linux system
functionality installed.</para></listitem>
<listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
<listitem><para><filename>core-image-lsb</filename>:
An image that conforms to the Linux Standard Base (LSB)
specification.
This image requires a distribution configuration that
@ -68,7 +68,7 @@
If you build <filename>core-image-lsb</filename> without that
configuration, the image will not be LSB-compliant.
</para></listitem>
<listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
<listitem><para><filename>core-image-lsb-dev</filename>:
A <filename>core-image-lsb</filename> image that is suitable for development work
using the host.
The image includes headers and libraries you can use in a host development
@ -78,7 +78,7 @@
If you build <filename>core-image-lsb-dev</filename> without that
configuration, the image will not be LSB-compliant.
</para></listitem>
<listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
<listitem><para><filename>core-image-lsb-sdk</filename>:
A <filename>core-image-lsb</filename> that includes everything in
meta-toolchain but also includes development headers and libraries
to form a complete standalone SDK.
@ -87,15 +87,15 @@
If you build <filename>core-image-lsb-sdk</filename> without that
configuration, the image will not be LSB-compliant.
This image is suitable for development using the target.</para></listitem>
<listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
<listitem><para><filename>core-image-minimal</filename>:
A small image just capable of allowing a device to boot.</para></listitem>
<listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
<listitem><para><filename>core-image-minimal-dev</filename>:
A <filename>core-image-minimal</filename> image suitable for development work
using the host.
The image includes headers and libraries you can use in a host development
environment.
</para></listitem>
<listitem><para id='images-core-image-minimal-initramfs'><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
<listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>:
A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
Initial Root Filesystem (initramfs) as part of the kernel,
which allows the system to find the first “init” program more efficiently.
@ -104,38 +104,38 @@
variable for additional information helpful when working with
initramfs images.
</para></listitem>
<listitem><para><emphasis><filename>core-image-minimal-mtdutils</filename>:</emphasis>
<listitem><para><filename>core-image-minimal-mtdutils</filename>:
A <filename>core-image-minimal</filename> image that has support
for the Minimal MTD Utilities, which let the user interact with the
MTD subsystem in the kernel to perform operations on flash devices.
</para></listitem>
<listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
<listitem><para><filename>core-image-rt</filename>:
A <filename>core-image-minimal</filename> image plus a real-time test suite and
tools appropriate for real-time use.</para></listitem>
<listitem><para><emphasis><filename>core-image-rt-sdk</filename>:</emphasis>
<listitem><para><filename>core-image-rt-sdk</filename>:
A <filename>core-image-rt</filename> image that includes everything in
<filename>meta-toolchain</filename>.
The image also includes development headers and libraries to form a complete
stand-alone SDK and is suitable for development using the target.
</para></listitem>
<listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
<listitem><para><filename>core-image-sato</filename>:
An image with Sato support, a mobile environment and visual style that works well
with mobile devices.
The image supports X11 with a Sato theme and applications such as
a terminal, editor, file manager, media player, and so forth.
</para></listitem>
<listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
<listitem><para><filename>core-image-sato-dev</filename>:
A <filename>core-image-sato</filename> image suitable for development
using the host.
The image includes libraries needed to build applications on the device itself,
testing and profiling tools, and debug symbols.
This image was formerly <filename>core-image-sdk</filename>.
</para></listitem>
<listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
<listitem><para><filename>core-image-sato-sdk</filename>:
A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
The image also includes development headers and libraries to form a complete standalone SDK
and is suitable for development using the target.</para></listitem>
<listitem><para><emphasis><filename>core-image-testmaster</filename>:</emphasis>
<listitem><para><filename>core-image-testmaster</filename>:
A "master" image designed to be used for automated runtime testing.
Provides a "known good" image that is deployed to a separate
partition so that you can boot into it and use it to deploy a
@ -144,21 +144,21 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
section in the Yocto Project Development Manual.
</para></listitem>
<listitem><para><emphasis><filename>core-image-testmaster-initramfs</filename>:</emphasis>
<listitem><para><filename>core-image-testmaster-initramfs</filename>:
A RAM-based Initial Root Filesystem (initramfs) image tailored for
use with the <filename>core-image-testmaster</filename> image.
</para></listitem>
<listitem><para><emphasis><filename>core-image-weston</filename>:</emphasis>
<listitem><para><filename>core-image-weston</filename>:
A very basic Wayland image with a terminal.
This image provides the Wayland protocol libraries and the
reference Weston compositor.
For more information, see the
"<link linkend='wayland'>Wayland</link>" section.
</para></listitem>
<listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
<listitem><para><filename>core-image-x11</filename>:
A very basic X11 image with a terminal.
</para></listitem>
<listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
<listitem><para><filename>qt4e-demo-image</filename>:
An image that launches into the demo application for the embedded
(not based on X11) version of Qt.</para></listitem>
</itemizedlist>

2
documentation/ref-manual/ref-qa-checks.xml
View File

@ -727,7 +727,7 @@ can be found then it should be implemented. I can't find one at the moment.
files that it should not have (e.g. a non-symlink
<filename>.so</filename> file) or it might have been added
manually (e.g. by adding to
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>).
</para>
<para>

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

@ -315,7 +315,7 @@
commands.
Following is the script syntax:
<literallayout class='monospaced'>
$ source oe-init-build-env-memres &lt;port_number&gt; &lt;build_dir&gt;
$ source oe-init-build-env-memres <replaceable>port_number</replaceable> <replaceable>build_dir</replaceable>
</literallayout>
The script uses other scripts within the
<filename>scripts</filename> directory to do the bulk of the work.
@ -499,7 +499,7 @@
the variable in the top-level build environment setup script as
follows:
<literallayout class='monospaced'>
TEMPLATECONF=&lt;your_layer&gt;/conf
TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
</literallayout>
Once the build process gets the sample file, it uses
<filename>sed</filename> to substitute final
@ -554,7 +554,7 @@
you can base your build from any layer by setting the variable in
the top-level build environment setup script as follows:
<literallayout class='monospaced'>
TEMPLATECONF=&lt;your_layer&gt;/conf
TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
</literallayout>
Once the build process gets the sample file, it uses
<filename>sed</filename> to substitute final

10
documentation/ref-manual/ref-tasks.xml
View File

@ -324,7 +324,7 @@
<para>
You can run this task using BitBake as follows:
<literallayout class='monospaced'>
$ bitbake -c clean &lt;recipe&gt;
$ bitbake -c clean <replaceable>recipe</replaceable>
</literallayout>
</para>
@ -338,7 +338,7 @@
If you want to remove the sstate cache files for the recipe,
you need to use the
<link linkend='ref-tasks-cleansstate'><filename>do_cleansstate</filename></link>
task instead (i.e. <filename>bitbake -c cleansstate &lt;recipe&gt;</filename>).
task instead (i.e. <filename>bitbake -c cleansstate</filename> <replaceable>recipe</replaceable>).
</para>
</section>
@ -359,7 +359,7 @@
<para>
You can run this task using BitBake as follows:
<literallayout class='monospaced'>
$ bitbake -c cleanall &lt;recipe&gt;
$ bitbake -c cleanall <replaceable>recipe</replaceable>
</literallayout>
</para>
@ -389,7 +389,7 @@
<para>
You can run this task using BitBake as follows:
<literallayout class='monospaced'>
$ bitbake -c cleansstate &lt;recipe&gt;
$ bitbake -c cleansstate <replaceable>recipe</replaceable>
</literallayout>
</para>
@ -404,7 +404,7 @@
If you need to build a target from scratch using remote
mirrors, use the "-f" option as follows:
<literallayout class='monospaced'>
$ bitbake -f -c do_cleansstate &lt;target&gt;
$ bitbake -f -c do_cleansstate <replaceable>target</replaceable>
</literallayout>
</note>
</para>

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

@ -136,7 +136,7 @@
<note>
If <filename>ALTERNATIVE_LINK_NAME</filename> is not
defined, it defaults to
<filename>${bindir}/&lt;name&gt;</filename>.
<filename>${bindir}/<replaceable>name</replaceable></filename>.
</note>
</para>
@ -159,9 +159,9 @@
a default for specific commands tied to particular packages.
Here are the available syntax forms:
<literallayout class='monospaced'>
ALTERNATIVE_PRIORITY = "&lt;priority&gt;"
ALTERNATIVE_PRIORITY[&lt;name&gt;] = "&lt;priority&gt;"
ALTERNATIVE_PRIORITY_&lt;pkg&gt;[&lt;name&gt;] = "&lt;priority&gt;"
ALTERNATIVE_PRIORITY = "<replaceable>priority</replaceable>"
ALTERNATIVE_PRIORITY[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
ALTERNATIVE_PRIORITY_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
</literallayout>
</para>
@ -185,9 +185,9 @@
a default for specific commands tied to particular packages.
Here are the available syntax forms:
<literallayout class='monospaced'>
ALTERNATIVE_TARGET = "&lt;target&gt;"
ALTERNATIVE_TARGET[&lt;name&gt;] = "&lt;target&gt;"
ALTERNATIVE_TARGET_&lt;pkg&gt;[&lt;name&gt;] = "&lt;target&gt;"
ALTERNATIVE_TARGET = "<replaceable>target</replaceable>"
ALTERNATIVE_TARGET[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
ALTERNATIVE_TARGET_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
</literallayout>
<note>
<para>
@ -338,13 +338,13 @@
being installed by listing them with the
<filename>BAD_RECOMMENDATIONS</filename> variable:
<literallayout class='monospaced'>
BAD_RECOMMENDATIONS = "&lt;package_name&gt; &lt;package_name&gt; &lt;package_name&gt; ..."
BAD_RECOMMENDATIONS = "<replaceable>package_name</replaceable> <replaceable>package_name</replaceable> <replaceable>package_name</replaceable> ..."
</literallayout>
You can set this variable globally in your
<filename>local.conf</filename> file or you can attach it to
a specific image recipe by using the recipe name override:
<literallayout class='monospaced'>
BAD_RECOMMENDATIONS_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
BAD_RECOMMENDATIONS_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
</literallayout>
</para>
@ -445,11 +445,11 @@
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
Use the following form:
<literallayout class='monospaced'>
BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
BB_DISKMON_DIRS = "<replaceable>action</replaceable>,<replaceable>dir</replaceable>,<replaceable>threshold</replaceable> [...]"
where:
&lt;action&gt; is:
<replaceable>action</replaceable> is:
ABORT: Immediately abort the build when
a threshold is broken.
STOPTASKS: Stop the build after the currently
@ -463,14 +463,14 @@
which must be defined in the
conf/local.conf file.
&lt;dir&gt; is:
<replaceable>dir</replaceable> is:
Any directory you choose. You can specify one or
more directories to monitor by separating the
groupings with a space. If two directories are
on the same device, only the first directory
is monitored.
&lt;threshold&gt; is:
<replaceable>threshold</replaceable> is:
Either the minimum available disk space,
the minimum number of free inodes, or
both. You must specify at least one. To
@ -559,16 +559,16 @@
When specifying the variable in your configuration file,
use the following form:
<literallayout class='monospaced'>
BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
BB_DISKMON_WARNINTERVAL = "<replaceable>disk_space_interval</replaceable>,<replaceable>disk_inode_interval</replaceable>"
where:
&lt;disk_space_interval&gt; is:
<replaceable>disk_space_interval</replaceable> is:
An interval of memory expressed in either
G, M, or K for Gbytes, Mbytes, or Kbytes,
respectively. You cannot use GB, MB, or KB.
&lt;disk_inode_interval&gt; is:
<replaceable>disk_inode_interval</replaceable> is:
An interval of free inodes expressed in either
G, M, or K for Gbytes, Mbytes, or Kbytes,
respectively. You cannot use GB, MB, or KB.
@ -643,7 +643,7 @@
which is a compiler built to run on the build machine but produces binaries
that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
"nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
and "mulitlibs" in the form "<filename>multilib:&lt;multilib_name&gt;</filename>".
and "mulitlibs" in the form "<filename>multilib:</filename><replaceable>multilib_name</replaceable>".
</para>
<para>
@ -651,7 +651,7 @@
is as simple as adding the following to your recipe:
<literallayout class='monospaced'>
BBCLASSEXTEND =+ "native nativesdk"
BBCLASSEXTEND =+ "multilib:&lt;multilib_name&gt;"
BBCLASSEXTEND =+ "multilib:<replaceable>multilib_name</replaceable>"
</literallayout>
</para>
</glossdef>
@ -856,9 +856,9 @@
Set the variable as you would any environment variable
and then run BitBake:
<literallayout class='monospaced'>
$ BBPATH = "&lt;build_directory&gt;"
$ BBPATH = "<replaceable>build_directory</replaceable>"
$ export BBPATH
$ bitbake &lt;target&gt;
$ bitbake <replaceable>target</replaceable>
</literallayout>
</note>
</para>
@ -2241,7 +2241,7 @@
you want the error reporting tool to store the debug files
as follows in your <filename>local.conf</filename> file:
<literallayout class='monospaced'>
ERR_REPORT_DIR = "path"
ERR_REPORT_DIR = "<replaceable>path</replaceable>"
</literallayout>
</para>
</glossdef>
@ -2585,11 +2585,11 @@
should have the name of the feature item as an override.
Here is an example:
<literallayout class='monospaced'>
FEATURE_PACKAGES_widget = "package1 package2"
FEATURE_PACKAGES_widget = "<replaceable>package1</replaceable> <replaceable>package2</replaceable>"
</literallayout>
In this example, if "widget" were added to
<filename>IMAGE_FEATURES</filename>, "package1" and
"package2" would be included in the image.
<filename>IMAGE_FEATURES</filename>, <replaceable>package1</replaceable> and
<replaceable>package2</replaceable> would be included in the image.
<note>
Packages installed by features defined through
<filename>FEATURE_PACKAGES</filename> are often package
@ -3468,7 +3468,7 @@
<para>
When you use this variable, it is best to use it as follows:
<literallayout class='monospaced'>
IMAGE_INSTALL_append = " package-name"
IMAGE_INSTALL_append = " <replaceable>package-name</replaceable>"
</literallayout>
Be sure to include the space between the quotation character
and the start of the package name or names.
@ -3520,7 +3520,7 @@
The file contains package information on a line-per-package
basis as follows:
<literallayout class='monospaced'>
&lt;packagename&gt; &lt;packagearch&gt; &lt;version&gt;
<replaceable>packagename</replaceable> <replaceable>packagearch</replaceable> <replaceable>version</replaceable>
</literallayout>
</para>
@ -3653,7 +3653,7 @@
OpenEmbedded build system has created the image.
You can specify shell commands separated by semicolons:
<literallayout class='monospaced'>
IMAGE_POSTPROCESS_COMMAND += "&lt;shell_command&gt;; ... "
IMAGE_POSTPROCESS_COMMAND += "<replaceable>shell_command</replaceable>; ... "
</literallayout>
If you need to pass the path to the root filesystem within
the command, you can use
@ -4458,7 +4458,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<para>
Specify it as follows:
<literallayout class='monospaced'>
KERNEL_MODULE_AUTOLOAD += "modname1 modname2 modname3"
KERNEL_MODULE_AUTOLOAD += "<replaceable>module_name1</replaceable> <replaceable>module_name2</replaceable> <replaceable>module_name3</replaceable>"
</literallayout>
</para>
@ -4470,7 +4470,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
The modules appear one-per-line in the file.
Here is an example of the most common use case:
<literallayout class='monospaced'>
KERNEL_MODULE_AUTOLOAD += "modname"
KERNEL_MODULE_AUTOLOAD += "<replaceable>module_name</replaceable>"
</literallayout>
</para>
@ -4489,7 +4489,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<para>
Provides a list of modules for which the OpenEmbedded
build system expects to find
<link linkend='var-module_conf'><filename>module_conf_&lt;modname&gt;</filename></link>
<filename>module_conf_</filename><replaceable>modname</replaceable>
values that specify configuration for each of the modules.
For information on how to provide those module
configurations, see the
@ -4505,7 +4505,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
The location of the kernel sources.
This variable is set to the value of the
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
within the <filename>module.bbclass</filename> class.
within the
<link linkend='ref-classes-module'><filename>module</filename></link>
class.
For information on how this variable is used, see the
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
section.
@ -4530,7 +4532,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
The location of the kernel sources.
This variable is set to the value of the
<link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
within the <filename>module.bbclass</filename> class.
within the
<link linkend='ref-classes-module'><filename>module</filename></link>
class.
For information on how this variable is used, see the
"<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
section.
@ -4796,10 +4800,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<para>
This variable must be defined for all recipes (unless
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
is set to "CLOSED")</para>
is set to "CLOSED").</para>
<para>For more information, see the
<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
Tracking License Changes</link> section</para>
"<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
Tracking License Changes</link>" section.</para>
</glossdef>
</glossentry>
@ -4912,7 +4916,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
The <filename>LICENSE_PATH</filename> variable allows you to extend that
location to other areas that have additional licenses:
<literallayout class='monospaced'>
LICENSE_PATH += "/path/to/additional/common/licenses"
LICENSE_PATH += "<replaceable>path-to-additional-common-licenses</replaceable>"
</literallayout></para>
</glossdef>
</glossentry>
@ -5407,7 +5411,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<para>
Here is the general syntax:
<literallayout class='monospaced'>
module_conf_&lt;modname&gt; = "&lt;modprobe.d syntax&gt;"
module_conf_<replaceable>module_name</replaceable> = "<replaceable>modprobe.d-syntax</replaceable>"
</literallayout>
You must use the kernel module name override.
</para>
@ -5531,7 +5535,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<filename>local.conf</filename> file or you can attach it to
a specific image recipe by using the recipe name override:
<literallayout class='monospaced'>
NO_RECOMMENDATIONS_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
NO_RECOMMENDATIONS_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
</literallayout>
</para>
@ -5909,13 +5913,13 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Lists packages that should not be installed into an image.
For example:
<literallayout class='monospaced'>
PACKAGE_EXCLUDE = "&lt;package_name&gt; &lt;package_name&gt; &lt;package_name&gt; ..."
PACKAGE_EXCLUDE = "<replaceable>package_name</replaceable> <replaceable>package_name</replaceable> <replaceable>package_name</replaceable> ..."
</literallayout>
You can set this variable globally in your
<filename>local.conf</filename> file or you can attach it to
a specific image recipe by using the recipe name override:
<literallayout class='monospaced'>
PACKAGE_EXCLUDE_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
PACKAGE_EXCLUDE_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
</literallayout>
</para>
@ -6099,8 +6103,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<itemizedlist>
<listitem><para><emphasis>Append file:</emphasis>
Create an append file named
<filename>&lt;recipename&gt;.bbappend</filename> in your
layer and override the value of
<replaceable>recipename</replaceable><filename>.bbappend</filename>
in your layer and override the value of
<filename>PACKAGECONFIG</filename>.
You can either completely override the variable:
<literallayout class='monospaced'>
@ -6114,15 +6118,15 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
This method is identical to changing the block
through an append file except you edit your
<filename>local.conf</filename> or
<filename>&lt;mydistro&gt;.conf</filename> file.
<filename><replaceable>mydistro</replaceable>.conf</filename> file.
As with append files previously described,
you can either completely override the variable:
<literallayout class='monospaced'>
PACKAGECONFIG_pn-&lt;recipename&gt;="f4 f5"
PACKAGECONFIG_pn-<replaceable>recipename</replaceable>="f4 f5"
</literallayout>
Or, you can just amend the variable:
<literallayout class='monospaced'>
PACKAGECONFIG_append_pn-&lt;recipename&gt; = " f4"
PACKAGECONFIG_append_pn-<replaceable>recipename</replaceable> = " f4"
</literallayout></para></listitem>
</itemizedlist>
</para>
@ -6345,7 +6349,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
For example, when the
<link linkend='ref-classes-debian'><filename>debian</filename></link>
class renames the output package, it does so by setting
<filename>PKG_&lt;packagename&gt;</filename>.
<filename>PKG_<replaceable>packagename</replaceable></filename>.
</para>
</glossdef>
</glossentry>
@ -6868,7 +6872,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
them in conjunction with a package name override.
Here is an example:
<literallayout class='monospaced'>
RCONFLICTS_${PN} = "another-conflicting-package-name"
RCONFLICTS_${PN} = "<replaceable>another-conflicting-package-name</replaceable>"
</literallayout>
</para>
@ -6880,7 +6884,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Here is the general syntax to specify versions with
the <filename>RCONFLICTS</filename> variable:
<literallayout class='monospaced'>
RCONFLICTS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
RCONFLICTS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
</literallayout>
For <filename>operator</filename>, you can specify the
following:
@ -6972,7 +6976,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
as it would in the <filename>PACKAGES</filename>
namespace before any renaming of the output package by
classes like
<link linkend='ref-classes-debian'><filename>debian.bbclass</filename></link>.
<link linkend='ref-classes-debian'><filename>debian</filename></link>.
</para>
<para>
@ -7006,7 +7010,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Here is the general syntax to specify versions with
the <filename>RDEPENDS</filename> variable:
<literallayout class='monospaced'>
RDEPENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
RDEPENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
</literallayout>
For <filename>operator</filename>, you can specify the
following:
@ -7136,7 +7140,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
OpenEmbedded build system has created the root filesystem.
You can specify shell commands separated by semicolons:
<literallayout class='monospaced'>
ROOTFS_POSTPROCESS_COMMAND += "&lt;shell_command&gt;; ... "
ROOTFS_POSTPROCESS_COMMAND += "<replaceable>shell_command</replaceable>; ... "
</literallayout>
If you need to pass the path to the root filesystem within
the command, you can use
@ -7224,7 +7228,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
that is extended to support wireless functionality.
In this case, you would use the following:
<literallayout class='monospaced'>
RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
RRECOMMENDS_${PN}-dev += "<replaceable>wireless_package_name</replaceable>"
</literallayout>
In the example, the package name
(<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
@ -7242,7 +7246,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Here is the general syntax to specify versions with
the <filename>RRECOMMENDS</filename> variable:
<literallayout class='monospaced'>
RRECOMMENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
RRECOMMENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
</literallayout>
For <filename>operator</filename>, you can specify the
following:
@ -7280,7 +7284,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
override.
Here is an example:
<literallayout class='monospaced'>
RREPLACES_${PN} = "other-package-being-replaced"
RREPLACES_${PN} = "<replaceable>other-package-being-replaced</replaceable>"
</literallayout>
</para>
@ -7292,7 +7296,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Here is the general syntax to specify versions with
the <filename>RREPLACES</filename> variable:
<literallayout class='monospaced'>
RREPLACES_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
RREPLACES_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
</literallayout>
For <filename>operator</filename>, you can specify the
following:
@ -7327,7 +7331,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
override.
Here is an example:
<literallayout class='monospaced'>
RSUGGESTS_${PN} = "useful-package another-package"
RSUGGESTS_${PN} = "<replaceable>useful-package</replaceable> <replaceable>another-package</replaceable>"
</literallayout>
</para>
</glossdef>
@ -7503,7 +7507,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
However, this variable applies to the SDK generated from an
image using the following command:
<literallayout class='monospaced'>
$ bitbake -c populate_sdk imagename
$ bitbake -c populate_sdk <replaceable>imagename</replaceable>
</literallayout>
</para>
</glossdef>
@ -8083,8 +8087,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
directory structure.
<literallayout class='monospaced'>
SSTATE_MIRRORS ?= "\
file://.* http://someserver.tld/share/sstate/PATH \n \
file://.* file:///some/local/dir/sstate/PATH"
file://.* http://<replaceable>someserver</replaceable>.tld/share/sstate/PATH \n \
file://.* file:///<replaceable>some-local-dir</replaceable>/sstate/PATH"
</literallayout>
</para>
</glossdef>
@ -9090,7 +9094,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
You can add your own tests to the list of tests by
appending <filename>TEST_SUITES</filename> as follows:
<literallayout class='monospaced'>
TEST_SUITES_append = " mytest"
TEST_SUITES_append = " <replaceable>mytest</replaceable>"
</literallayout>
Alternatively, you can provide the "auto" option to
have all applicable tests run against the image.
@ -9511,11 +9515,11 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</glossdef>
</glossentry>
<glossentry id='var-TUNECONFLICT'><glossterm>TUNECONFLICT[&lt;feature&gt;]</glossterm>
<glossentry id='var-TUNECONFLICT'><glossterm>TUNECONFLICT[<replaceable>feature</replaceable>]</glossterm>
<glossdef>
<para>
Specifies CPU or Application Binary Interface (ABI)
tuning features that conflict with &gt;feature&lt;.
tuning features that conflict with <replaceable>feature</replaceable>.
</para>
<para>
@ -9533,7 +9537,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</glossdef>
</glossentry>
<glossentry id='var-TUNEVALID'><glossterm>TUNEVALID[&lt;feature&gt;]</glossterm>
<glossentry id='var-TUNEVALID'><glossterm>TUNEVALID[<replaceable>feature</replaceable>]</glossterm>
<glossdef>
<para>
Specifies a valid CPU or Application Binary Interface (ABI)
@ -9644,7 +9648,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
The value indicates the target platform configuration.
You typically set this variable from the machine
configuration file (i.e.
<filename>conf/machine/&lt;machine_name&gt;.conf</filename>).
<filename>conf/machine/<replaceable>machine_name</replaceable>.conf</filename>).
</para>
<para>

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

@ -85,7 +85,7 @@
</para>
<para>
The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
<filename>packagename</filename> is the name of the package you want to build
(referred to as the "target" in this manual).
The target often equates to the first part of a recipe's filename
@ -304,7 +304,8 @@
<para>
Here is the bootstrap process for the relocatable toolchain:
<literallayout class='monospaced'>
gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers ->
eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
</literallayout>
<itemizedlist>
<listitem><para><filename>gcc</filename>:
@ -608,13 +609,13 @@
make some dependency and hash information available to the build.
This information includes:
<itemizedlist>
<listitem><para><filename>BB_BASEHASH_task-&lt;taskname&gt;</filename>:
<listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>:
The base hashes for each task in the recipe.
</para></listitem>
<listitem><para><filename>BB_BASEHASH_&lt;filename:taskname&gt;</filename>:
<listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
The base hashes for each dependent task.
</para></listitem>
<listitem><para><filename>BBHASHDEPS_&lt;filename:taskname&gt;</filename>:
<listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
The task dependencies for each task.
</para></listitem>
<listitem><para><filename>BB_TASKHASH</filename>:

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

@ -35,12 +35,12 @@
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
Here is an example:
<literallayout class='monospaced'>
$ source &OE_INIT_FILE; [&lt;build_dir&gt;]
$ source &OE_INIT_FILE; [<replaceable>build_dir</replaceable>]
</literallayout>
</para>
<para>
The <filename>build_dir</filename> argument is optional and specifies the directory the
The <replaceable>build_dir</replaceable> argument is optional and specifies the directory the
OpenEmbedded build system uses for the build -
the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
If you do not specify a Build Directory, it defaults to a directory
@ -53,12 +53,12 @@
<para>
Once the build environment is set up, you can build a target using:
<literallayout class='monospaced'>
$ bitbake &lt;target&gt;
$ bitbake <replaceable>target</replaceable>
</literallayout>
</para>
<para>
The <filename>target</filename> is the name of the recipe you want to build.
The <replaceable>target</replaceable> is the name of the recipe you want to build.
Common targets are the images in <filename>meta/recipes-core/images</filename>,
<filename>meta/recipes-sato/images</filename>, etc. all found in the
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
@ -154,14 +154,14 @@
<title>Task Failures</title>
<para>The log file for shell tasks is available in
<filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
For example, the <filename>compile</filename> task for the QEMU minimal image for the x86
<filename>${WORKDIR}/temp/log.do_<replaceable>taskname</replaceable>.pid</filename>.
For example, the <filename>do_compile</filename> task for the QEMU minimal image for the x86
machine (<filename>qemux86</filename>) might be
<filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</filename>.
To see what
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
runs to generate that log, look at the corresponding
<filename>run.do_taskname.pid</filename> file located in the same directory.
<filename>run.do_<replaceable>taskname</replaceable>.pid</filename> file located in the same directory.
</para>
<para>
@ -203,7 +203,7 @@
$ bitbake matchbox-desktop
.
.
[make some changes to the source code in the work directory]
<replaceable>make some changes to the source code in the work directory</replaceable>
.
.
$ bitbake matchbox-desktop -c compile -f
@ -238,7 +238,7 @@
<para>
Sometimes it can be hard to see why BitBake wants to build
other packages before building a given package you have specified.
The <filename>bitbake -g &lt;targetname&gt;</filename> command
The <filename>bitbake -g <replaceable>targetname</replaceable></filename> command
creates the <filename>pn-buildlist</filename>,
<filename>pn-depends.dot</filename>,
<filename>package-depends.dot</filename>, and
@ -247,7 +247,7 @@
These files show what will be built and the package and task
dependencies, which are useful for debugging problems.
You can use the
<filename>bitbake -g -u depexp &lt;targetname&gt;</filename>
<filename>bitbake -g -u depexp <replaceable>targetname</replaceable></filename>
command to display the results in a more human-readable form.
</para>
</section>
@ -264,7 +264,7 @@
</para>
<para>
The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
The output from <filename>bitbake -DDD -v</filename> <replaceable>targetname</replaceable> can reveal why
BitBake chose a certain version of a package or why BitBake
picked a certain provider.
This command could also help you in a situation where you think BitBake did something
@ -310,7 +310,7 @@
To build a specific recipe (<filename>.bb</filename> file),
you can use the following command form:
<literallayout class='monospaced'>
$ bitbake -b &lt;somepath/somerecipe.bb&gt;
$ bitbake -b <replaceable>somepath</replaceable>/<replaceable>somerecipe</replaceable>.bb
</literallayout>
This command form does not check for dependencies.
Consequently, you should use it
@ -334,7 +334,7 @@
This next example shows the parsing environment for a specific
recipe:
<literallayout class='monospaced'>
$ bitbake -e &lt;recipename&gt;
$ bitbake -e <replaceable>recipename</replaceable>
</literallayout>
</para>
</section>