documentation: dev-manual - Final changes before 1.3 lockdown.
Made minor changes as needed due to some new sections, links, and capitalization standards. (From yocto-docs rev: bc966e5a78dadd14ecf1896a36e40a9b256bae77) 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
f3c1226cc8
commit
2b51188de6
|
|
@ -208,7 +208,7 @@
|
|||
To enable your layer, simply add your layer's path to the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'>BBLAYERS</ulink></filename>
|
||||
variable in your <filename>conf/bblayers.conf</filename> file, which is found in the
|
||||
<link linkend='build-directory'>build directory</link>.
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
The following example shows how to enable a layer named <filename>meta-mylayer</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
LCONF_VERSION = "6"
|
||||
|
|
@ -315,7 +315,7 @@
|
|||
<literallayout class='monospaced'>
|
||||
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||||
|
||||
PRINC := "${@int(PRINC) + 1}"
|
||||
PRINC := "${@int(PRINC) + 2}"
|
||||
</literallayout>
|
||||
This example adds or overrides files in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||
|
|
@ -581,7 +581,7 @@
|
|||
You can also add more features by configuring the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</ulink></filename>
|
||||
variable in the <filename>local.conf</filename> file found in the Source Directory
|
||||
located in the build directory.
|
||||
located in the Build Directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -1240,7 +1240,7 @@
|
|||
combination of multiple libraries you want to build.
|
||||
You accomplish this through your <filename>local.conf</filename>
|
||||
configuration file in the
|
||||
<link linkend='build-directory'>build directory</link>.
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
An example configuration would be as follows:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE = "qemux86-64"
|
||||
|
|
@ -1285,7 +1285,7 @@
|
|||
<listitem><para>A unique architecture is defined for the Multilib packages,
|
||||
along with creating a unique deploy folder under
|
||||
<filename>tmp/deploy/rpm</filename> in the
|
||||
<link linkend='build-directory'>build directory</link>.
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
For example, consider <filename>lib32</filename> in a
|
||||
<filename>qemux86-64</filename> image.
|
||||
The possible architectures in the system are "all", "qemux86_64",
|
||||
|
|
@ -1407,7 +1407,7 @@
|
|||
Saving the selections updates the <filename>.config</filename> configuration file.
|
||||
This is the file that the OpenEmbedded build system uses to configure the
|
||||
kernel during the build.
|
||||
You can find and examine this file in the build directory in
|
||||
You can find and examine this file in the Build Directory in
|
||||
<filename>tmp/work/</filename>.
|
||||
The actual <filename>.config</filename> is located in the area where the
|
||||
specific kernel is built.
|
||||
|
|
@ -1463,7 +1463,7 @@
|
|||
placed where the OpenEmbedded build system can find and apply them.
|
||||
Syntactically, the configuration statement is identical to what would appear
|
||||
in the <filename>.config</filename> file, which is in the
|
||||
<link linkend='build-directory'>build directory</link> in
|
||||
<link linkend='build-directory'>Build Directory</link> in
|
||||
<filename>tmp/work/<arch>-poky-linux/linux-yocto-<release-specific-string>/linux-<arch>-<build-type></filename>.
|
||||
</para>
|
||||
|
||||
|
|
@ -1801,7 +1801,7 @@
|
|||
<itemizedlist>
|
||||
<listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> Your
|
||||
selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
definition within the <filename>local.conf</filename> file in the build directory
|
||||
definition within the <filename>local.conf</filename> file in the Build Directory
|
||||
specifies the target architecture used when building the Linux kernel.
|
||||
By default, <filename>MACHINE</filename> is set to
|
||||
<filename>qemux86</filename>, which specifies a 32-bit
|
||||
|
|
@ -1847,12 +1847,12 @@
|
|||
</para></listitem>
|
||||
<listitem><para><emphasis>Clean up</emphasis>:
|
||||
Be sure to clean the shared state out by running the
|
||||
<filename>cleansstate</filename> BitBake task as follows from your build directory:
|
||||
<filename>cleansstate</filename> BitBake task as follows from your Build Directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake -c cleansstate linux-yocto
|
||||
</literallayout></para>
|
||||
<para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
|
||||
directory inside the build directory.
|
||||
directory inside the Build Directory.
|
||||
Always use the various BitBake clean tasks to clear out previous
|
||||
build artifacts.
|
||||
</note></para></listitem>
|
||||
|
|
@ -2022,7 +2022,7 @@
|
|||
|
||||
<para>
|
||||
By default, the OpenEmbedded build system does its work from within the
|
||||
<link linkend='build-directory'>build directory</link>.
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
The build process involves fetching the source files, unpacking them, and then patching them
|
||||
if necessary before the build takes place.
|
||||
</para>
|
||||
|
|
@ -2058,17 +2058,17 @@
|
|||
|
||||
<para>
|
||||
It is important to know that the <filename>externalsrc.bbclass</filename> assumes that the
|
||||
source directory <filename>S</filename> and the build directory
|
||||
source directory <filename>S</filename> and the Build Directory
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-B'><filename>B</filename></ulink>
|
||||
are different even though by default these directories are the same.
|
||||
This assumption is important because it supports building different variants of the recipe
|
||||
by using the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
|
||||
variable.
|
||||
You could allow the build directory to be the same as the source directory but you would
|
||||
You could allow the Build Directory to be the same as the source directory but you would
|
||||
not be able to build more than one variant of the recipe.
|
||||
Consequently, if you are building multiple variants of the recipe, you need to establish a
|
||||
build directory that is different than the source directory.
|
||||
Build Directory that is different than the source directory.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -2114,7 +2114,7 @@
|
|||
<para>
|
||||
To enable this behavior, simply add the following to 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>:
|
||||
<literallayout class='monospaced'>
|
||||
SRCREV_pn-<PN> = "${AUTOREV}"
|
||||
</literallayout>
|
||||
|
|
@ -2545,7 +2545,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Downloaded archives reside in the build directory in
|
||||
Downloaded archives reside in the Build Directory in
|
||||
<filename>/tmp</filename> and are cleared up when they are no longer in use.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@
|
|||
"<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
|
||||
for an example that changes the source code of the kernel.
|
||||
For information on how to configure the kernel, see the
|
||||
"<link linkend='configuring-the-kernel'>Configuring the Kernel</link> section.
|
||||
"<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
|
||||
</para>
|
||||
|
||||
<section id='kernel-overview'>
|
||||
|
|
@ -347,7 +347,8 @@
|
|||
What happens during the build?
|
||||
When you build the kernel on your development system, all files needed for the build
|
||||
are taken from the source repositories pointed to by the
|
||||
<filename>SRC_URI</filename> variable and gathered in a temporary work area
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable
|
||||
and gathered in a temporary work area
|
||||
where they are subsequently used to create the unique kernel.
|
||||
Thus, in a sense, the process constructs a local source tree specific to your
|
||||
kernel to generate the new kernel image - a source generator if you will.
|
||||
|
|
@ -394,8 +395,8 @@
|
|||
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
|
||||
in the Yocto Project Quick Start for requirements.</para></listitem>
|
||||
<listitem><para><emphasis>Establish a local copy of project files on your
|
||||
system</emphasis>: Having the <link linkend='source-directory'>source
|
||||
directory</link> on your system gives you access to the build process and tools
|
||||
system</emphasis>: Having the <link linkend='source-directory'>Source
|
||||
Directory</link> on your system gives you access to the build process and tools
|
||||
you need.
|
||||
For information on how to get these files, see the bulleted item
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
|
||||
|
|
@ -439,7 +440,7 @@
|
|||
<filename>.config</filename>.
|
||||
Try to resist the temptation of directly editing the <filename>.config</filename>
|
||||
file found in the
|
||||
<link linkend='build-directory'>build directory</link> at
|
||||
<link linkend='build-directory'>Build Directory</link> at
|
||||
<filename>tmp/sysroots/<machine-name>/kernel</filename>.
|
||||
Doing so, can produce unexpected results when the OpenEmbedded build system
|
||||
regenerates the configuration file.</para>
|
||||
|
|
@ -986,10 +987,10 @@
|
|||
<listitem><para><emphasis>
|
||||
<filename>Build System Derived Toolchain:</filename></emphasis>
|
||||
Select this mode if the cross-toolchain has been installed and built
|
||||
as part of the build directory.
|
||||
as part of the Build Directory.
|
||||
When you select <filename>Build system derived toolchain</filename>,
|
||||
you are using the toolchain bundled
|
||||
inside the build directory.
|
||||
inside the Build Directory.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
|
|
@ -1008,9 +1009,9 @@
|
|||
However, doing so is discouraged.</note></para>
|
||||
<para>If you are using a system-derived toolchain, the path you provide
|
||||
for the <filename>Toolchain Root Location</filename>
|
||||
field is the build directory.
|
||||
field is the Build Directory.
|
||||
See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using
|
||||
BitBake and the build directory</ulink>" section in the Yocto Project Application
|
||||
BitBake and the Build Directory</ulink>" section in the Yocto Project Application
|
||||
Developer's Guide for information on how to install the toolchain into the build
|
||||
directory.</para></listitem>
|
||||
<listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
|
||||
|
|
@ -1053,7 +1054,7 @@ directory.</para></listitem>
|
|||
and specify any custom options.</para>
|
||||
<para>If you selected <filename>Build system derived toolchain</filename>,
|
||||
the target kernel you built will be located in the
|
||||
build directory in <filename>tmp/deploy/images</filename> directory.
|
||||
Build Directory in <filename>tmp/deploy/images</filename> directory.
|
||||
If you selected <filename>Standalone pre-built toolchain</filename>, the
|
||||
pre-built image you downloaded is located
|
||||
in the directory you specified when you downloaded the image.</para>
|
||||
|
|
@ -1409,7 +1410,7 @@ directory.</para></listitem>
|
|||
<orderedlist>
|
||||
<listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
|
||||
<listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem>
|
||||
<listitem><para>Enter the build directory where you want to put your final images.</para></listitem>
|
||||
<listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
|
||||
<listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
|
||||
<listitem><para>Use Hob to customize and build your own images.
|
||||
For information on Hob, see the
|
||||
|
|
@ -1480,7 +1481,7 @@ directory.</para></listitem>
|
|||
to figure out your solution.
|
||||
After you have initially built the package, you can iteratively tweak the
|
||||
source code, which is located in the
|
||||
<link linkend='build-directory'>build directory</link>, and then
|
||||
<link linkend='build-directory'>Build Directory</link>, and then
|
||||
you can force a re-compile and quickly test your altered code.
|
||||
Once you settle on a solution, you can then preserve your changes in the form of
|
||||
patches.
|
||||
|
|
@ -1494,7 +1495,7 @@ directory.</para></listitem>
|
|||
|
||||
<para>
|
||||
During a build, the unpacked temporary source code used by recipes
|
||||
to build packages is available in the build directory as
|
||||
to build packages is available in the Build Directory as
|
||||
defined by the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
|
||||
Below is the default value for the <filename>S</filename> variable as defined in the
|
||||
|
|
@ -1528,7 +1529,7 @@ directory.</para></listitem>
|
|||
Let's look at an example without variables.
|
||||
Assuming a top-level <link linkend='source-directory'>Source Directory</link>
|
||||
named <filename>poky</filename>
|
||||
and a default build directory of <filename>poky/build</filename>,
|
||||
and a default Build Directory of <filename>poky/build</filename>,
|
||||
the following is the work directory for the <filename>acl</filename> recipe that
|
||||
creates the <filename>acl</filename> package:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -1543,7 +1544,7 @@ directory.</para></listitem>
|
|||
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
|
||||
</literallayout>
|
||||
Again, assuming top-level Source Directory named <filename>poky</filename>
|
||||
and a default build directory of <filename>poky/build</filename>, the
|
||||
and a default Build Directory of <filename>poky/build</filename>, the
|
||||
following are the work and temporary source directories, respectively,
|
||||
for the <filename>acl</filename> package that is being
|
||||
built for a MIPS-based device:
|
||||
|
|
@ -1591,7 +1592,7 @@ directory.</para></listitem>
|
|||
<orderedlist>
|
||||
<listitem><para><emphasis>Find the Source Code:</emphasis>
|
||||
The temporary source code used by the OpenEmbedded build system is kept in the
|
||||
build directory.
|
||||
Build Directory.
|
||||
See the
|
||||
"<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
|
||||
section to learn how to locate the directory that has the temporary source code for a
|
||||
|
|
@ -1689,7 +1690,7 @@ directory.</para></listitem>
|
|||
<orderedlist>
|
||||
<listitem><para><emphasis>Find the Source Code:</emphasis>
|
||||
The temporary source code used by the OpenEmbedded build system is kept in the
|
||||
build directory.
|
||||
Build Directory.
|
||||
See the
|
||||
"<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
|
||||
section to learn how to locate the directory that has the temporary source code for a
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@
|
|||
From the interface, you can click on any particular item in the "Name" column and
|
||||
see the URL at the bottom of the page that you need to set up a Git repository for
|
||||
that particular item.
|
||||
Having a local Git repository of the source directory (poky) allows you to
|
||||
Having a local Git repository of the Source Directory (poky) allows you to
|
||||
make changes, contribute to the history, and ultimately enhance the Yocto Project's
|
||||
tools, Board Support Packages, and so forth.
|
||||
</para>
|
||||
|
|
@ -148,7 +148,7 @@
|
|||
<ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a
|
||||
tarball of the release.
|
||||
You can also go to this site to download any supported BSP tarballs.
|
||||
Unpacking the tarball gives you a hierarchical source directory that lets you develop
|
||||
Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
|
||||
using the Yocto Project.
|
||||
</para>
|
||||
|
||||
|
|
@ -220,31 +220,31 @@
|
|||
<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. <filename>oe-init-build-env</filename>).
|
||||
environment script that is found in the Source Directory
|
||||
(i.e. <filename>&OE_INIT_FILE;</filename>).
|
||||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
|
||||
variable points to the build directory.</para>
|
||||
variable points to the Build Directory.</para>
|
||||
|
||||
<para>You have a lot of flexibility when creating the build directory.
|
||||
<para>You have a lot of flexibility when creating the Build Directory.
|
||||
Following are some examples that show how to create the directory:
|
||||
<itemizedlist>
|
||||
<listitem><para>Create the build directory in your current working directory
|
||||
<listitem><para>Create the Build Directory in your current working directory
|
||||
and name it <filename>build</filename>.
|
||||
This is the default behavior.
|
||||
<literallayout class='monospaced'>
|
||||
$ source oe-init-build-env
|
||||
$ source &OE_INIT_PATH;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Provide a directory path and specifically name the build
|
||||
directory.
|
||||
This next example creates a build directory named <filename>YP-&POKYVERSION;</filename>
|
||||
This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
|
||||
in your home directory within the directory <filename>mybuilds</filename>.
|
||||
If <filename>mybuilds</filename> does not exist, the directory is created for you:
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Provide an existing directory to use as the build directory.
|
||||
<listitem><para>Provide an existing directory to use as the Build Directory.
|
||||
This example uses the existing <filename>mybuilds</filename> directory
|
||||
as the build directory.
|
||||
as the Build Directory.
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_PATH; $HOME/mybuilds/
|
||||
</literallayout></para></listitem>
|
||||
|
|
@ -254,7 +254,7 @@
|
|||
this term refers to the OpenEmbedded build system used by the project.
|
||||
This build system is based on the project known as "Poky."
|
||||
For some historical information about Poky, see the
|
||||
<link linkend='poky'>poky</link> term further along in this section.
|
||||
<link linkend='poky'>Poky</link> term further along in this section.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
|
||||
and inheritance allowing commonly used patterns to be defined once and easily used
|
||||
|
|
@ -264,14 +264,14 @@
|
|||
<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>
|
||||
<link linkend='build-directory'>Build Directory</link>
|
||||
contains user-defined variables that affect each build.
|
||||
The <filename>meta-yocto/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
|
||||
<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/beagleboard.conf</filename> configuration file defines
|
||||
variables for the Texas Instruments ARM Cortex-A8 development board).
|
||||
|
|
@ -332,7 +332,7 @@
|
|||
the Yocto Project's build system.
|
||||
Within the Yocto Project source repositories, poky exists as a separate Git repository
|
||||
that can be cloned to yield a local copy on the host system.
|
||||
Thus, "poky" can refer to the local copy of the source directory used to develop within
|
||||
Thus, "poky" can refer to the local copy of the Source Directory used to develop within
|
||||
the Yocto Project.</para></listitem>
|
||||
<listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.
|
||||
A recipe describes where you get source code and which patches to apply.
|
||||
|
|
@ -349,15 +349,15 @@
|
|||
Sometimes you might here the term "poky directory" used to refer to this
|
||||
directory structure.</para>
|
||||
|
||||
<para>The source directory contains BitBake, Documentation, metadata and
|
||||
<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
|
||||
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>For tarball expansion, the name of the top-level directory of the source directory
|
||||
<para>For tarball expansion, the name of the top-level directory 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 top-level folder is named
|
||||
results in a Source Directory whose top-level folder is named
|
||||
<filename>&YOCTO_POKY;</filename>.
|
||||
If you create a local copy of the Git repository, then you can name the repository
|
||||
anything you like.
|
||||
|
|
@ -366,15 +366,15 @@
|
|||
So, for example, cloning the <filename>poky</filename> Git repository results in a
|
||||
local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
|
||||
|
||||
<para>It is important to understand the differences between the source directory created
|
||||
<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.
|
||||
Any changes you make to your local files in the Source Directory are on top of the release.
|
||||
On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
|
||||
active development repository.
|
||||
In this case, any local changes you make to the source directory can be later applied
|
||||
In this case, any local changes you make to the Source Directory can be later applied
|
||||
to active development branches of the upstream <filename>poky</filename> Git
|
||||
repository.</para>
|
||||
|
||||
|
|
@ -438,7 +438,7 @@
|
|||
<filename>meta/files/common-licenses</filename>.
|
||||
Once the build completes, the list of all licenses found and used during that build are
|
||||
kept in the
|
||||
<link linkend='build-directory'>build directory</link> at
|
||||
<link linkend='build-directory'>Build Directory</link> at
|
||||
<filename>tmp/deploy/images/licenses</filename>.
|
||||
</para>
|
||||
|
||||
|
|
@ -466,6 +466,12 @@
|
|||
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
|
||||
This wiki page discusses the license infrastructure used by the Yocto Project.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information that can help you to maintain compliance with various open source licensing
|
||||
during the lifecycle of a product created using the Yocto Project, see the
|
||||
"<link linkend='maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</link>" section.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='git'>
|
||||
|
|
|
|||
|
|
@ -56,8 +56,9 @@
|
|||
OpenSUSE, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
|
||||
and officially supported.
|
||||
For a list of the distributions under validation and their status, see the
|
||||
<ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
|
||||
Support</ulink> wiki page.</para>
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
|
||||
in the Yocto Project Reference Manual and the wiki page at
|
||||
<ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>.</para>
|
||||
<para>
|
||||
You should also have about 100 gigabytes of free disk space for building images.
|
||||
</para></listitem>
|
||||
|
|
@ -69,12 +70,12 @@
|
|||
for the supported distributions.</para></listitem>
|
||||
<listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
|
||||
You need a release of the Yocto Project.
|
||||
You set up a with local <link linkend='source-directory'>source directory</link>
|
||||
You set up a with local <link linkend='source-directory'>Source Directory</link>
|
||||
one of two ways depending on whether you
|
||||
are going to contribute back into the Yocto Project or not.
|
||||
<note>
|
||||
Regardless of the method you use, this manual refers to the resulting local
|
||||
hierarchical set of files as the "source directory."
|
||||
hierarchical set of files as the "Source Directory."
|
||||
</note>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Tarball Extraction:</emphasis> If you are not going to contribute
|
||||
|
|
@ -83,7 +84,7 @@
|
|||
Once you have the tarball, just extract it into a directory of your choice.</para>
|
||||
<para>For example, the following command extracts the Yocto Project &DISTRO;
|
||||
release tarball
|
||||
into the current working directory and sets up the local source directory
|
||||
into the current working directory and sets up the local Source Directory
|
||||
with a top-level folder named <filename>&YOCTO_POKY;</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ tar xfj &YOCTO_POKY_TARBALL;
|
||||
|
|
@ -125,11 +126,11 @@
|
|||
You can find Git repositories of supported Yocto Project Kernels organized under
|
||||
"Yocto Linux Kernel" in the Yocto Project Source Repositories at
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
|
||||
<para>This setup involves creating a bare clone of the Yocto Project kernel and then
|
||||
<para>This setup can involve creating a bare clone of the Yocto Project kernel and then
|
||||
copying that cloned repository.
|
||||
You can create the bare clone and the copy of the bare clone anywhere you like.
|
||||
For simplicity, it is recommended that you create these structures outside of the
|
||||
source directory (usually <filename>poky</filename>).</para>
|
||||
Source Directory (usually <filename>poky</filename>).</para>
|
||||
<para>As an example, the following transcript shows how to create the bare clone
|
||||
of the <filename>linux-yocto-3.4</filename> kernel and then create a copy of
|
||||
that clone.
|
||||
|
|
@ -168,9 +169,9 @@
|
|||
<para>You can find the <filename>poky-extras</filename> Git Repository in the
|
||||
"Yocto Metadata Layers" area of the Yocto Project Source Repositories at
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
|
||||
It is good practice to create this Git repository inside the source directory.</para>
|
||||
It is good practice to create this Git repository inside the Source Directory.</para>
|
||||
<para>Following is an example that creates the <filename>poky-extras</filename> Git
|
||||
repository inside the source directory, which is named <filename>poky</filename>
|
||||
repository inside the Source Directory, which is named <filename>poky</filename>
|
||||
in this case:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
|
|
@ -192,7 +193,7 @@
|
|||
layer.
|
||||
You can get set up for BSP development one of two ways: tarball extraction or
|
||||
with a local Git repository.
|
||||
It is a good idea to use the same method that you used to set up the source directory.
|
||||
It is a good idea to use the same method that you used to set up the Source Directory.
|
||||
Regardless of the method you use, the Yocto Project uses the following BSP layer
|
||||
naming scheme:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -218,13 +219,13 @@
|
|||
Again, this method just produces a snapshot of the BSP layer in the form
|
||||
of a hierarchical directory structure.</para></listitem>
|
||||
<listitem><para><emphasis>Git Repository Method:</emphasis> If you are working
|
||||
with a local Git repository for your source directory, you should also use this method
|
||||
with a local Git repository for your Source Directory, you should also use this method
|
||||
to set up the <filename>meta-intel</filename> Git repository.
|
||||
You can locate the <filename>meta-intel</filename> Git repository in the
|
||||
"Yocto Metadata Layers" area of the Yocto Project Source Repositories at
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
|
||||
<para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
|
||||
the source directory.
|
||||
the Source Directory.
|
||||
For example, the following transcript shows the steps to clone the
|
||||
<filename>meta-intel</filename>
|
||||
Git repository inside the local <filename>poky</filename> Git repository.
|
||||
|
|
@ -266,13 +267,13 @@
|
|||
<para>
|
||||
The build process is as follows:
|
||||
<orderedlist>
|
||||
<listitem><para>Make sure you have set up the source directory described in the
|
||||
<listitem><para>Make sure you have set up the Source Directory described in the
|
||||
previous section.</para></listitem>
|
||||
<listitem><para>Initialize the build environment by sourcing a build environment
|
||||
script.</para></listitem>
|
||||
<listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file,
|
||||
which is found in the
|
||||
<link linkend='build-directory'>build directory</link>,
|
||||
<link linkend='build-directory'>Build Directory</link>,
|
||||
is set up how you want it.
|
||||
This file defines many aspects of the build environment including
|
||||
the target machine architecture through the
|
||||
|
|
@ -298,7 +299,7 @@
|
|||
<para>
|
||||
Another option you have to get started is to use pre-built binaries.
|
||||
The Yocto Project provides many types of binaries with each release.
|
||||
See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>
|
||||
See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
|
||||
chapter in the Yocto Project Reference Manual
|
||||
for descriptions of the types of binaries that ship with a Yocto Project
|
||||
release.
|
||||
|
|
|
|||
Loading…
Reference in New Issue