1
0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 00:20:08 +00:00

ref-manual: Fixed links in the "Yocto Project Terms" section.

Fixes [YOCTO #11630]

Moving the "Yocto Project Terms" section from the dev-manual to
the ref-manual caused many links local to that section to be
incorrect.  I scrubbed the section and fixed all the links.

(From yocto-docs rev: 4b795159aa80184f26ff1181a564516840c373b2)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2017-06-13 16:50:32 -07:00
committed by Richard Purdie
parent 45b16e35b6
commit b8b87dd690
+179 -137
View File
@@ -43,110 +43,123 @@
<title>Yocto Project Terms</title>
<para>
Following is a list of terms and definitions users new to the Yocto Project development
environment might find helpful.
While some of these terms are universal, the list includes them just in case:
Following is a list of terms and definitions users new to the Yocto
Project development environment might find helpful.
While some of these terms are universal, the list includes them
just in case:
<itemizedlist>
<listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
a recipe file.
Append files are known as BitBake append files and <filename>.bbappend</filename> files.
The OpenEmbedded build system expects every append file to have a corresponding
recipe (<filename>.bb</filename>) file.
<listitem><para>
<emphasis>Append Files:</emphasis>
Files that append build information to a recipe file.
Append files are known as BitBake append files and
<filename>.bbappend</filename> files.
The OpenEmbedded build system expects every append file to have
a corresponding recipe (<filename>.bb</filename>) file.
Furthermore, the append file and corresponding recipe file
must use the same root filename.
The filenames can differ only in the file type suffix used (e.g.
<filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
</para>
The filenames can differ only in the file type suffix used
(e.g.
<filename>formfactor_0.0.bb</filename> and
<filename>formfactor_0.0.bbappend</filename>).</para>
<para>Information in append files extends or overrides the
information in the similarly-named recipe file.
For an example of an append file in use, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
section in the Yocto Project Development Manual.
<note>
Append files can also use wildcard patterns in their version numbers
so they can be applied to more than one version of the underlying recipe file.
Append files can also use wildcard patterns in their
version numbers so they can be applied to more than one
version of the underlying recipe file.
</note>
</para></listitem>
<listitem><para id='bitbake-term'><emphasis>BitBake:</emphasis>
<listitem><para id='bitbake-term'>
<emphasis>BitBake:</emphasis>
The task executor and scheduler used by the OpenEmbedded build
system to build images.
For more information on BitBake, see the
<ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
</para></listitem>
<listitem>
<para id='build-directory'><emphasis>Build Directory:</emphasis>
<para id='build-directory'>
<emphasis>Build Directory:</emphasis>
This term refers to the area used by the OpenEmbedded build
system for builds.
The area is created when you <filename>source</filename> the
setup environment script that is found in the Source Directory
(i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
(i.e. <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
or
<ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
The
<link linkend='var-TOPDIR'><filename>TOPDIR</filename></link>
variable points to the Build Directory.</para>
<para>
You have a lot of flexibility when creating the Build
Directory.
Following are some examples that show how to create the
directory.
The examples assume your
<link linkend='source-directory'>Source Directory</link> is
named <filename>poky</filename>:
<itemizedlist>
<listitem><para>Create the Build Directory inside your
Source Directory and let the name of the Build
Directory default to <filename>build</filename>:
<literallayout class='monospaced'>
<para>You have a lot of flexibility when creating the Build
Directory.
Following are some examples that show how to create the
directory.
The examples assume your
<link linkend='source-directory'>Source Directory</link> is
named <filename>poky</filename>:
<itemizedlist>
<listitem><para>Create the Build Directory inside your
Source Directory and let the name of the Build
Directory default to <filename>build</filename>:
<literallayout class='monospaced'>
$ cd $HOME/poky
$ source &OE_INIT_FILE;
</literallayout></para></listitem>
<listitem><para>Create the Build Directory inside your
home directory and specifically name it
<filename>test-builds</filename>:
<literallayout class='monospaced'>
</literallayout>
</para></listitem>
<listitem><para>Create the Build Directory inside your
home directory and specifically name it
<filename>test-builds</filename>:
<literallayout class='monospaced'>
$ cd $HOME
$ source poky/&OE_INIT_FILE; test-builds
</literallayout></para></listitem>
<listitem><para>
Provide a directory path and
specifically name the Build Directory.
Any intermediate folders in the pathname must
exist.
This next example creates a Build Directory named
<filename>YP-&POKYVERSION;</filename>
in your home directory within the existing
directory <filename>mybuilds</filename>:
<literallayout class='monospaced'>
</literallayout>
</para></listitem>
<listitem><para>
Provide a directory path and specifically name the
Build Directory.
Any intermediate folders in the pathname must exist.
This next example creates a Build Directory named
<filename>YP-&POKYVERSION;</filename>
in your home directory within the existing
directory <filename>mybuilds</filename>:
<literallayout class='monospaced'>
$cd $HOME
$ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
</literallayout></para></listitem>
</itemizedlist>
<note>
By default, the Build Directory contains
<ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>,
which is a temporary directory the build system uses for
its work.
<filename>TMPDIR</filename> cannot be under NFS.
Thus, by default, the Build Directory cannot be under NFS.
However, if you need the Build Directory to be under NFS,
you can set this up by setting <filename>TMPDIR</filename>
in your <filename>local.conf</filename> file
to use a local drive.
Doing so effectively separates <filename>TMPDIR</filename>
from <filename>TOPDIR</filename>, which is the Build
Directory.
</note>
</para></listitem>
<listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
and inheritance so that commonly used patterns can be defined once and then easily used
in multiple recipes.
For reference information on the Yocto Project classes, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>" chapter of the
Yocto Project Reference Manual.
Class files end with the <filename>.bbclass</filename> filename extension.
</literallayout>
</para></listitem>
</itemizedlist>
<note>
By default, the Build Directory contains
<link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
which is a temporary directory the build system uses for
its work.
<filename>TMPDIR</filename> cannot be under NFS.
Thus, by default, the Build Directory cannot be under NFS.
However, if you need the Build Directory to be under NFS,
you can set this up by setting <filename>TMPDIR</filename>
in your <filename>local.conf</filename> file
to use a local drive.
Doing so effectively separates <filename>TMPDIR</filename>
from <filename>TOPDIR</filename>, which is the Build
Directory.
</note>
</para></listitem>
<listitem><para><emphasis>Configuration File:</emphasis>
<listitem><para>
<emphasis>Classes:</emphasis>
Files that provide for logic encapsulation and inheritance so
that commonly used patterns can be defined once and then
easily used in multiple recipes.
For reference information on the Yocto Project classes, see the
"<link linkend='ref-classes'>Classes</link>" chapter.
Class files end with the <filename>.bbclass</filename>
filename extension.
</para></listitem>
<listitem><para>
<emphasis>Configuration File:</emphasis>
Configuration information in various <filename>.conf</filename>
files provides global definitions of variables.
The <filename>conf/local.conf</filename> configuration file in
@@ -169,52 +182,58 @@
</para></listitem>
<listitem><para id='cross-development-toolchain'>
<emphasis>Cross-Development Toolchain:</emphasis>
In general, a cross-development toolchain is a collection of
software development tools and utilities that run on one
architecture and allow you to develop software for a
different, or targeted, architecture.
These toolchains contain cross-compilers, linkers, and
debuggers that are specific to the target architecture.
</para>
In general, a cross-development toolchain is a collection of
software development tools and utilities that run on one
architecture and allow you to develop software for a
different, or targeted, architecture.
These toolchains contain cross-compilers, linkers, and
debuggers that are specific to the target architecture.</para>
<para>The Yocto Project supports two different cross-development
toolchains:
<itemizedlist>
<listitem><para>A toolchain only used by and within
BitBake when building an image for a target
architecture.</para></listitem>
<listitem><para>A relocatable toolchain used outside of
BitBake by developers when developing applications
that will run on a targeted device.
</para></listitem>
</itemizedlist>
</para>
toolchains:
<itemizedlist>
<listitem><para>
A toolchain only used by and within
BitBake when building an image for a target
architecture.
</para></listitem>
<listitem><para>A relocatable toolchain used outside of
BitBake by developers when developing applications
that will run on a targeted device.
</para></listitem>
</itemizedlist></para>
<para>
Creation of these toolchains is simple and automated.
For information on toolchain concepts as they apply to the
Yocto Project, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
section in the Yocto Project Reference Manual.
You can also find more information on using the
relocatable toolchain in the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
<para>Creation of these toolchains is simple and automated.
For information on toolchain concepts as they apply to the
Yocto Project, see the
"<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
section.
You can also find more information on using the
relocatable toolchain in the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
</para></listitem>
<listitem><para><emphasis>Image:</emphasis>
<listitem><para>
<emphasis>Image:</emphasis>
An image is an artifact of the BitBake build process given
a collection of recipes and related Metadata.
Images are the binary output that run on specific hardware or
QEMU and are used for specific use-cases.
For a list of the supported image types that the Yocto Project provides, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
chapter in the Yocto Project Reference Manual.</para></listitem>
<listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core,
For a list of the supported image types that the Yocto Project
provides, see the
"<link linkend='ref-images'>Images</link>"
chapter.
</para></listitem>
<listitem><para id='layer'>
<emphasis>Layer:</emphasis>
A collection of recipes representing the core,
a BSP, or an application stack.
For a discussion specifically on BSP Layers, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
section in the Yocto Project Board Support Packages (BSP)
Developer's Guide.</para></listitem>
<listitem><para id='metadata'><emphasis>Metadata:</emphasis>
Developer's Guide.
</para></listitem>
<listitem><para id='metadata'>
<emphasis>Metadata:</emphasis>
The files that BitBake parses when building an image.
In general, Metadata includes recipes, classes, and
configuration files.
@@ -222,11 +241,16 @@
it refers to Metadata in the <filename>meta</filename>
branches of the kernel source Git repositories.
</para></listitem>
<listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
This Metadata is found in the <filename>meta</filename> directory of the
<link linkend='source-directory'>Source Directory</link>.</para></listitem>
<listitem><para id='build-system-term'><emphasis>OpenEmbedded Build System:</emphasis>
<listitem><para id='oe-core'>
<emphasis>OE-Core:</emphasis>
A core set of Metadata originating with OpenEmbedded (OE)
that is shared between OE and the Yocto Project.
This Metadata is found in the <filename>meta</filename>
directory of the
<link linkend='source-directory'>Source Directory</link>.
</para></listitem>
<listitem><para id='build-system-term'>
<emphasis>OpenEmbedded Build System:</emphasis>
The build system specific to the Yocto Project.
The OpenEmbedded build system is based on another project known
as "Poky", which uses
@@ -243,26 +267,33 @@
<link linkend='poky'>Poky</link> term.
</note>
</para></listitem>
<listitem><para><emphasis>Package:</emphasis>
<listitem><para>
<emphasis>Package:</emphasis>
In the context of the Yocto Project, this term refers to a
recipe's packaged output produced by BitBake (i.e. a
"baked recipe").
A package is generally the compiled binaries produced from the
recipe's sources.
You "bake" something by running it through BitBake.</para>
<para>It is worth noting that the term "package" can, in general, have subtle
meanings. For example, the packages referred to in the
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>" section are
compiled binaries that, when installed, add functionality to your Linux
<para>It is worth noting that the term "package" can,
in general, have subtle meanings.
For example, the packages referred to in the
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>"
section in the Yocto Project Quick Start are compiled binaries
that, when installed, add functionality to your Linux
distribution.</para>
<para>Another point worth noting is that historically within the Yocto Project,
recipes were referred to as packages - thus, the existence of several BitBake
variables that are seemingly mis-named,
(e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
<ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
<para>Another point worth noting is that historically within
the Yocto Project, recipes were referred to as packages - thus,
the existence of several BitBake variables that are seemingly
mis-named,
(e.g. <link linkend='var-PR'><filename>PR</filename></link>,
<link linkend='var-PV'><filename>PV</filename></link>, and
<link linkend='var-PE'><filename>PE</filename></link>).
</para></listitem>
<listitem><para><emphasis>Package Groups:</emphasis>
<listitem><para>
<emphasis>Package Groups:</emphasis>
Arbitrary groups of software Recipes.
You use package groups to hold recipes that, when built,
usually accomplish a single task.
@@ -272,8 +303,10 @@
graphics.
A package group is really just another recipe.
Because package group files are recipes, they end with the
<filename>.bb</filename> filename extension.</para></listitem>
<listitem><para id='poky'><emphasis>Poky:</emphasis>
<filename>.bb</filename> filename extension.
</para></listitem>
<listitem><para id='poky'>
<emphasis>Poky:</emphasis>
The term "poky" can mean several things.
In its most general sense, it is an open-source
project that was initially developed by OpenedHand.
@@ -283,6 +316,7 @@
After Intel Corporation acquired OpenedHand, the
project poky became the basis for the Yocto Project's
build system.</para>
<para>Within the Yocto Project source repositories,
<filename>poky</filename> exists as a separate Git
repository you can clone to yield a local copy on your
@@ -290,13 +324,15 @@
Thus, "poky" can refer to the local copy of the Source
Directory used for development within the Yocto
Project.</para>
<para>Finally, "poky" can refer to the default
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
<link linkend='var-DISTRO'><filename>DISTRO</filename></link>
(i.e. distribution) created when you use the Yocto
Project in conjunction with the
<filename>poky</filename> repository to build an image.
</para></listitem>
<listitem><para><emphasis>Recipe:</emphasis>
<listitem><para>
<emphasis>Recipe:</emphasis>
A set of instructions for building packages.
A recipe describes where you get source code, which patches
to apply, how to configure the source, how to compile it and so on.
@@ -307,7 +343,8 @@
<filename>.bb</filename> file extension.
</para></listitem>
<listitem>
<para id='source-directory'><emphasis>Source Directory:</emphasis>
<para id='source-directory'>
<emphasis>Source Directory:</emphasis>
This term refers to the directory structure created as a result
of creating a local copy of the <filename>poky</filename> Git
repository <filename>git://git.yoctoproject.org/poky</filename>
@@ -373,16 +410,21 @@
</para></listitem>
<listitem><para><emphasis>Task:</emphasis>
A unit of execution for BitBake (e.g.
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink>,
<link linkend='ref-tasks-compile'><filename>do_compile</filename></link>,
<link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>,
<link linkend='ref-tasks-patch'><filename>do_patch</filename></link>,
and so forth).
</para></listitem>
<listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
that are not local to the development system but located in a master area that is controlled
by the maintainer of the source code.
For example, in order for a developer to work on a particular piece of code, they need to
first get a copy of it from an "upstream" source.</para></listitem>
<listitem><para>
<emphasis>Upstream:</emphasis>
A reference to source code or repositories
that are not local to the development system but located in a
master area that is controlled by the maintainer of the source
code.
For example, in order for a developer to work on a particular
piece of code, they need to first get a copy of it from an
"upstream" source.
</para></listitem>
</itemizedlist>
</para>
</section>