ref-manual: Re-ordered flow for detailed process sections.
Fixes [YOCTO #2808] Based on feedback from Dave Stewart, I have rearranged the sub- section flow of the topics to match that of an actual build. This meant moving the BitBake section higher up in the order. (From yocto-docs rev: 3e62dd70dab596c3a55815c1ad3f1578a9f3400f) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
b359e9a981
commit
7b70da93bc
|
|
@ -743,223 +743,6 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id="package-feeds-dev-environment">
|
||||
<title>Package Feeds</title>
|
||||
|
||||
<para>
|
||||
When the OpenEmbedded build system generates an image or an SDK,
|
||||
it gets the packages from a package feed area located in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
||||
The main
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
figure shows this package feeds area in the upper-right corner.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section looks a little closer into the package feeds area used
|
||||
by the build system.
|
||||
Here is a more detailed look at the area:
|
||||
<imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Package feeds are an intermediary step in the build process.
|
||||
BitBake generates packages whose type is defined by the
|
||||
<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
|
||||
variable.
|
||||
Before placing the packages into package feeds,
|
||||
the build process validates them with generated output quality
|
||||
assurance checks through the
|
||||
<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
|
||||
class.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The package feed area resides in
|
||||
<filename>tmp/deploy</filename> of the Build Directory.
|
||||
Folders are created that correspond to the package type
|
||||
(IPK, DEB, or RPM) created.
|
||||
Further organization is derived through the value of the
|
||||
<link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
|
||||
variable for each package.
|
||||
For example, packages can exist for the i586 or qemux86
|
||||
architectures.
|
||||
The package files themselves reside within the appropriate
|
||||
architecture folder.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake uses the <filename>do_package_write_*</filename> task to
|
||||
place generated packages into the package holding area (e.g.
|
||||
<filename>do_package_write_ipk</filename> for IPK packages).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='images-dev-environment'>
|
||||
<title>Images</title>
|
||||
|
||||
<para>
|
||||
The images produced by the OpenEmbedded build system
|
||||
are compressed forms of the
|
||||
root filesystems that are ready to boot on a target device.
|
||||
You can see from the main
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
figure that BitBake output in part consists of images.
|
||||
This section is going to look more closely at this output:
|
||||
<imagedata fileref="figures/images.png" align="center" width="6in" depth="5in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For a list of example images that the Yocto Project provides,
|
||||
the
|
||||
"<link linkend='ref-images'>Images</link>" chapter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Images are written out to the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
inside the <filename>deploy/images</filename> folder as shown
|
||||
in the figure.
|
||||
This folder contains any files expected to be loaded on the
|
||||
target device.
|
||||
The
|
||||
<link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
|
||||
variable points to the <filename>deploy</filename> directory.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><kernel-image></filename>:
|
||||
A kernel binary file.
|
||||
The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
|
||||
variable setting determines the naming scheme for the
|
||||
kernel image file.
|
||||
Depending on that variable, the file could begin with
|
||||
a variety of naming strings.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple image files.</para></listitem>
|
||||
<listitem><para><filename><root-filesystem-image></filename>:
|
||||
Root filesystems for the target device (e.g.
|
||||
<filename>*.ext3</filename> or <filename>*.bz2</filename>
|
||||
files).
|
||||
The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
||||
variable setting determines the root filesystem image
|
||||
type.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple root filesystems.</para></listitem>
|
||||
<listitem><para><filename><kernel-modules></filename>:
|
||||
Tarballs that contain all the modules built for the kernel.
|
||||
Kernel module tarballs exist for legacy purposes and
|
||||
can be suppressed by setting the
|
||||
<link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
|
||||
variable to "0".
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple kernel module tarballs.
|
||||
</para></listitem>
|
||||
<listitem><para><filename><bootloaders></filename>:
|
||||
Bootloaders supporting the image, if applicable to the
|
||||
target machine.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple bootloaders.
|
||||
</para></listitem>
|
||||
<listitem><para><filename><symlinks></filename>:
|
||||
The <filename>deploy/images</filename> folder contains
|
||||
a symbolic link that points to the most recently built file
|
||||
for each machine.
|
||||
These links might be useful for external scripts that
|
||||
need to obtain the latest version of each file.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-dev-environment'>
|
||||
<title>Application Development SDK</title>
|
||||
|
||||
<para>
|
||||
In the overview figure of the
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
the output labeled "Application Development SDK" represents an
|
||||
SDK.
|
||||
This section is going to take a closer look at this output:
|
||||
<imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The specific form of this output is a self-extracting
|
||||
SDK installer (<filename>*.sh</filename>) that, when run,
|
||||
installs the SDK, which consists of a cross-development
|
||||
toolchain, a set of libraries and headers, and an SDK
|
||||
environment setup script.
|
||||
Running this installer essentially sets up your
|
||||
cross-development environment.
|
||||
You can think of the cross-toolchain as the "host"
|
||||
part because it runs on the SDK machine.
|
||||
You can think of the libraries and headers as the "target"
|
||||
part because they are built for the target hardware.
|
||||
The setup script is added so that you can initialize the
|
||||
environment before using the tools.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The Yocto Project supports several methods by which you can
|
||||
set up this cross-development environment.
|
||||
These methods include downloading pre-built SDK installers,
|
||||
building and installing your own SDK installer, or running
|
||||
an Application Development Toolkit (ADT) installer to
|
||||
install not just cross-development toolchains
|
||||
but also additional tools to help in this type of
|
||||
development.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For background information on cross-development toolchains
|
||||
in the Yocto Project development environment, see the
|
||||
"<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
|
||||
section.
|
||||
For information on setting up a cross-development
|
||||
environment, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
|
||||
section in the Yocto Project Application Developer's Guide.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Once built, the SDK installers are written out to the
|
||||
<filename>deploy/sdk</filename> folder inside the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
as shown in the figure at the beginning of this section.
|
||||
Several variables exist that help configure these files:
|
||||
<itemizedlist>
|
||||
<listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
|
||||
Points to the <filename>deploy</filename>
|
||||
directory.</para></listitem>
|
||||
<listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
|
||||
Specifies the architecture of the machine
|
||||
on which the cross-development tools are run to
|
||||
create packages for the target hardware.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
|
||||
Lists the features to include in the "target" part
|
||||
of the SDK.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
|
||||
Lists packages that make up the host
|
||||
part of the SDK (i.e. the part that runs on
|
||||
the <filename>SDKMACHINE</filename>).
|
||||
When you use
|
||||
<filename>bitbake -c populate_sdk <imagename></filename>
|
||||
to create the SDK, a set of default packages
|
||||
apply.
|
||||
This variable allows you to add more packages.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
|
||||
Lists packages that make up the target part
|
||||
of the SDK (i.e. the part built for the
|
||||
target hardware).
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='bitbake-dev-environment'>
|
||||
<title>BitBake</title>
|
||||
|
||||
|
|
@ -1190,6 +973,223 @@
|
|||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="package-feeds-dev-environment">
|
||||
<title>Package Feeds</title>
|
||||
|
||||
<para>
|
||||
When the OpenEmbedded build system generates an image or an SDK,
|
||||
it gets the packages from a package feed area located in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
||||
The main
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
figure shows this package feeds area in the upper-right corner.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section looks a little closer into the package feeds area used
|
||||
by the build system.
|
||||
Here is a more detailed look at the area:
|
||||
<imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Package feeds are an intermediary step in the build process.
|
||||
BitBake generates packages whose type is defined by the
|
||||
<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
|
||||
variable.
|
||||
Before placing the packages into package feeds,
|
||||
the build process validates them with generated output quality
|
||||
assurance checks through the
|
||||
<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
|
||||
class.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The package feed area resides in
|
||||
<filename>tmp/deploy</filename> of the Build Directory.
|
||||
Folders are created that correspond to the package type
|
||||
(IPK, DEB, or RPM) created.
|
||||
Further organization is derived through the value of the
|
||||
<link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
|
||||
variable for each package.
|
||||
For example, packages can exist for the i586 or qemux86
|
||||
architectures.
|
||||
The package files themselves reside within the appropriate
|
||||
architecture folder.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
BitBake uses the <filename>do_package_write_*</filename> task to
|
||||
place generated packages into the package holding area (e.g.
|
||||
<filename>do_package_write_ipk</filename> for IPK packages).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='images-dev-environment'>
|
||||
<title>Images</title>
|
||||
|
||||
<para>
|
||||
The images produced by the OpenEmbedded build system
|
||||
are compressed forms of the
|
||||
root filesystems that are ready to boot on a target device.
|
||||
You can see from the main
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
figure that BitBake output in part consists of images.
|
||||
This section is going to look more closely at this output:
|
||||
<imagedata fileref="figures/images.png" align="center" width="6in" depth="5in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For a list of example images that the Yocto Project provides,
|
||||
the
|
||||
"<link linkend='ref-images'>Images</link>" chapter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Images are written out to the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
inside the <filename>deploy/images</filename> folder as shown
|
||||
in the figure.
|
||||
This folder contains any files expected to be loaded on the
|
||||
target device.
|
||||
The
|
||||
<link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
|
||||
variable points to the <filename>deploy</filename> directory.
|
||||
<itemizedlist>
|
||||
<listitem><para><filename><kernel-image></filename>:
|
||||
A kernel binary file.
|
||||
The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
|
||||
variable setting determines the naming scheme for the
|
||||
kernel image file.
|
||||
Depending on that variable, the file could begin with
|
||||
a variety of naming strings.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple image files.</para></listitem>
|
||||
<listitem><para><filename><root-filesystem-image></filename>:
|
||||
Root filesystems for the target device (e.g.
|
||||
<filename>*.ext3</filename> or <filename>*.bz2</filename>
|
||||
files).
|
||||
The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
|
||||
variable setting determines the root filesystem image
|
||||
type.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple root filesystems.</para></listitem>
|
||||
<listitem><para><filename><kernel-modules></filename>:
|
||||
Tarballs that contain all the modules built for the kernel.
|
||||
Kernel module tarballs exist for legacy purposes and
|
||||
can be suppressed by setting the
|
||||
<link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
|
||||
variable to "0".
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple kernel module tarballs.
|
||||
</para></listitem>
|
||||
<listitem><para><filename><bootloaders></filename>:
|
||||
Bootloaders supporting the image, if applicable to the
|
||||
target machine.
|
||||
The <filename>deploy/images</filename> directory can
|
||||
contain multiple bootloaders.
|
||||
</para></listitem>
|
||||
<listitem><para><filename><symlinks></filename>:
|
||||
The <filename>deploy/images</filename> folder contains
|
||||
a symbolic link that points to the most recently built file
|
||||
for each machine.
|
||||
These links might be useful for external scripts that
|
||||
need to obtain the latest version of each file.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-dev-environment'>
|
||||
<title>Application Development SDK</title>
|
||||
|
||||
<para>
|
||||
In the overview figure of the
|
||||
<link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link>
|
||||
the output labeled "Application Development SDK" represents an
|
||||
SDK.
|
||||
This section is going to take a closer look at this output:
|
||||
<imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The specific form of this output is a self-extracting
|
||||
SDK installer (<filename>*.sh</filename>) that, when run,
|
||||
installs the SDK, which consists of a cross-development
|
||||
toolchain, a set of libraries and headers, and an SDK
|
||||
environment setup script.
|
||||
Running this installer essentially sets up your
|
||||
cross-development environment.
|
||||
You can think of the cross-toolchain as the "host"
|
||||
part because it runs on the SDK machine.
|
||||
You can think of the libraries and headers as the "target"
|
||||
part because they are built for the target hardware.
|
||||
The setup script is added so that you can initialize the
|
||||
environment before using the tools.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The Yocto Project supports several methods by which you can
|
||||
set up this cross-development environment.
|
||||
These methods include downloading pre-built SDK installers,
|
||||
building and installing your own SDK installer, or running
|
||||
an Application Development Toolkit (ADT) installer to
|
||||
install not just cross-development toolchains
|
||||
but also additional tools to help in this type of
|
||||
development.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For background information on cross-development toolchains
|
||||
in the Yocto Project development environment, see the
|
||||
"<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
|
||||
section.
|
||||
For information on setting up a cross-development
|
||||
environment, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
|
||||
section in the Yocto Project Application Developer's Guide.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Once built, the SDK installers are written out to the
|
||||
<filename>deploy/sdk</filename> folder inside the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
as shown in the figure at the beginning of this section.
|
||||
Several variables exist that help configure these files:
|
||||
<itemizedlist>
|
||||
<listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
|
||||
Points to the <filename>deploy</filename>
|
||||
directory.</para></listitem>
|
||||
<listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
|
||||
Specifies the architecture of the machine
|
||||
on which the cross-development tools are run to
|
||||
create packages for the target hardware.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
|
||||
Lists the features to include in the "target" part
|
||||
of the SDK.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
|
||||
Lists packages that make up the host
|
||||
part of the SDK (i.e. the part that runs on
|
||||
the <filename>SDKMACHINE</filename>).
|
||||
When you use
|
||||
<filename>bitbake -c populate_sdk <imagename></filename>
|
||||
to create the SDK, a set of default packages
|
||||
apply.
|
||||
This variable allows you to add more packages.
|
||||
</para></listitem>
|
||||
<listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
|
||||
Lists packages that make up the target part
|
||||
of the SDK (i.e. the part built for the
|
||||
target hardware).
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="cross-development-toolchain-generation">
|
||||
|
|
|
|||
Loading…
Reference in New Issue