mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-09 17:39:31 +00:00
Code Issues Projects Releases Wiki Activity

ref-manual, overview-manual, yocto-project-qs: Moved YP Components

Browse Source 
Fixes [YOCTO #12370]

Moved the "Yocto Project Components" section from the ref-manual to
the overview-manual.  This material falls into the "concepts" area
and is being moved from the ref-manual.  One link in the
yocto-project-qs was affected and updated.  Oh... another link in the
ref-manual for a variable also fixed.

(From yocto-docs rev: 75ced485bb223373591eb41d1b343d0c2b315345)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2018-01-10 12:35:02 -08:00
committed by Richard Purdie
parent 8097a978ce
commit 707224b57a
4 changed files with 314 additions and 286 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/ref-manual/ref-variables.xml
+3 -2
View File
@@ -10709,8 +10709,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
</literallayout>
For more information see:
<link linkend='metadata-virtual-providers'>Metadata (Virtual Providers)</link>
For more information, see the
"<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#metadata-virtual-providers'>Metadata (Virtual Providers)</ulink>"
section in the Yocto Project Overview Manual.
<note>
If you set <filename>PREFERRED_PROVIDER</filename>
for a <filename>virtual/*</filename> item, then any
documentation/ref-manual/technical-details.xml
-222
View File
@@ -13,228 +13,6 @@
x32, Wayland support, and Licenses.
</para>
<section id='usingpoky-components'>
<title>Yocto Project Components</title>
<para>
The
<link linkend='bitbake-term'>BitBake</link>
task executor together with various types of configuration files form
the OpenEmbedded Core.
This section overviews these components by describing their use and
how they interact.
</para>
<para>
BitBake handles the parsing and execution of the data files.
The data itself is of various types:
<itemizedlist>
<listitem><para><emphasis>Recipes:</emphasis> Provides details
about particular pieces of software.
</para></listitem>
<listitem><para><emphasis>Class Data:</emphasis> Abstracts
common build information (e.g. how to build a Linux kernel).
</para></listitem>
<listitem><para><emphasis>Configuration Data:</emphasis> Defines
machine-specific settings, policy decisions, and so forth.
Configuration data acts as the glue to bind everything
together.
</para></listitem>
</itemizedlist>
</para>
<para>
BitBake knows how to combine multiple data sources together and refers
to each data source as a layer.
For information on layers, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
Creating Layers</ulink>" section of the Yocto Project Development
Tasks Manual.
</para>
<para>
Following are some brief details on these core components.
For additional information on how these components interact during
a build, see the
"<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#development-concepts'>Development Concepts</ulink>"
section in the Yocto Project Overview Manual.
</para>
<section id='usingpoky-components-bitbake'>
<title>BitBake</title>
<para>
BitBake is the tool at the heart of the OpenEmbedded build system
and is responsible for parsing the
<link linkend='metadata'>Metadata</link>,
generating a list of tasks from it, and then executing those tasks.
</para>
<para>
This section briefly introduces BitBake.
If you want more information on BitBake, see the
<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
</para>
<para>
To see a list of the options BitBake supports, use either of
the following commands:
<literallayout class='monospaced'>
$ bitbake -h
$ bitbake --help
</literallayout>
</para>
<para>
The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
<filename>packagename</filename> is the name of the package you want to build
(referred to as the "target" in this manual).
The target often equates to the first part of a recipe's filename
(e.g. "foo" for a recipe named
<filename>foo_1.3.0-r0.bb</filename>).
So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
might type the following:
<literallayout class='monospaced'>
$ bitbake matchbox-desktop
</literallayout>
Several different versions of <filename>matchbox-desktop</filename> might exist.
BitBake chooses the one selected by the distribution configuration.
You can get more details about how BitBake chooses between different
target versions and providers in the
"<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
section of the BitBake User Manual.
</para>
<para>
BitBake also tries to execute any dependent tasks first.
So for example, before building <filename>matchbox-desktop</filename>, BitBake
would build a cross compiler and <filename>glibc</filename> if they had not already
been built.
</para>
<para>
A useful BitBake option to consider is the <filename>-k</filename> or
<filename>--continue</filename> option.
This option instructs BitBake to try and continue processing the job
as long as possible even after encountering an error.
When an error occurs, the target that
failed and those that depend on it cannot be remade.
However, when you use this option other dependencies can still be
processed.
</para>
</section>
<section id='usingpoky-components-metadata'>
<title>Metadata (Recipes)</title>
<para>
Files that have the <filename>.bb</filename> suffix are "recipes"
files.
In general, a recipe contains information about a single piece of
software.
This information includes the location from which to download the
unaltered source, any source patches to be applied to that source
(if needed), which special configuration options to apply,
how to compile the source files, and how to package the compiled
output.
</para>
<para>
The term "package" is sometimes used to refer to recipes. However,
since the word "package" is used for the packaged output from the OpenEmbedded
build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
this document avoids using the term "package" when referring to recipes.
</para>
</section>
<section id='metadata-virtual-providers'>
<title>Metadata (Virtual Providers)</title>
<para>
Prior to the build, if you know that several different recipes
provide the same functionality, you can use a virtual provider
(i.e. <filename>virtual/*</filename>) as a placeholder for the
actual provider.
The actual provider would be determined at build
time.
In this case, you should add <filename>virtual/*</filename>
to <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
rather than listing the specified provider.
You would select the actual provider by setting the
<link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>
variable (i.e. <filename>PREFERRED_PROVIDER_virtual/*</filename>)
in the build's configuration file (e.g.
<filename>poky/build/conf/local.conf</filename>).
<note>
Any recipe that PROVIDES a <filename>virtual/*</filename> item
that is ultimately not selected through
<filename>PREFERRED_PROVIDER</filename> does not get built.
Preventing these recipes from building is usually the desired
behavior since this mechanism's purpose is to select between
mutually exclusive alternative providers.
</note>
</para>
<para>
The following lists specific examples of virtual providers:
<itemizedlist>
<listitem><para>
<filename>virtual/mesa</filename>:
Provides <filename>gbm.pc</filename>.
</para></listitem>
<listitem><para>
<filename>virtual/egl</filename>:
Provides <filename>egl.pc</filename> and possibly
<filename>wayland-egl.pc</filename>.
</para></listitem>
<listitem><para>
<filename>virtual/libgl</filename>:
Provides <filename>gl.pc</filename> (i.e. libGL).
</para></listitem>
<listitem><para>
<filename>virtual/libgles1</filename>:
Provides <filename>glesv1_cm.pc</filename>
(i.e. libGLESv1_CM).
</para></listitem>
<listitem><para>
<filename>virtual/libgles2</filename>:
Provides <filename>glesv2.pc</filename> (i.e. libGLESv2).
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='usingpoky-components-classes'>
<title>Classes</title>
<para>
Class files (<filename>.bbclass</filename>) contain information that
is useful to share between
<link linkend='metadata'>Metadata</link> files.
An example is the
<link linkend='ref-classes-autotools'><filename>autotools</filename></link>
class, which contains common settings for any application that
Autotools uses.
The "<link linkend='ref-classes'>Classes</link>" chapter provides
details about classes and how to use them.
</para>
</section>
<section id='usingpoky-components-configuration'>
<title>Configuration</title>
<para>
The configuration files (<filename>.conf</filename>) define various configuration variables
that govern the OpenEmbedded build process.
These files fall into several areas that define machine configuration options,
distribution configuration options, compiler tuning options, general common configuration
options, and user configuration options in <filename>local.conf</filename>, which is found
in the
<link linkend='build-directory'>Build Directory</link>.
</para>
</section>
</section>
<section id="cross-development-toolchain-generation">
<title>Cross-Development Toolchain Generation</title>