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