mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 12:29:55 +00:00
Code Issues Projects Releases Wiki Activity

documentation: Fixed links to "bitbake-term"

Browse Source 
Fixes [YOCTO #11630]

Moving the "Yocto Project Terms" section from the dev-manual to
the ref-manual.  Doing so caused all the links to the id
"bitbake-term" to break.  These had to be individually fixed.

Discovered two unresolved references that were a consequence of
moving that section to the ref-manual.  These were fixed as well.

(From yocto-docs rev: 829ca6b64562f00a69f3956e9636c7edaa90ce16)

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:14:51 -07:00
committed by Richard Purdie
parent dccca9af47
commit 45b16e35b6
13 changed files with 362 additions and 359 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/bsp-guide/bsp.xml
+1 -1
View File
@@ -522,7 +522,7 @@
<para> <para>
This file simply makes This file simply makes
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
aware of the recipes and configuration directories. aware of the recipes and configuration directories.
The file must exist so that the OpenEmbedded build system can recognize the BSP. The file must exist so that the OpenEmbedded build system can recognize the BSP.
</para> </para>
documentation/dev-manual/dev-manual-newbie.xml
-346
View File
@@ -490,352 +490,6 @@
</para> </para>
</section> </section>
<section id='yocto-project-terms'>
<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:
<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.
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>
<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
"<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section.
<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.
</note>
</para></listitem>
<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>
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>
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>
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'>
$ 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'>
$ 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'>
$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.
</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
the
<link linkend='build-directory'>Build Directory</link>
contains user-defined variables that affect every build.
The <filename>meta-poky/conf/distro/poky.conf</filename>
configuration file defines Yocto "distro" configuration
variables used only when building with this policy.
Machine configuration files, which
are located throughout the
<link linkend='source-directory'>Source Directory</link>, define
variables for specific hardware and are only used when building
for that target (e.g. the
<filename>machine/beaglebone.conf</filename> configuration
file defines variables for the Texas Instruments ARM Cortex-A8
development board).
Configuration files end with a <filename>.conf</filename>
filename extension.
</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>
<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>
<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>
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,
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>
The files that BitBake parses when building an image.
In general, Metadata includes recipes, classes, and
configuration files.
In the context of the kernel ("kernel Metadata"),
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>
The build system specific to the Yocto Project.
The OpenEmbedded build system is based on another project known
as "Poky", which uses
<link linkend='bitbake-term'>BitBake</link> as the task
executor.
Throughout the Yocto Project documentation set, the
OpenEmbedded build system is sometimes referred to simply
as "the build system".
If other build systems, such as a host or target build system
are referenced, the documentation clearly states the
difference.
<note>
For some historical information about Poky, see the
<link linkend='poky'>Poky</link> term.
</note>
</para></listitem>
<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
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>
Arbitrary groups of software Recipes.
You use package groups to hold recipes that, when built,
usually accomplish a single task.
For example, a package group could contain the recipes for a
company’s proprietary or value-add software.
Or, the package group could contain the recipes that enable
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>
The term "poky" can mean several things.
In its most general sense, it is an open-source
project that was initially developed by OpenedHand.
With OpenedHand, poky was developed off of the existing
OpenEmbedded build system becoming a commercially
supportable build system for embedded Linux.
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
host system.
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>
(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>
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.
Recipes also describe dependencies for libraries or for other
recipes.
Recipes represent the logical unit of execution, the software
to build, the images to build, and use the
<filename>.bb</filename> file extension.
</para></listitem>
<listitem>
<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>
or expanding a released <filename>poky</filename> tarball.
<note>
Creating a local copy of the <filename>poky</filename>
Git repository is the recommended method for setting up
your Source Directory.
</note>
Sometimes you might hear the term "poky directory" used to refer
to this directory structure.
<note>
The OpenEmbedded build system does not support file or
directory names that contain spaces.
Be sure that the Source Directory you use does not contain
these types of names.
</note></para>
<para>The Source Directory contains BitBake, Documentation,
Metadata and other files that all support the Yocto Project.
Consequently, you must have the Source Directory in place on
your development system in order to do any development using
the Yocto Project.</para>
<para>When you create a local copy of the Git repository, you
can name the repository anything you like.
Throughout much of the documentation, "poky"
is used as the name of the top-level folder of the local copy of
the poky Git repository.
So, for example, cloning the <filename>poky</filename> Git
repository results in a local Git repository whose top-level
folder is also named "poky".</para>
<para>While it is not recommended that you use tarball expansion
to set up the Source Directory, if you do, the top-level
directory name of the Source Directory is derived from the
Yocto Project release tarball.
For example, downloading and unpacking
<filename>&YOCTO_POKY_TARBALL;</filename> results in a
Source Directory whose root folder is named
<filename>&YOCTO_POKY;</filename>.</para>
<para>It is important to understand the differences between the
Source Directory created by unpacking a released tarball as
compared to cloning
<filename>git://git.yoctoproject.org/poky</filename>.
When you unpack a tarball, you have an exact copy of the files
based on the time of release - a fixed release point.
Any changes you make to your local files in the Source Directory
are on top of the release and will remain local only.
On the other hand, when you clone the <filename>poky</filename>
Git repository, you have an active development repository with
access to the upstream repository's branches and tags.
In this case, any local changes you make to the local
Source Directory can be later applied to active development
branches of the upstream <filename>poky</filename> Git
repository.</para>
<para>For more information on concepts related to Git
repositories, branches, and tags, see the
"<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
section.</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>,
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>
</itemizedlist>
</para>
</section>
<section id='licensing'> <section id='licensing'>
<title>Licensing</title> <title>Licensing</title>
documentation/dev-manual/dev-manual-start.xml
+2 -1
View File
@@ -34,7 +34,8 @@
<para> <para>
You can use the OpenEmbedded build system, which uses You can use the OpenEmbedded build system, which uses
<link linkend='bitbake-term'>BitBake</link>, to develop complete Linux <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>,
to develop complete Linux
images and associated user-space applications for architectures based images and associated user-space applications for architectures based
on ARM, MIPS, PowerPC, x86 and x86-64. on ARM, MIPS, PowerPC, x86 and x86-64.
<note> <note>
documentation/kernel-dev/kernel-dev-advanced.xml
+1 -1
View File
@@ -48,7 +48,7 @@
This variable is typically set to the same value as the This variable is typically set to the same value as the
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
variable, which is used by variable, which is used by
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>.
However, in some cases, the variable might instead refer to the However, in some cases, the variable might instead refer to the
underlying platform of the <filename>MACHINE</filename>. underlying platform of the <filename>MACHINE</filename>.
</para> </para>
documentation/kernel-dev/kernel-dev-common.xml
+1 -1
View File
@@ -26,7 +26,7 @@
that you create and prepare your own layer in which to do your that you create and prepare your own layer in which to do your
work. work.
Your layer contains its own Your layer contains its own
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
append files append files
(<filename>.bbappend</filename>) and provides a convenient (<filename>.bbappend</filename>) and provides a convenient
mechanism to create your own recipe files mechanism to create your own recipe files
documentation/ref-manual/closer-look.xml
+2 -2
View File
@@ -34,7 +34,7 @@
Upstream releases, local projects, and SCMs.</para></listitem> Upstream releases, local projects, and SCMs.</para></listitem>
<listitem><para><emphasis>Build System:</emphasis> <listitem><para><emphasis>Build System:</emphasis>
Processes under the control of Processes under the control of
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. <link linkend='bitbake-term'>BitBake</link>.
This block expands on how BitBake fetches source, applies This block expands on how BitBake fetches source, applies
patches, completes compilation, analyzes output for package patches, completes compilation, analyzes output for package
generation, creates and tests packages, generates images, and generation, creates and tests packages, generates images, and
@@ -727,7 +727,7 @@
<para> <para>
The OpenEmbedded build system uses The OpenEmbedded build system uses
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <link linkend='bitbake-term'>BitBake</link>
to produce images. to produce images.
You can see from the You can see from the
<link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>, <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
documentation/ref-manual/faq.xml
+2 -2
View File
@@ -17,7 +17,7 @@
refers to the specific reference build system that refers to the specific reference build system that
the Yocto Project provides. the Yocto Project provides.
Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. and <link linkend='bitbake-term'>BitBake</link>.
Thus, the generic term used here for the build system is Thus, the generic term used here for the build system is
the "OpenEmbedded build system." the "OpenEmbedded build system."
Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
@@ -810,7 +810,7 @@
<para> <para>
This situation results when a build system does This situation results when a build system does
not recognize the environment variables supplied to it by not recognize the environment variables supplied to it by
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. <link linkend='bitbake-term'>BitBake</link>.
The incident that prompted this FAQ entry involved a Makefile The incident that prompted this FAQ entry involved a Makefile
that used an environment variable named that used an environment variable named
<filename>BINDIR</filename> instead of the more standard <filename>BINDIR</filename> instead of the more standard
documentation/ref-manual/introduction.xml
+348
View File
@@ -39,6 +39,354 @@
</para> </para>
</section> </section>
<section id='yocto-project-terms'>
<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:
<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.
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>
<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.
</note>
</para></listitem>
<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>
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>
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>
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'>
$ 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'>
$ 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'>
$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.
</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
the
<link linkend='build-directory'>Build Directory</link>
contains user-defined variables that affect every build.
The <filename>meta-poky/conf/distro/poky.conf</filename>
configuration file defines Yocto "distro" configuration
variables used only when building with this policy.
Machine configuration files, which
are located throughout the
<link linkend='source-directory'>Source Directory</link>, define
variables for specific hardware and are only used when building
for that target (e.g. the
<filename>machine/beaglebone.conf</filename> configuration
file defines variables for the Texas Instruments ARM Cortex-A8
development board).
Configuration files end with a <filename>.conf</filename>
filename extension.
</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>
<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>
<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>
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,
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>
The files that BitBake parses when building an image.
In general, Metadata includes recipes, classes, and
configuration files.
In the context of the kernel ("kernel Metadata"),
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>
The build system specific to the Yocto Project.
The OpenEmbedded build system is based on another project known
as "Poky", which uses
<link linkend='bitbake-term'>BitBake</link> as the task
executor.
Throughout the Yocto Project documentation set, the
OpenEmbedded build system is sometimes referred to simply
as "the build system".
If other build systems, such as a host or target build system
are referenced, the documentation clearly states the
difference.
<note>
For some historical information about Poky, see the
<link linkend='poky'>Poky</link> term.
</note>
</para></listitem>
<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
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>
Arbitrary groups of software Recipes.
You use package groups to hold recipes that, when built,
usually accomplish a single task.
For example, a package group could contain the recipes for a
company’s proprietary or value-add software.
Or, the package group could contain the recipes that enable
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>
The term "poky" can mean several things.
In its most general sense, it is an open-source
project that was initially developed by OpenedHand.
With OpenedHand, poky was developed off of the existing
OpenEmbedded build system becoming a commercially
supportable build system for embedded Linux.
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
host system.
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>
(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>
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.
Recipes also describe dependencies for libraries or for other
recipes.
Recipes represent the logical unit of execution, the software
to build, the images to build, and use the
<filename>.bb</filename> file extension.
</para></listitem>
<listitem>
<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>
or expanding a released <filename>poky</filename> tarball.
<note>
Creating a local copy of the <filename>poky</filename>
Git repository is the recommended method for setting up
your Source Directory.
</note>
Sometimes you might hear the term "poky directory" used to refer
to this directory structure.
<note>
The OpenEmbedded build system does not support file or
directory names that contain spaces.
Be sure that the Source Directory you use does not contain
these types of names.
</note></para>
<para>The Source Directory contains BitBake, Documentation,
Metadata and other files that all support the Yocto Project.
Consequently, you must have the Source Directory in place on
your development system in order to do any development using
the Yocto Project.</para>
<para>When you create a local copy of the Git repository, you
can name the repository anything you like.
Throughout much of the documentation, "poky"
is used as the name of the top-level folder of the local copy of
the poky Git repository.
So, for example, cloning the <filename>poky</filename> Git
repository results in a local Git repository whose top-level
folder is also named "poky".</para>
<para>While it is not recommended that you use tarball expansion
to set up the Source Directory, if you do, the top-level
directory name of the Source Directory is derived from the
Yocto Project release tarball.
For example, downloading and unpacking
<filename>&YOCTO_POKY_TARBALL;</filename> results in a
Source Directory whose root folder is named
<filename>&YOCTO_POKY;</filename>.</para>
<para>It is important to understand the differences between the
Source Directory created by unpacking a released tarball as
compared to cloning
<filename>git://git.yoctoproject.org/poky</filename>.
When you unpack a tarball, you have an exact copy of the files
based on the time of release - a fixed release point.
Any changes you make to your local files in the Source Directory
are on top of the release and will remain local only.
On the other hand, when you clone the <filename>poky</filename>
Git repository, you have an active development repository with
access to the upstream repository's branches and tags.
In this case, any local changes you make to the local
Source Directory can be later applied to active development
branches of the upstream <filename>poky</filename> Git
repository.</para>
<para>For more information on concepts related to Git
repositories, branches, and tags, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#repositories-tags-and-branches'>Repositories, Tags, and Branches</ulink>"
section in the Yocto Project Development Manual.
</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>,
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>
</itemizedlist>
</para>
</section>
<section id='intro-manualoverview'> <section id='intro-manualoverview'>
<title>Documentation Overview</title> <title>Documentation Overview</title>
<para> <para>
documentation/ref-manual/migration.xml
+1 -1
View File
@@ -1218,7 +1218,7 @@
<para> <para>
The following changes have been made to The following changes have been made to
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. <link linkend='bitbake-term'>BitBake</link>.
</para> </para>
<section id='migration-1.6-matching-branch-requirement-for-git-fetching'> <section id='migration-1.6-matching-branch-requirement-for-git-fetching'>
documentation/ref-manual/resources.xml
+1 -1
View File
@@ -89,7 +89,7 @@
Discussion mailing list about OpenEmbedded.</para></listitem> Discussion mailing list about OpenEmbedded.</para></listitem>
<listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> - <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
Discussion mailing list about the Discussion mailing list about the
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <link linkend='bitbake-term'>BitBake</link>
build tool.</para></listitem> build tool.</para></listitem>
<listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> - <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
Discussion mailing list about Discussion mailing list about
documentation/ref-manual/technical-details.xml
+1 -1
View File
@@ -18,7 +18,7 @@
<para> <para>
The The
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <link linkend='bitbake-term'>BitBake</link>
task executor together with various types of configuration files form task executor together with various types of configuration files form
the OpenEmbedded Core. the OpenEmbedded Core.
This section overviews these components by describing their use and This section overviews these components by describing their use and
documentation/ref-manual/usingpoky.xml
+1 -1
View File
@@ -208,7 +208,7 @@
(<filename>qemux86</filename>) might be in (<filename>qemux86</filename>) might be in
<filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile</filename>. <filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile</filename>.
To see the commands To see the commands
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> ran <link linkend='bitbake-term'>BitBake</link> ran
to generate a log, look at the corresponding to generate a log, look at the corresponding
<filename>run.do_</filename><replaceable>taskname</replaceable> <filename>run.do_</filename><replaceable>taskname</replaceable>
file in the same directory. file in the same directory.
documentation/yocto-project-qs/yocto-project-qs.xml
+1 -1
View File
@@ -60,7 +60,7 @@
focus is developers of embedded Linux systems. focus is developers of embedded Linux systems.
Among other things, the Yocto Project uses a build host based Among other things, the Yocto Project uses a build host based
on the OpenEmbedded (OE) project, which uses the on the OpenEmbedded (OE) project, which uses the
<ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink> <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
tool, to construct complete Linux images. tool, to construct complete Linux images.
The BitBake and OE components are combined together to form The BitBake and OE components are combined together to form
a reference build host, historically known as a reference build host, historically known as