[gnome-continuous-yocto/gnomeostree-3.28-rocko: 6385/8267] ref-manual: Fixed links in the "Yocto Project Terms" section.
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 6385/8267] ref-manual: Fixed links in the "Yocto Project Terms" section.
- Date: Sun, 17 Dec 2017 04:46:14 +0000 (UTC)
commit b8b87dd690ef2f828c21937ec82c2d1dab405734
Author: Scott Rifenbark <srifenbark gmail com>
Date: Tue Jun 13 16:50:32 2017 -0700
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>
documentation/ref-manual/introduction.xml | 314 ++++++++++++++++-------------
1 files changed, 178 insertions(+), 136 deletions(-)
---
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
index 58ee073..deaac03 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/documentation/ref-manual/introduction.xml
@@ -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.
+ </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>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.
+ "<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>
+ <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></listitem>
- <listitem><para><emphasis>Image:</emphasis>
+ <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>
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></listitem>
- <listitem><para><emphasis>Package Groups:</emphasis>
+
+ <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>
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>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
