<title>Development Checkouts</title>
<para>
Development using the Yocto Project requires a local
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
You can set up the source directory by downloading a Yocto Project release tarball and unpacking it,
or by cloning a copy of the upstream
<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
<para>
The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
This file resides in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
within the <filename>meta/conf/</filename> directory.
BitBake finds it by examining its
<link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
Class files are identified by the extension <filename>.bbclass</filename> and are usually placed
in a <filename>classes/</filename> directory beneath the
<filename>meta*/</filename> directory found in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
<filename>.conf</filename> files in the <filename>conf</filename> directory.
Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
<filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename>
variable defined in the <filename>local.conf</filename> configuration file,
which is located in the <filename>conf</filename> folder of the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
When defining the variable, you can specify one or more package types.
Since images are generated from packages, a packaging class is
needed to enable image generation.
you can use this class to specify those packages and associate the users and groups
with those packages.
The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
- recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+ recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
provides a simple exmample that shows how to add three
users and groups to two packages.
See the <filename>useradd-example.bb</filename> for more information on how to
<link linkend='var-B'><filename>B</filename></link> variable to point to the directory in
which the OpenEmbedded build system places the generated objects built from the recipes.
By default, the <filename>B</filename> directory is set to the following, which is separate from the
- source directory (<filename>S</filename>):
+ Source Directory (<filename>S</filename>):
<literallayout class='monospaced'>
${WORKDIR}/${BPN}-{PV}/
</literallayout>
Thus far, this chapter has discussed only the most useful and important
classes.
However, other classes exist within the <filename>meta/classes</filename> directory
- in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
You can examine the <filename>.bbclass</filename> files directly for more
information.
</para>
You can disable the feature without affecting
other existing distro configurations that need PulseAudio support
by adding "pulseaudio" to
- DISTRO_FEATURES_BACKFILL_CONSIDERED
+ <filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename>
in your distro's <filename>.conf</filename> file.
Adding the feature to this variable when it also
exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
You can disable RTC support for your device without
affecting other machines that need RTC support
by adding the feature to your machine's
- MACHINE_FEATURES_BACKFILL_CONSIDERED
+ <filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename>
list in the machine's <filename>.conf</filename> file.
Adding the feature to this variable when it also
exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>
<title>Source Directory Structure</title>
<para>
- The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> consists of several components.
+ The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> consists of several components.
Understanding them and knowing where they are located is key to using the Yocto Project well.
- This chapter describes the source directory and gives information about the various
+ This chapter describes the Source Directory and gives information about the various
files and directories.
</para>
<para>
- For information on how to establish a local source directory on your development system, see the
+ For information on how to establish a local Source Directory on your development system, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
section in the Yocto Project Development Manual.
</para>
<title><filename>bitbake/</filename></title>
<para>
- The <ulink url='source-directory'>source directory</ulink>
+ The <ulink url='source-directory'>Source Directory</ulink>
includes a copy of BitBake for ease of use.
The copy usually matches the current stable BitBake release from the BitBake project.
BitBake, a metadata interpreter, reads the Yocto Project metadata and runs the tasks
When you run the <filename>bitbake</filename> command, the wrapper script in
<filename>scripts/</filename> is executed to run the main BitBake executable,
which resides in the <filename>bitbake/bin/</filename> directory.
- Sourcing the <link linkend="structure-core-script">oe-init-build-env</link>
+ Sourcing the <link linkend="structure-core-script">&OE_INIT_FILE;</link>
script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
directories (in that order) into the shell's <filename>PATH</filename> environment
variable.
This directory contains user configuration files and the output
generated by the OpenEmbedded build system in its standard configuration where
the source tree is combined with the output.
- The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+ The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
is created initially when you <filename>source</filename>
- the OpenEmbedded build environment setup script <filename>oe-init-build-env</filename>.
+ the OpenEmbedded build environment setup script <filename>&OE_INIT_FILE;</filename>.
</para>
<para>
It is also possible to place output and configuration
files in a directory separate from the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
by providing a directory name when you <filename>source</filename>
the setup script.
- For information on separating output from your local source directory files, see <link
- linkend='structure-core-script'>oe-init-build-env</link>.
+ For information on separating output from your local Source Directory files, see <link
+ linkend='structure-core-script'>&OE_INIT_FILE;</link>.
</para>
</section>
<para>
This directory contains various integration scripts that implement
extra functionality in the Yocto Project environment (e.g. QEMU scripts).
- The <link linkend="structure-core-script">oe-init-build-env</link> script appends this
+ The <link linkend="structure-core-script">&OE_INIT_FILE;</link> script appends this
directory to the shell's <filename>PATH</filename> environment variable.
</para>
</section>
<section id='structure-core-script'>
- <title><filename>oe-init-build-env</filename></title>
+ <title><filename>&OE_INIT_FILE;</filename></title>
<para>
This script sets up the OpenEmbedded build environment.
</para>
<para>
- By default, running this script without a build directory argument creates the
+ By default, running this script without a Build Directory argument creates the
<filename>build</filename> directory.
- If you provide a build directory argument when you <filename>source</filename>
+ If you provide a Build Directory argument when you <filename>source</filename>
the script, you direct OpenEmbedded build system to create a
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> of your choice.
- For example, the following command creates a build directory named
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> of your choice.
+ For example, the following command creates a Build Directory named
<filename>mybuilds</filename> that is outside of the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
<literallayout class='monospaced'>
- $ source oe-init-build-env ~/mybuilds
+ $ source &OE_INIT_FILE; ~/mybuilds
</literallayout>
</para>
</section>
data.
Packages that need to share output with other packages do so within this directory.
The directory is subdivided by architecture so multiple builds can run within
- the one build directory.
+ the one Build Directory.
</para>
</section>
<glossentry id='var-B'><glossterm>B</glossterm>
<glossdef>
<para>
- The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
- The OpenEmbedded build system places generated objects into the build directory
+ The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+ The OpenEmbedded build system places generated objects into the Build Directory
during a recipe's build process.
By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
directory:
</literallayout></para>
<para>Use the <filename>BBMASK</filename> variable from within the
<filename>conf/local.conf</filename> file found
- in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.</para>
+ in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.</para>
</glossdef>
</glossentry>
<glossdef>
<para>Lists the layers to enable during the build.
This variable is defined in the <filename>bblayers.conf</filename> configuration
- file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
Here is an example:
<literallayout class='monospaced'>
BBLAYERS = " \
than <filename>/usr/bin</filename>.
You can find a list of these variables at the top of the
<filename>/meta/conf/bitbake.conf</filename> file in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
</note>
</glossdef>
</glossentry>
Specifies the list of packages to be added to the image.
This variable should only be set in the <filename>local.conf</filename>
configuration file found in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
</para>
<para>
This directory is self-maintaining and you should not have
to touch it.
By default, the directory is <filename>downloads</filename> in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
<literallayout class='monospaced'>
#DL_DIR ?= "${TOPDIR}/downloads"
</literallayout>
than <filename>/usr/bin</filename>.
You can find a list of these variables at the top of the
<filename>/meta/conf/bitbake.conf</filename> file in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
</note>
<para>
The default value for the <filename>FILESPATH</filename> variable is defined
in the <filename>base.bbclass</filename> class found in
<filename>meta/classes</filename> in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
<literallayout class='monospaced'>
FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
"${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", \
<para>
By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
is located in the <filename>meta/files</filename> folder in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
If you create your own file permissions setting table, you should place it in your
layer or the distros layer.
</para>
<para>
You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
<filename>conf/local.conf</filename> file, which is found in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, to
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, to
point to your custom <filename>fs-perms.txt</filename>.
You can specify more than a single file permissions setting table.
The paths you specify to these files must be defined within the
Values for this variable are set in the kernel's recipe file and the kernel's
append file.
For example, if you are using the Yocto Project kernel that is based on the
- Linux 3.2 kernel, the kernel recipe file is the
- <filename>meta/recipes-kernel/linux/linux-yocto_3.2.bb</filename> file.
- Following is the default value for <filename>KBRANCH</filename> and the five overrides
- for the architectures the Yocto Project supports:
+ Linux 3.4 kernel, the kernel recipe file is the
+ <filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename> file.
+ Following is the default value for <filename>KBRANCH</filename> and the default
+ override for the architectures the Yocto Project supports:
<literallayout class='monospaced'>
- KBRANCH = "standard/default/base"
- KBRANCH_qemux86 = "standard/default/common-pc/base"
- KBRANCH_qemux86-64 = "standard/default/common-pc-64/base"
- KBRANCH_qemuppc = "standard/default/qemu-ppc32"
- KBRANCH_qemumips = "standard/default/mti-malta32-be"
- KBRANCH_qemuarm = "standard/default/arm-versatile-926ejs"
+ KBRANCH_DEFAULT = "standard/base"
+ KBRANCH = "${KBRANCH_DEFAULT}"
</literallayout>
- Each of the above branches exist in the <filename>linux-yocto-3.2</filename> kernel Git
- repository <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.2/refs/heads'></ulink>.
+ This branch exists in the <filename>linux-yocto-3.4</filename> kernel Git
+ repository <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
</para>
<para>
The kernel's append file is located in the BSP layer for a given machine.
For example, the kernel append file for the Crown Bay BSP is in the
<filename>meta-intel</filename> Git repository and is named
- <filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>.
+ <filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>.
Here are the related statements from the append file:
<literallayout class='monospaced'>
COMPATIBLE_MACHINE_crownbay = "crownbay"
KMACHINE_crownbay = "crownbay"
- KBRANCH_crownbay = "standard/default/crownbay"
-
+ KBRANCH_crownbay = "standard/crownbay"
+
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
KMACHINE_crownbay-noemgd = "crownbay"
- KBRANCH_crownbay-noemgd = "standard/default/crownbay"
+ KBRANCH_crownbay-noemgd = "standard/crownbay"
</literallayout>
The <filename>KBRANCH_*</filename> statements identify the kernel branch to
use when building for the Crown Bay BSP.
<para>
Kernel machine names are initially defined in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink> in
+ <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Yocto Linux Kernel</ulink> in
+ the <filename>meta</filename> branch.
+ From the <filename>meta</filename> branch, look in
the <filename>meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc</filename> file.
- For example, in the <filename>linux-yocto-3.4</filename> kernel in the
- <filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file,
+ For example, from the <filename>meta</filename> branch in the
+ <filename>linux-yocto-3.0</filename> kernel, the
+ <filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file
has the following:
<literallayout class='monospaced'>
define KMACHINE cedartrail
include ktypes/standard
branch cedartrail
- include cedartrail.scc
+ include cedartrail.scc
</literallayout>
You can see that the kernel understands the machine name for the Cedar Trail BSP as
<filename>cedartrail</filename>.
<glossdef>
<para>This variable, which is set in the <filename>local.conf</filename> configuration
file found in the <filename>conf</filename> folder of the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>,
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
specifies the package manager to use when packaging data.
You can provide one or more arguments for the variable with the first
argument being the package manager used to create images:
<glossentry id='var-S'><glossterm>S</glossterm>
<glossdef>
<para>
- The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+ The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
where unpacked package source code resides.
This location is within the working directory
(<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>), which
${WORKDIR}/${PN}-${PV}
</literallayout>
As an example, assume a
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> top-level
folder named <filename>poky</filename>
- and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+ and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
at <filename>poky/build</filename>.
In this case, the working directory the build system uses to build
the <filename>db</filename> package is the following:
the upstream GCC or CodeSourcery Labs toolchain.
The variable identifies the <filename>tcmode-*</filename> files used in
the <filename>meta/conf/distro/include</filename> directory, which is found in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
</para>
<para>
By default, <filename>TCMODE</filename> is set to "default", which
uses when it does its work building images.
By default, the <filename>TMPDIR</filename> variable is named
<filename>tmp</filename> within the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
</para>
<para>
If you want to establish this directory in a location other than the
default, you can uncomment the following statement in the
<filename>conf/local.conf</filename> file in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
<literallayout class='monospaced'>
#TMPDIR = "${TOPDIR}/tmp"
</literallayout>
<glossdef>
<para>
This variable is the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
BitBake automatically sets this variable.
- The OpenEmbedded build system uses the build directory when building images.
+ The OpenEmbedded build system uses the Build Directory when building images.
</para>
</glossdef>
</glossentry>
${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
</literallayout>
As an example, assume a
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> top-level
folder name <filename>poky</filename> and a default
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
at <filename>poky/build</filename>.
In this case, the working directory the build system uses to build
the <filename>v86d</filename> package is the following:
<literallayout class='monospaced'>
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
</literallayout>
- As an example, again assume a source directory top-level folder
- named <filename>poky</filename> and a default build directory
+ As an example, again assume a Source Directory top-level folder
+ named <filename>poky</filename> and a default Build Directory
at <filename>poky/build</filename>.
In this case, the working directory the build system uses to build
the <filename>acl</filename> recipe, which is being built for a
between metadata files.
An example is the Autotools class, which contains
common settings for any application that Autotools uses.
- The "<link linkend='ref-classes'>Reference: Classes</link>" chapter provides details
+ The "<link linkend='ref-classes'>Classes</link>" chapter provides details
about common classes and how to use them.
</para>
</section>
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 (<filename>local.conf</filename>, which is found
- in the <ulink url='build-directory'>build directory</ulink>).
+ in the <ulink url='build-directory'>Build Directory</ulink>).
</para>
</section>
</section>
Information based on direct inputs is referred to as the "basehash" in the
code.
However, there is still the question of a task's indirect inputs - the
- things that were already built and present in the build directory.
+ things that were already built and present in the Build Directory.
The checksum (or signature) for a particular task needs to add the hashes
of all the tasks on which the particular task depends.
Choosing which dependencies to add is a policy decision.
Yocto Project, you can follow these steps to use the x32 spABI:
<itemizedlist>
<listitem><para>Add the <filename>experimental/meta-x32</filename> layer to your local
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
You can find the <filename>experimental/meta-x32</filename> source repository at
<ulink url='&YOCTO_GIT_URL;'></ulink>.</para></listitem>
<listitem><para>Edit your <filename>conf/bblayers.conf</filename> file so that it includes
which by default are disabled.
</para>
+ <para>
+ For information that can help you maintain compliance with various open
+ source licensing during the lifecycle of the product, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>" section
+ in the Yocto Project Development Manual.
+ </para>
+
<section id="usingpoky-configuring-LIC_FILES_CHKSUM">
<title>Tracking License Changes</title>
The first thing you need to do is set up the OpenEmbedded build environment by sourcing
the environment setup script as follows:
<literallayout class='monospaced'>
- $ source oe-init-build-env [build_dir]
+ $ source &OE_INIT_FILE; [build_dir]
</literallayout>
</para>
<para>
The <filename>build_dir</filename> is optional and specifies the directory the
OpenEmbedded build system uses for the build -
- the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
- If you do not specify a build directory it defaults to <filename>build</filename>
+ the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+ If you do not specify a Build Directory it defaults to <filename>build</filename>
in your current working directory.
- A common practice is to use a different build directory for different targets.
+ A common practice is to use a different Build Directory for different targets.
For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
- See <link linkend="structure-core-script">oe-init-build-env</link>
+ See <link linkend="structure-core-script">&OE_INIT_FILE;</link>
for more information on this script.
</para>
The <filename>target</filename> is the name of the recipe you want to build.
Common targets are the images in <filename>meta/recipes-core/images</filename>,
<filename>/meta/recipes-sato/images</filename>, etc. all found in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
Or, the target can be the name of a recipe for a specific piece of software such as
<application>busybox</application>.
For more details about the images the OpenEmbedded build system supports, see the
<para>
Once an image has been built, it often needs to be installed.
The images and kernels built by the OpenEmbedded build system are placed in the
- <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> in
+ <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in
<filename class="directory">tmp/deploy/images</filename>.
For information on how to run pre-built images such as <filename>qemux86</filename>
and <filename>qemuarm</filename>, see the
For guidance on how logging is handled in both Python and Bash recipes, see the
<filename>logging.bbclass</filename> file in the
<filename>meta/classes</filename> folder of the
- <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+ <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
</para>
<section id='logging-with-python'>
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
