mirror of
https://git.yoctoproject.org/poky
synced 2026-06-02 13:29:49 +00:00
sphinx: remove DocBook files
The Yocto Project documentation was migrated to Sphinx. Let's remove the deprecated DocBook files. (From yocto-docs rev: 28fb0e63b2fbfd6426b00498bf2682bb53fdd862) Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne
committed by
Richard Purdie
Richard Purdie
parent
1fd9c4b2c0
commit
43d07a2851
@@ -1,59 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<appendix id='sdk-appendix-customizing-standard'>
|
||||
|
||||
<title>Customizing the Standard SDK</title>
|
||||
|
||||
<para>
|
||||
This appendix presents customizations you can apply to the standard SDK.
|
||||
</para>
|
||||
|
||||
<section id='sdk-adding-individual-packages'>
|
||||
<title>Adding Individual Packages to the Standard SDK</title>
|
||||
|
||||
<para>
|
||||
When you build a standard SDK using the
|
||||
<filename>bitbake -c populate_sdk</filename>, a default set of
|
||||
packages is included in the resulting SDK.
|
||||
The
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></ulink>
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></ulink>
|
||||
variables control the set of packages adding to the SDK.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want to add individual packages to the toolchain that runs on
|
||||
the host, simply add those packages to the
|
||||
<filename>TOOLCHAIN_HOST_TASK</filename> variable.
|
||||
Similarly, if you want to add packages to the default set that is
|
||||
part of the toolchain that runs on the target, add the packages to the
|
||||
<filename>TOOLCHAIN_TARGET_TASK</filename> variable.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='adding-api-documentation-to-the-standard-sdk'>
|
||||
<title>Adding API Documentation to the Standard SDK</title>
|
||||
|
||||
<para>
|
||||
You can include API documentation as well as any other
|
||||
documentation provided by recipes with the standard SDK by
|
||||
adding "api-documentation" to the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
|
||||
variable:
|
||||
<literallayout class='monospaced'>
|
||||
DISTRO_FEATURES_append = " api-documentation"
|
||||
</literallayout>
|
||||
Setting this variable as shown here causes the OpenEmbedded build
|
||||
system to build the documentation and then include it in the standard
|
||||
SDK.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</appendix>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
@@ -1,515 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<appendix id='sdk-appendix-customizing'>
|
||||
|
||||
<title>Customizing the Extensible SDK</title>
|
||||
|
||||
<para>
|
||||
This appendix describes customizations you can apply to the extensible SDK.
|
||||
</para>
|
||||
|
||||
<section id='sdk-configuring-the-extensible-sdk'>
|
||||
<title>Configuring the Extensible SDK</title>
|
||||
|
||||
<para>
|
||||
The extensible SDK primarily consists of a pre-configured copy of
|
||||
the OpenEmbedded build system from which it was produced.
|
||||
Thus, the SDK's configuration is derived using that build system and
|
||||
the filters shown in the following list.
|
||||
When these filters are present, the OpenEmbedded build system applies
|
||||
them against <filename>local.conf</filename> and
|
||||
<filename>auto.conf</filename>:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Variables whose values start with "/" are excluded since the
|
||||
assumption is that those values are paths that are likely to
|
||||
be specific to the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Variables listed in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
|
||||
are excluded.
|
||||
These variables are not allowed through from the OpenEmbedded
|
||||
build system configuration into the extensible SDK
|
||||
configuration.
|
||||
Typically, these variables are specific to the machine on
|
||||
which the build system is running and could be problematic
|
||||
as part of the extensible SDK configuration.</para>
|
||||
|
||||
<para>For a list of the variables excluded by default, see the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
|
||||
in the glossary of the Yocto Project Reference Manual.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Variables listed in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></ulink>
|
||||
are included.
|
||||
Including a variable in the value of
|
||||
<filename>SDK_LOCAL_CONF_WHITELIST</filename> overrides either
|
||||
of the previous two filters.
|
||||
The default value is blank.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Classes inherited globally with
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
|
||||
that are listed in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
|
||||
are disabled.
|
||||
Using <filename>SDK_INHERIT_BLACKLIST</filename> to disable
|
||||
these classes is the typical method to disable classes that
|
||||
are problematic or unnecessary in the SDK context.
|
||||
The default value blacklists the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory'><filename>buildhistory</filename></ulink>
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-icecc'><filename>icecc</filename></ulink>
|
||||
classes.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
Additionally, the contents of <filename>conf/sdk-extra.conf</filename>,
|
||||
when present, are appended to the end of
|
||||
<filename>conf/local.conf</filename> within the produced SDK, without
|
||||
any filtering.
|
||||
The <filename>sdk-extra.conf</filename> file is particularly useful
|
||||
if you want to set a variable value just for the SDK and not the
|
||||
OpenEmbedded build system used to create the SDK.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='adjusting-the-extensible-sdk-to-suit-your-build-hosts-setup'>
|
||||
<title>Adjusting the Extensible SDK to Suit Your Build Host's Setup</title>
|
||||
|
||||
<para>
|
||||
In most cases, the extensible SDK defaults should work with your
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host's</ulink>
|
||||
setup.
|
||||
However, some cases exist for which you might consider making
|
||||
adjustments:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
If your SDK configuration inherits additional classes
|
||||
using the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
|
||||
variable and you do not need or want those classes enabled in
|
||||
the SDK, you can blacklist them by adding them to the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
|
||||
variable as described in the fourth bullet of the previous
|
||||
section.
|
||||
<note>
|
||||
The default value of
|
||||
<filename>SDK_INHERIT_BLACKLIST</filename> is set using
|
||||
the "?=" operator.
|
||||
Consequently, you will need to either define the entire
|
||||
list by using the "=" operator, or you will need to append
|
||||
a value using either "_append" or the "+=" operator.
|
||||
You can learn more about these operators in the
|
||||
"<ulink url='&YOCTO_DOCS_BB_URL;#basic-syntax'>Basic Syntax</ulink>"
|
||||
section of the BitBake User Manual.
|
||||
</note>.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you have classes or recipes that add additional tasks to
|
||||
the standard build flow (i.e. the tasks execute as the recipe
|
||||
builds as opposed to being called explicitly), then you need
|
||||
to do one of the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
After ensuring the tasks are
|
||||
<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>shared state</ulink>
|
||||
tasks (i.e. the output of the task is saved to and
|
||||
can be restored from the shared state cache) or
|
||||
ensuring the tasks are able to be produced quickly from
|
||||
a task that is a shared state task, add the task name
|
||||
to the value of
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_RECRDEP_TASKS'><filename>SDK_RECRDEP_TASKS</filename></ulink>.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Disable the tasks if they are added by a class and
|
||||
you do not need the functionality the class provides
|
||||
in the extensible SDK.
|
||||
To disable the tasks, add the class to the
|
||||
<filename>SDK_INHERIT_BLACKLIST</filename> variable
|
||||
as described in the previous section.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Generally, you want to have a shared state mirror set up so
|
||||
users of the SDK can add additional items to the SDK after
|
||||
installation without needing to build the items from source.
|
||||
See the
|
||||
"<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
|
||||
section for information.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you want users of the SDK to be able to easily update the
|
||||
SDK, you need to set the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
|
||||
variable.
|
||||
For more information, see the
|
||||
"<link linkend='sdk-providing-updates-to-the-extensible-sdk-after-installation'>Providing Updates to the Extensible SDK After Installation</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you have adjusted the list of files and directories that
|
||||
appear in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE'><filename>COREBASE</filename></ulink>
|
||||
(other than layers that are enabled through
|
||||
<filename>bblayers.conf</filename>), then you must list these
|
||||
files in
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE_FILES'><filename>COREBASE_FILES</filename></ulink>
|
||||
so that the files are copied into the SDK.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If your OpenEmbedded build system setup uses a different
|
||||
environment setup script other than
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>,
|
||||
then you must set
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-OE_INIT_ENV_SCRIPT'><filename>OE_INIT_ENV_SCRIPT</filename></ulink>
|
||||
to point to the environment setup script you use.
|
||||
<note>
|
||||
You must also reflect this change in the value used for the
|
||||
<filename>COREBASE_FILES</filename> variable as previously
|
||||
described.
|
||||
</note>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-changing-the-sdk-installer-title'>
|
||||
<title>Changing the Extensible SDK Installer Title</title>
|
||||
|
||||
<para>
|
||||
You can change the displayed title for the SDK installer by setting
|
||||
the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_TITLE'><filename>SDK_TITLE</filename></ulink>
|
||||
variable and then rebuilding the the SDK installer.
|
||||
For information on how to build an SDK installer, see the
|
||||
"<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
|
||||
section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
By default, this title is derived from
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink>
|
||||
when it is set.
|
||||
If the <filename>DISTRO_NAME</filename> variable is not set, the title
|
||||
is derived from the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
|
||||
variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></ulink>
|
||||
class defines the default value of the <filename>SDK_TITLE</filename>
|
||||
variable as follows:
|
||||
<literallayout class='monospaced'>
|
||||
SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While several ways exist to change this variable, an efficient method
|
||||
is to set the variable in your distribution's configuration file.
|
||||
Doing so creates an SDK installer title that applies across your
|
||||
distribution.
|
||||
As an example, assume you have your own layer for your distribution
|
||||
named "meta-mydistro" and you are using the same type of file
|
||||
hierarchy as does the default "poky" distribution.
|
||||
If so, you could update the <filename>SDK_TITLE</filename> variable
|
||||
in the
|
||||
<filename>~/meta-mydistro/conf/distro/mydistro.conf</filename> file
|
||||
using the following form:
|
||||
<literallayout class='monospaced'>
|
||||
SDK_TITLE = "<replaceable>your_title</replaceable>"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-providing-updates-to-the-extensible-sdk-after-installation'>
|
||||
<title>Providing Updates to the Extensible SDK After Installation</title>
|
||||
|
||||
<para>
|
||||
When you make changes to your configuration or to the metadata and
|
||||
if you want those changes to be reflected in installed SDKs, you need
|
||||
to perform additional steps.
|
||||
These steps make it possible for anyone using the installed SDKs to
|
||||
update the installed SDKs by using the
|
||||
<filename>devtool sdk-update</filename> command:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
Create a directory that can be shared over HTTP or HTTPS.
|
||||
You can do this by setting up a web server such as an
|
||||
<ulink url='https://en.wikipedia.org/wiki/Apache_HTTP_Server'>Apache HTTP Server</ulink>
|
||||
or
|
||||
<ulink url='https://en.wikipedia.org/wiki/Nginx'>Nginx</ulink>
|
||||
server in the cloud to host the directory.
|
||||
This directory must contain the published SDK.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Set the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
|
||||
variable to point to the corresponding HTTP or HTTPS URL.
|
||||
Setting this variable causes any SDK built to default to that
|
||||
URL and thus, the user does not have to pass the URL to the
|
||||
<filename>devtool sdk-update</filename> command as described
|
||||
in the
|
||||
"<link linkend='sdk-applying-updates-to-an-installed-extensible-sdk'>Applying Updates to an Installed Extensible SDK</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Build the extensible SDK normally (i.e., use the
|
||||
<filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>
|
||||
command).
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Publish the SDK using the following command:
|
||||
<literallayout class='monospaced'>
|
||||
$ oe-publish-sdk <replaceable>some_path</replaceable>/sdk-installer.sh <replaceable>path_to_shared_http_directory</replaceable>
|
||||
</literallayout>
|
||||
You must repeat this step each time you rebuild the SDK
|
||||
with changes that you want to make available through the
|
||||
update mechanism.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Completing the above steps allows users of the existing installed
|
||||
SDKs to simply run <filename>devtool sdk-update</filename> to
|
||||
retrieve and apply the latest updates.
|
||||
See the
|
||||
"<link linkend='sdk-applying-updates-to-an-installed-extensible-sdk'>Applying Updates to an Installed Extensible SDK</link>"
|
||||
section for further information.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-changing-the-default-sdk-installation-directory'>
|
||||
<title>Changing the Default SDK Installation Directory</title>
|
||||
|
||||
<para>
|
||||
When you build the installer for the Extensible SDK, the default
|
||||
installation directory for the SDK is based on the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDKEXTPATH'><filename>SDKEXTPATH</filename></ulink>
|
||||
variables from within the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></ulink>
|
||||
class as follows:
|
||||
<literallayout class='monospaced'>
|
||||
SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
|
||||
</literallayout>
|
||||
You can change this default installation directory by specifically
|
||||
setting the <filename>SDKEXTPATH</filename> variable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While a number of ways exist through which you can set this variable,
|
||||
the method that makes the most sense is to set the variable in your
|
||||
distribution's configuration file.
|
||||
Doing so creates an SDK installer default directory that applies
|
||||
across your distribution.
|
||||
As an example, assume you have your own layer for your distribution
|
||||
named "meta-mydistro" and you are using the same type of file
|
||||
hierarchy as does the default "poky" distribution.
|
||||
If so, you could update the <filename>SDKEXTPATH</filename> variable
|
||||
in the
|
||||
<filename>~/meta-mydistro/conf/distro/mydistro.conf</filename> file
|
||||
using the following form:
|
||||
<literallayout class='monospaced'>
|
||||
SDKEXTPATH = "<replaceable>some_path_for_your_installed_sdk</replaceable>"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After building your installer, running it prompts the user for
|
||||
acceptance of the
|
||||
<replaceable>some_path_for_your_installed_sdk</replaceable> directory
|
||||
as the default location to install the Extensible SDK.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-providing-additional-installable-extensible-sdk-content'>
|
||||
<title>Providing Additional Installable Extensible SDK Content</title>
|
||||
|
||||
<para>
|
||||
If you want the users of an extensible SDK you build to be
|
||||
able to add items to the SDK without requiring the users to build
|
||||
the items from source, you need to do a number of things:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
Ensure the additional items you want the user to be able to
|
||||
install are already built:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Build the items explicitly.
|
||||
You could use one or more "meta" recipes that depend
|
||||
on lists of other recipes.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Build the "world" target and set
|
||||
<filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
|
||||
for the recipes you do not want built.
|
||||
See the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD'><filename>EXCLUDE_FROM_WORLD</filename></ulink>
|
||||
variable for additional information.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Expose the <filename>sstate-cache</filename> directory
|
||||
produced by the build.
|
||||
Typically, you expose this directory by making it available
|
||||
through an
|
||||
<ulink url='https://en.wikipedia.org/wiki/Apache_HTTP_Server'>Apache HTTP Server</ulink>
|
||||
or
|
||||
<ulink url='https://en.wikipedia.org/wiki/Nginx'>Nginx</ulink>
|
||||
server.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Set the appropriate configuration so that the produced SDK
|
||||
knows how to find the configuration.
|
||||
The variable you need to set is
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>:
|
||||
<literallayout class='monospaced'>
|
||||
SSTATE_MIRRORS = "file://.* http://<replaceable>example</replaceable>.com/<replaceable>some_path</replaceable>/sstate-cache/PATH"
|
||||
</literallayout>
|
||||
You can set the <filename>SSTATE_MIRRORS</filename> variable
|
||||
in two different places:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
If the mirror value you are setting is appropriate to
|
||||
be set for both the OpenEmbedded build system that is
|
||||
actually building the SDK and the SDK itself (i.e. the
|
||||
mirror is accessible in both places or it will fail
|
||||
quickly on the OpenEmbedded build system side, and its
|
||||
contents will not interfere with the build), then you
|
||||
can set the variable in your
|
||||
<filename>local.conf</filename> or custom distro
|
||||
configuration file.
|
||||
You can then "whitelist" the variable through
|
||||
to the SDK by adding the following:
|
||||
<literallayout class='monospaced'>
|
||||
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Alternatively, if you just want to set the
|
||||
<filename>SSTATE_MIRRORS</filename> variable's value
|
||||
for the SDK alone, create a
|
||||
<filename>conf/sdk-extra.conf</filename> file either in
|
||||
your
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
||||
or within any layer and put your
|
||||
<filename>SSTATE_MIRRORS</filename> setting within
|
||||
that file.
|
||||
<note>
|
||||
This second option is the safest option should
|
||||
you have any doubts as to which method to use when
|
||||
setting <filename>SSTATE_MIRRORS</filename>.
|
||||
</note>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-minimizing-the-size-of-the-extensible-sdk-installer-download'>
|
||||
<title>Minimizing the Size of the Extensible SDK Installer Download</title>
|
||||
|
||||
<para>
|
||||
By default, the extensible SDK bundles the shared state artifacts for
|
||||
everything needed to reconstruct the image for which the SDK was built.
|
||||
This bundling can lead to an SDK installer file that is a Gigabyte or
|
||||
more in size.
|
||||
If the size of this file causes a problem, you can build an SDK that
|
||||
has just enough in it to install and provide access to the
|
||||
<filename>devtool command</filename> by setting the following in your
|
||||
configuration:
|
||||
<literallayout class='monospaced'>
|
||||
SDK_EXT_TYPE = "minimal"
|
||||
</literallayout>
|
||||
Setting
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></ulink>
|
||||
to "minimal" produces an SDK installer that is around 35 Mbytes in
|
||||
size, which downloads and installs quickly.
|
||||
You need to realize, though, that the minimal installer does not
|
||||
install any libraries or tools out of the box.
|
||||
These libraries and tools must be installed either "on the fly" or
|
||||
through actions you perform using <filename>devtool</filename> or
|
||||
explicitly with the <filename>devtool sdk-install</filename> command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In most cases, when building a minimal SDK you need to also enable
|
||||
bringing in the information on a wider range of packages produced by
|
||||
the system.
|
||||
Requiring this wider range of information is particularly true
|
||||
so that <filename>devtool add</filename> is able to effectively map
|
||||
dependencies it discovers in a source tree to the appropriate recipes.
|
||||
Additionally, the information enables the
|
||||
<filename>devtool search</filename> command to return useful results.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To facilitate this wider range of information, you would need to
|
||||
set the following:
|
||||
<literallayout class='monospaced'>
|
||||
SDK_INCLUDE_PKGDATA = "1"
|
||||
</literallayout>
|
||||
See the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></ulink>
|
||||
variable for additional information.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Setting the <filename>SDK_INCLUDE_PKGDATA</filename> variable as
|
||||
shown causes the "world" target to be built so that information
|
||||
for all of the recipes included within it are available.
|
||||
Having these recipes available increases build time significantly and
|
||||
increases the size of the SDK installer by 30-80 Mbytes depending on
|
||||
how many recipes are included in your configuration.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can use
|
||||
<filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
|
||||
for recipes you want to exclude.
|
||||
However, it is assumed that you would need to be building the "world"
|
||||
target if you want to provide additional items to the SDK.
|
||||
Consequently, building for "world" should not represent undue
|
||||
overhead in most cases.
|
||||
<note>
|
||||
If you set <filename>SDK_EXT_TYPE</filename> to "minimal",
|
||||
then providing a shared state mirror is mandatory so that items
|
||||
can be installed as needed.
|
||||
See the
|
||||
"<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
|
||||
section for more information.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can explicitly control whether or not to include the toolchain
|
||||
when you build an SDK by setting the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink>
|
||||
variable to "1".
|
||||
In particular, it is useful to include the toolchain when you
|
||||
have set <filename>SDK_EXT_TYPE</filename> to "minimal", which by
|
||||
default, excludes the toolchain.
|
||||
Also, it is helpful if you are building a small SDK for use with
|
||||
an IDE or some
|
||||
other tool where you do not want to take extra steps to install a
|
||||
toolchain.
|
||||
</para>
|
||||
</section>
|
||||
</appendix>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
@@ -1,444 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<appendix id='sdk-appendix-obtain'>
|
||||
|
||||
<title>Obtaining the SDK</title>
|
||||
|
||||
<section id='sdk-locating-pre-built-sdk-installers'>
|
||||
<title>Locating Pre-Built SDK Installers</title>
|
||||
|
||||
<para>
|
||||
You can use existing, pre-built toolchains by locating and running
|
||||
an SDK installer script that ships with the Yocto Project.
|
||||
Using this method, you select and download an architecture-specific
|
||||
SDK installer and then run the script to hand-install the
|
||||
toolchain.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these steps to locate and hand-install the toolchain:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Go to the Installers Directory:</emphasis>
|
||||
Go to <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Open the Folder for Your Build Host:</emphasis>
|
||||
Open the folder that matches your
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>build host</ulink>
|
||||
(i.e. <filename>i686</filename> for 32-bit machines or
|
||||
<filename>x86_64</filename> for 64-bit machines).
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Locate and Download the SDK Installer:</emphasis>
|
||||
You need to find and download the installer appropriate for
|
||||
your build host, target hardware, and image type.
|
||||
</para>
|
||||
|
||||
<para>The installer files (<filename>*.sh</filename>) follow
|
||||
this naming convention:
|
||||
<literallayout class='monospaced'>
|
||||
poky-glibc-<replaceable>host_system</replaceable>-core-image-<replaceable>type</replaceable>-<replaceable>arch</replaceable>-toolchain[-ext]-<replaceable>release</replaceable>.sh
|
||||
|
||||
Where:
|
||||
<replaceable>host_system</replaceable> is a string representing your development system:
|
||||
"i686" or "x86_64"
|
||||
|
||||
<replaceable>type</replaceable> is a string representing the image:
|
||||
"sato" or "minimal"
|
||||
|
||||
<replaceable>arch</replaceable> is a string representing the target architecture:
|
||||
"aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2",
|
||||
"mips64", or "ppc7400"
|
||||
|
||||
<replaceable>release</replaceable> is the version of Yocto Project.
|
||||
|
||||
NOTE:
|
||||
The standard SDK installer does not have the "-ext" string as
|
||||
part of the filename.
|
||||
|
||||
</literallayout>
|
||||
The toolchains provided by the Yocto Project are based off of
|
||||
the <filename>core-image-sato</filename> and
|
||||
<filename>core-image-minimal</filename> images and contain
|
||||
libraries appropriate for developing against those images.
|
||||
</para>
|
||||
|
||||
<para>For example, if your build host is a 64-bit x86 system
|
||||
and you need an extended SDK for a 64-bit core2 target, go
|
||||
into the <filename>x86_64</filename> folder and download the
|
||||
following installer:
|
||||
<literallayout class='monospaced'>
|
||||
poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Run the Installer:</emphasis>
|
||||
Be sure you have execution privileges and run the installer.
|
||||
Following is an example from the <filename>Downloads</filename>
|
||||
directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
|
||||
</literallayout>
|
||||
During execution of the script, you choose the root location
|
||||
for the toolchain.
|
||||
See the
|
||||
"<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
|
||||
section and the
|
||||
"<link linkend='sdk-installed-extensible-sdk-directory-structure'>Installed Extensible SDK Directory Structure</link>"
|
||||
section for more information.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-building-an-sdk-installer'>
|
||||
<title>Building an SDK Installer</title>
|
||||
|
||||
<para>
|
||||
As an alternative to locating and downloading an SDK installer,
|
||||
you can build the SDK installer.
|
||||
Follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Set Up the Build Environment:</emphasis>
|
||||
Be sure you are set up to use BitBake in a shell.
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host'>Preparing the Build Host</ulink>"
|
||||
section in the Yocto Project Development Tasks Manual for
|
||||
information on how to get a build host ready that is either a
|
||||
native Linux machine or a machine that uses CROPS.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Clone the <filename>poky</filename> Repository:</emphasis>
|
||||
You need to have a local copy of the Yocto Project
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
||||
(i.e. a local <filename>poky</filename> repository).
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository'>Cloning the <filename>poky</filename> Repository</ulink>"
|
||||
and possibly the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out by Branch in Poky</ulink>"
|
||||
and
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#checkout-out-by-tag-in-poky'>Checking Out by Tag in Poky</ulink>"
|
||||
sections all in the Yocto Project Development Tasks Manual for
|
||||
information on how to clone the <filename>poky</filename>
|
||||
repository and check out the appropriate branch for your work.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Initialize the Build Environment:</emphasis>
|
||||
While in the root directory of the Source Directory (i.e.
|
||||
<filename>poky</filename>), run the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||||
environment setup script to define the OpenEmbedded
|
||||
build environment on your build host.
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_FILE;
|
||||
</literallayout>
|
||||
Among other things, the script creates the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
|
||||
which is <filename>build</filename> in this case
|
||||
and is located in the Source Directory.
|
||||
After the script runs, your current working directory
|
||||
is set to the <filename>build</filename> directory.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Make Sure You Are Building an Installer for the Correct Machine:</emphasis>
|
||||
Check to be sure that your
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
variable in the <filename>local.conf</filename> file in your
|
||||
Build Directory matches the architecture for which you are
|
||||
building.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Make Sure Your SDK Machine is Correctly Set:</emphasis>
|
||||
If you are building a toolchain designed to run on an
|
||||
architecture that differs from your current development host
|
||||
machine (i.e. the build host), be sure that the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
|
||||
variable in the <filename>local.conf</filename> file in your
|
||||
Build Directory is correctly set.
|
||||
<note>
|
||||
If you are building an SDK installer for the Extensible
|
||||
SDK, the <filename>SDKMACHINE</filename> value must be
|
||||
set for the architecture of the machine you are using to
|
||||
build the installer.
|
||||
If <filename>SDKMACHINE</filename> is not set appropriately,
|
||||
the build fails and provides an error message similar to
|
||||
the following:
|
||||
<literallayout class='monospaced'>
|
||||
The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is
|
||||
set to i686 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (x86_64).
|
||||
Unable to continue.
|
||||
</literallayout>
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Build the SDK Installer:</emphasis>
|
||||
To build the SDK installer for a standard SDK and populate
|
||||
the SDK image, use the following command form.
|
||||
Be sure to replace <replaceable>image</replaceable> with
|
||||
an image (e.g. "core-image-sato"):
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake <replaceable>image</replaceable> -c populate_sdk
|
||||
</literallayout>
|
||||
You can do the same for the extensible SDK using this command
|
||||
form:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake <replaceable>image</replaceable> -c populate_sdk_ext
|
||||
</literallayout>
|
||||
These commands produce an SDK installer that contains the
|
||||
sysroot that matches your target root filesystem.</para>
|
||||
|
||||
<para>When the <filename>bitbake</filename> command completes,
|
||||
the SDK installer will be in
|
||||
<filename>tmp/deploy/sdk</filename> in the Build Directory.
|
||||
<note><title>Notes</title>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
By default, the previous BitBake command does not
|
||||
build static binaries.
|
||||
If you want to use the toolchain to build these
|
||||
types of libraries, you need to be sure your SDK
|
||||
has the appropriate static development libraries.
|
||||
Use the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></ulink>
|
||||
variable inside your <filename>local.conf</filename>
|
||||
file before building the SDK installer.
|
||||
Doing so ensures that the eventual SDK installation
|
||||
process installs the appropriate library packages
|
||||
as part of the SDK.
|
||||
Following is an example using
|
||||
<filename>libc</filename> static development
|
||||
libraries:
|
||||
<literallayout class='monospaced'>
|
||||
TOOLCHAIN_TARGET_TASK_append = " libc-staticdev"
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Run the Installer:</emphasis>
|
||||
You can now run the SDK installer from
|
||||
<filename>tmp/deploy/sdk</filename> in the Build Directory.
|
||||
Following is an example:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky/build/tmp/deploy/sdk
|
||||
$ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
|
||||
</literallayout>
|
||||
During execution of the script, you choose the root location
|
||||
for the toolchain.
|
||||
See the
|
||||
"<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
|
||||
section and the
|
||||
"<link linkend='sdk-installed-extensible-sdk-directory-structure'>Installed Extensible SDK Directory Structure</link>"
|
||||
section for more information.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-extracting-the-root-filesystem'>
|
||||
<title>Extracting the Root Filesystem</title>
|
||||
|
||||
<para>
|
||||
After installing the toolchain, for some use cases you
|
||||
might need to separately extract a root filesystem:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
You want to boot the image using NFS.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
You want to use the root filesystem as the
|
||||
target sysroot.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
You want to develop your target application
|
||||
using the root filesystem as the target sysroot.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these steps to extract the root filesystem:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Locate and Download the Tarball for the Pre-Built
|
||||
Root Filesystem Image File:</emphasis>
|
||||
You need to find and download the root filesystem image
|
||||
file that is appropriate for your target system.
|
||||
These files are kept in machine-specific folders in the
|
||||
<ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/machines/'>Index of Releases</ulink>
|
||||
in the "machines" directory.</para>
|
||||
|
||||
<para>The machine-specific folders of the "machines" directory
|
||||
contain tarballs (<filename>*.tar.bz2</filename>) for supported
|
||||
machines.
|
||||
These directories also contain flattened root filesystem
|
||||
image files (<filename>*.ext4</filename>), which you can use
|
||||
with QEMU directly.</para>
|
||||
|
||||
<para>The pre-built root filesystem image files
|
||||
follow these naming conventions:
|
||||
<literallayout class='monospaced'>
|
||||
<!--
|
||||
core-image-<replaceable>profile</replaceable>-<replaceable>arch</replaceable>-<replaceable>date_time</replaceable>.rootfs.tar.bz2
|
||||
-->
|
||||
core-image-<replaceable>profile</replaceable>-<replaceable>arch</replaceable>.tar.bz2
|
||||
|
||||
Where:
|
||||
<replaceable>profile</replaceable> is the filesystem image's profile:
|
||||
lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, minimal-initramfs,
|
||||
sato, sato-dev, sato-sdk, sato-sdk-ptest. For information on
|
||||
these types of image profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
|
||||
the Yocto Project Reference Manual.
|
||||
|
||||
<replaceable>arch</replaceable> is a string representing the target architecture:
|
||||
beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb,
|
||||
genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*.
|
||||
|
||||
<!-->
|
||||
<replaceable>date_time</replaceable> is a date and time stamp.
|
||||
-->
|
||||
|
||||
</literallayout>
|
||||
The root filesystems provided by the Yocto Project are based
|
||||
off of the <filename>core-image-sato</filename> and
|
||||
<filename>core-image-minimal</filename> images.
|
||||
</para>
|
||||
|
||||
<para>For example, if you plan on using a BeagleBone device
|
||||
as your target hardware and your image is a
|
||||
<filename>core-image-sato-sdk</filename>
|
||||
image, you can download the following file:
|
||||
<literallayout class='monospaced'>
|
||||
core-image-sato-sdk-beaglebone-yocto.tar.bz2
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Initialize the Cross-Development Environment:</emphasis>
|
||||
You must <filename>source</filename> the cross-development
|
||||
environment setup script to establish necessary environment
|
||||
variables.</para>
|
||||
|
||||
<para>This script is located in the top-level directory in
|
||||
which you installed the toolchain (e.g.
|
||||
<filename>poky_sdk</filename>).</para>
|
||||
|
||||
<para>Following is an example based on the toolchain installed
|
||||
in the
|
||||
"<link linkend='sdk-locating-pre-built-sdk-installers'>Locating Pre-Built SDK Installers</link>"
|
||||
section:
|
||||
<literallayout class='monospaced'>
|
||||
$ source ~/poky_sdk/environment-setup-core2-64-poky-linux
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Extract the Root Filesystem:</emphasis>
|
||||
Use the <filename>runqemu-extract-sdk</filename> command
|
||||
and provide the root filesystem image.</para>
|
||||
|
||||
<para>Following is an example command that extracts the root
|
||||
filesystem from a previously built root filesystem image that
|
||||
was downloaded from the
|
||||
<ulink url='&YOCTO_DOCS_OM_URL;#index-downloads'>Index of Releases</ulink>.
|
||||
This command extracts the root filesystem into the
|
||||
<filename>core2-64-sato</filename> directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
|
||||
</literallayout>
|
||||
You could now point to the target sysroot at
|
||||
<filename>beablebone-sato</filename>.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-installed-standard-sdk-directory-structure'>
|
||||
<title>Installed Standard SDK Directory Structure</title>
|
||||
|
||||
<para>
|
||||
The following figure shows the resulting directory structure after
|
||||
you install the Standard SDK by running the <filename>*.sh</filename>
|
||||
SDK installation script:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/sdk-installed-standard-sdk-directory.png" scale="80" align="center" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The installed SDK consists of an environment setup script for the SDK,
|
||||
a configuration file for the target, a version file for the target,
|
||||
and the root filesystem (<filename>sysroots</filename>) needed to
|
||||
develop objects for the target system.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Within the figure, italicized text is used to indicate replaceable
|
||||
portions of the file or directory name.
|
||||
For example,
|
||||
<replaceable>install_dir</replaceable>/<replaceable>version</replaceable>
|
||||
is the directory where the SDK is installed.
|
||||
By default, this directory is <filename>/opt/poky/</filename>.
|
||||
And, <replaceable>version</replaceable> represents the specific
|
||||
snapshot of the SDK (e.g. <filename>&DISTRO;</filename>).
|
||||
Furthermore, <replaceable>target</replaceable> represents the target
|
||||
architecture (e.g. <filename>i586</filename>) and
|
||||
<replaceable>host</replaceable> represents the development system's
|
||||
architecture (e.g. <filename>x86_64</filename>).
|
||||
Thus, the complete names of the two directories within the
|
||||
<filename>sysroots</filename> could be
|
||||
<filename>i586-poky-linux</filename> and
|
||||
<filename>x86_64-pokysdk-linux</filename> for the target and host,
|
||||
respectively.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-installed-extensible-sdk-directory-structure'>
|
||||
<title>Installed Extensible SDK Directory Structure</title>
|
||||
|
||||
<para>
|
||||
The following figure shows the resulting directory structure after
|
||||
you install the Extensible SDK by running the <filename>*.sh</filename>
|
||||
SDK installation script:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<imagedata fileref="figures/sdk-installed-extensible-sdk-directory.png" scale="80" align="center" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The installed directory structure for the extensible SDK is quite
|
||||
different than the installed structure for the standard SDK.
|
||||
The extensible SDK does not separate host and target parts in the
|
||||
same manner as does the standard SDK.
|
||||
The extensible SDK uses an embedded copy of the OpenEmbedded
|
||||
build system, which has its own sysroots.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Of note in the directory structure are an environment setup script
|
||||
for the SDK, a configuration file for the target, a version file for
|
||||
the target, and log files for the OpenEmbedded build system
|
||||
preparation script run by the installer and BitBake.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Within the figure, italicized text is used to indicate replaceable
|
||||
portions of the file or directory name.
|
||||
For example,
|
||||
<replaceable>install_dir</replaceable> is the directory where the SDK
|
||||
is installed, which is <filename>poky_sdk</filename> by default, and
|
||||
<replaceable>target</replaceable> represents the target
|
||||
architecture (e.g. <filename>i586</filename>).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</appendix>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,353 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<chapter id='sdk-intro'>
|
||||
<title>Introduction</title>
|
||||
|
||||
<section id='sdk-manual-intro'>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
Welcome to the Yocto Project Application Development and the
|
||||
Extensible Software Development Kit (eSDK) manual.
|
||||
This manual provides information that explains how to use both the
|
||||
Yocto Project extensible and standard SDKs to develop
|
||||
applications and images.
|
||||
<note>
|
||||
Prior to the 2.0 Release of the Yocto Project, application
|
||||
development was primarily accomplished through the use of the
|
||||
Application Development Toolkit (ADT) and the availability
|
||||
of stand-alone cross-development toolchains and other tools.
|
||||
With the 2.1 Release of the Yocto Project, application development
|
||||
has transitioned to within a tool-rich extensible SDK and the more
|
||||
traditional standard SDK.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All SDKs consist of the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Cross-Development Toolchain</emphasis>:
|
||||
This toolchain contains a compiler, debugger, and various
|
||||
miscellaneous tools.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Libraries, Headers, and Symbols</emphasis>:
|
||||
The libraries, headers, and symbols are specific to the image
|
||||
(i.e. they match the image).
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Environment Setup Script</emphasis>:
|
||||
This <filename>*.sh</filename> file, once run, sets up the
|
||||
cross-development environment by defining variables and
|
||||
preparing for SDK use.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Additionally, an extensible SDK has tools that allow you to easily add
|
||||
new applications and libraries to an image, modify the source of an
|
||||
existing component, test changes on the target hardware, and easily
|
||||
integrate an application into the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can use an SDK to independently develop and test code
|
||||
that is destined to run on some target machine.
|
||||
SDKs are completely self-contained.
|
||||
The binaries are linked against their own copy of
|
||||
<filename>libc</filename>, which results in no dependencies
|
||||
on the target system.
|
||||
To achieve this, the pointer to the dynamic loader is
|
||||
configured at install time since that path cannot be dynamically
|
||||
altered.
|
||||
This is the reason for a wrapper around the
|
||||
<filename>populate_sdk</filename> and
|
||||
<filename>populate_sdk_ext</filename> archives.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another feature for the SDKs is that only one set of cross-compiler
|
||||
toolchain binaries are produced for any given architecture.
|
||||
This feature takes advantage of the fact that the target hardware can
|
||||
be passed to <filename>gcc</filename> as a set of compiler options.
|
||||
Those options are set up by the environment script and contained in
|
||||
variables such as
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
|
||||
This reduces the space needed for the tools.
|
||||
Understand, however, that every target still needs a sysroot because
|
||||
those binaries are target-specific.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The SDK development environment consists of the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
The self-contained SDK, which is an
|
||||
architecture-specific cross-toolchain and
|
||||
matching sysroots (target and native) all built by the
|
||||
OpenEmbedded build system (e.g. the SDK).
|
||||
The toolchain and sysroots are based on a
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
|
||||
configuration and extensions,
|
||||
which allows you to cross-develop on the host machine for the
|
||||
target hardware.
|
||||
Additionally, the extensible SDK contains the
|
||||
<filename>devtool</filename> functionality.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
The Quick EMUlator (QEMU), which lets you simulate
|
||||
target hardware.
|
||||
QEMU is not literally part of the SDK.
|
||||
You must build and include this emulator separately.
|
||||
However, QEMU plays an important role in the development
|
||||
process that revolves around use of the SDK.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In summary, the extensible and standard SDK share many features.
|
||||
However, the extensible SDK has powerful development tools to help you
|
||||
more quickly develop applications.
|
||||
Following is a table that summarizes the primary differences between
|
||||
the standard and extensible SDK types when considering which to
|
||||
build:
|
||||
<informaltable frame='none'>
|
||||
<tgroup cols='3' align='left' colsep='1' rowsep='1'>
|
||||
<colspec colname='c1' colwidth='1*'/>
|
||||
<colspec colname='c2' colwidth='1*'/>
|
||||
<colspec colname='c3' colwidth='1*'/>
|
||||
<thead>
|
||||
<row>
|
||||
<entry align="left"><emphasis>Feature</emphasis></entry>
|
||||
<entry align="left"><emphasis>Standard SDK</emphasis></entry>
|
||||
<entry align="left"><emphasis>Extensible SDK</emphasis></entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry align="left">Toolchain</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
<entry align="left">Yes*</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Debugger</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
<entry align="left">Yes*</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Size</entry>
|
||||
<entry align="left">100+ MBytes</entry>
|
||||
<entry align="left">1+ GBytes (or 300+ MBytes for minimal w/toolchain)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left"><filename>devtool</filename></entry>
|
||||
<entry align="left">No</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Build Images</entry>
|
||||
<entry align="left">No</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Updateable</entry>
|
||||
<entry align="left">No</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Managed Sysroot**</entry>
|
||||
<entry align="left">No</entry>
|
||||
<entry align="left">Yes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Installed Packages</entry>
|
||||
<entry align="left">No***</entry>
|
||||
<entry align="left">Yes****</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry align="left">Construction</entry>
|
||||
<entry align="left">Packages</entry>
|
||||
<entry align="left">Shared State</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
<literallayout class='monospaced'>
|
||||
* Extensible SDK contains the toolchain and debugger if <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></ulink> is "full" or <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink> is "1", which is the default.
|
||||
|
||||
** Sysroot is managed through the use of <filename>devtool</filename>. Thus, it is less likely that you will corrupt your SDK sysroot when you try to add additional libraries.
|
||||
|
||||
*** You can add runtime package management to the standard SDK but it is not supported by default.
|
||||
|
||||
**** You must build and make the shared state available to extensible SDK users for "packages" you want to enable users to install.
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<section id='the-cross-development-toolchain'>
|
||||
<title>The Cross-Development Toolchain</title>
|
||||
|
||||
<para>
|
||||
The
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
|
||||
consists of a cross-compiler, cross-linker, and cross-debugger
|
||||
that are used to develop user-space applications for targeted
|
||||
hardware.
|
||||
Additionally, for an extensible SDK, the toolchain also has
|
||||
built-in <filename>devtool</filename> functionality.
|
||||
This toolchain is created by running a SDK installer script
|
||||
or through a
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
||||
that is based on your metadata configuration or extension for
|
||||
your targeted device.
|
||||
The cross-toolchain works with a matching target sysroot.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sysroot'>
|
||||
<title>Sysroots</title>
|
||||
|
||||
<para>
|
||||
The native and target sysroots contain needed headers and libraries
|
||||
for generating binaries that run on the target architecture.
|
||||
The target sysroot is based on the target root filesystem image
|
||||
that is built by the OpenEmbedded build system and uses the same
|
||||
metadata configuration used to build the cross-toolchain.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='the-qemu-emulator'>
|
||||
<title>The QEMU Emulator</title>
|
||||
|
||||
<para>
|
||||
The QEMU emulator allows you to simulate your hardware while
|
||||
running your application or image.
|
||||
QEMU is not part of the SDK but is made available a number of
|
||||
different ways:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
If you have cloned the <filename>poky</filename> Git
|
||||
repository to create a
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
||||
and you have sourced the environment setup script, QEMU is
|
||||
installed and automatically available.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you have downloaded a Yocto Project release and unpacked
|
||||
it to create a Source Directory and you have sourced the
|
||||
environment setup script, QEMU is installed and
|
||||
automatically available.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you have installed the cross-toolchain tarball and you
|
||||
have sourced the toolchain's setup environment script, QEMU
|
||||
is also installed and automatically available.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='sdk-development-model'>
|
||||
<title>SDK Development Model</title>
|
||||
|
||||
<para>
|
||||
Fundamentally, the SDK fits into the development process as follows:
|
||||
<imagedata fileref="figures/sdk-environment.png" align="center" width="6in" depth="5in" scalefit="100" />
|
||||
The SDK is installed on any machine and can be used to develop
|
||||
applications, images, and kernels.
|
||||
An SDK can even be used by a QA Engineer or Release Engineer.
|
||||
The fundamental concept is that the machine that has the SDK installed
|
||||
does not have to be associated with the machine that has the
|
||||
Yocto Project installed.
|
||||
A developer can independently compile and test an object on their
|
||||
machine and then, when the object is ready for integration into an
|
||||
image, they can simply make it available to the machine that has the
|
||||
Yocto Project.
|
||||
Once the object is available, the image can be rebuilt using the
|
||||
Yocto Project to produce the modified image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You just need to follow these general steps:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Install the SDK for your target hardware:</emphasis>
|
||||
For information on how to install the SDK, see the
|
||||
"<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Download or Build the Target Image:</emphasis>
|
||||
The Yocto Project supports several target architectures
|
||||
and has many pre-built kernel images and root filesystem
|
||||
images.</para>
|
||||
|
||||
<para>If you are going to develop your application on
|
||||
hardware, go to the
|
||||
<ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
|
||||
download area and choose a target machine area
|
||||
from which to download the kernel image and root filesystem.
|
||||
This download area could have several files in it that
|
||||
support development using actual hardware.
|
||||
For example, the area might contain
|
||||
<filename>.hddimg</filename> files that combine the
|
||||
kernel image with the filesystem, boot loaders, and
|
||||
so forth.
|
||||
Be sure to get the files you need for your particular
|
||||
development process.</para>
|
||||
|
||||
<para>If you are going to develop your application and
|
||||
then run and test it using the QEMU emulator, go to the
|
||||
<ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
|
||||
download area.
|
||||
From this area, go down into the directory for your
|
||||
target architecture (e.g. <filename>qemux86_64</filename>
|
||||
for an <trademark class='registered'>Intel</trademark>-based
|
||||
64-bit architecture).
|
||||
Download the kernel, root filesystem, and any other files you
|
||||
need for your process.
|
||||
<note>
|
||||
To use the root filesystem in QEMU, you need to extract it.
|
||||
See the
|
||||
"<link linkend='sdk-extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
|
||||
section for information on how to extract the root
|
||||
filesystem.
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Develop and Test your Application:</emphasis>
|
||||
At this point, you have the tools to develop your application.
|
||||
If you need to separately install and use the QEMU emulator,
|
||||
you can go to
|
||||
<ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
|
||||
to download and learn about the emulator.
|
||||
See the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
|
||||
chapter in the Yocto Project Development Tasks Manual
|
||||
for information on using QEMU within the Yocto
|
||||
Project.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this manual describes how to use the extensible
|
||||
and standard SDKs.
|
||||
Information also exists in appendix form that describes how you can
|
||||
build, install, and modify an SDK.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
@@ -1,28 +0,0 @@
|
||||
<?xml version='1.0'?>
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
|
||||
|
||||
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
|
||||
|
||||
<!--
|
||||
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
|
||||
|
||||
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
|
||||
|
||||
-->
|
||||
|
||||
<xsl:include href="../template/permalinks.xsl"/>
|
||||
<xsl:include href="../template/section.title.xsl"/>
|
||||
<xsl:include href="../template/component.title.xsl"/>
|
||||
<xsl:include href="../template/division.title.xsl"/>
|
||||
<xsl:include href="../template/formal.object.heading.xsl"/>
|
||||
|
||||
<xsl:param name="html.stylesheet" select="'sdk-style.css'" />
|
||||
<xsl:param name="chapter.autolabel" select="1" />
|
||||
<xsl:param name="appendix.autolabel">A</xsl:param>
|
||||
<xsl:param name="section.autolabel" select="1" />
|
||||
<xsl:param name="section.label.includes.component.label" select="1" />
|
||||
<xsl:param name="generate.id.attributes" select="1" />
|
||||
|
||||
</xsl:stylesheet>
|
||||
@@ -1,159 +0,0 @@
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<book id='sdk-manual' lang='en'
|
||||
xmlns:xi="http://www.w3.org/2003/XInclude"
|
||||
xmlns="http://docbook.org/ns/docbook"
|
||||
>
|
||||
<bookinfo>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref='figures/sdk-title.png'
|
||||
format='SVG'
|
||||
align='left' scalefit='1' width='100%'/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
|
||||
<title>
|
||||
Yocto Project Application Development and the Extensible Software Development Kit (eSDK)
|
||||
</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<affiliation>
|
||||
<orgname>&ORGNAME;</orgname>
|
||||
</affiliation>
|
||||
<email>&ORGEMAIL;</email>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>2.1</revnumber>
|
||||
<date>April 2016</date>
|
||||
<revremark>The initial document released with the Yocto Project 2.1 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.2</revnumber>
|
||||
<date>October 2016</date>
|
||||
<revremark>Released with the Yocto Project 2.2 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.3</revnumber>
|
||||
<date>May 2017</date>
|
||||
<revremark>Released with the Yocto Project 2.3 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.4</revnumber>
|
||||
<date>October 2017</date>
|
||||
<revremark>Released with the Yocto Project 2.4 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.5</revnumber>
|
||||
<date>May 2018</date>
|
||||
<revremark>Released with the Yocto Project 2.5 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.6</revnumber>
|
||||
<date>November 2018</date>
|
||||
<revremark>Released with the Yocto Project 2.6 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.7</revnumber>
|
||||
<date>May 2019</date>
|
||||
<revremark>Released with the Yocto Project 2.7 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>3.0</revnumber>
|
||||
<date>October 2019</date>
|
||||
<revremark>Released with the Yocto Project 3.0 Release.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>3.1</revnumber>
|
||||
<date>&REL_MONTH_YEAR;</date>
|
||||
<revremark>Released with the Yocto Project 3.1 Release.</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
|
||||
<copyright>
|
||||
<year>©RIGHT_YEAR;</year>
|
||||
<holder>Linux Foundation</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
Permission is granted to copy, distribute and/or modify this document under
|
||||
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England & Wales</ulink> as published by Creative Commons.
|
||||
</para>
|
||||
<note><title>Manual Notes</title>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
This version of the
|
||||
<emphasis>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</emphasis>
|
||||
manual is for the &YOCTO_DOC_VERSION; release of the
|
||||
Yocto Project.
|
||||
To be sure you have the latest version of the manual
|
||||
for this release, go to the
|
||||
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
|
||||
and select the manual from that site.
|
||||
Manuals from the site are more up-to-date than manuals
|
||||
derived from the Yocto Project released TAR files.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
If you located this manual through a web search, the
|
||||
version of the manual might not be the one you want
|
||||
(e.g. the search might have returned a manual much
|
||||
older than the Yocto Project version with which you
|
||||
are working).
|
||||
You can see all Yocto Project major releases by
|
||||
visiting the
|
||||
<ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
|
||||
page.
|
||||
If you need a version of this manual for a different
|
||||
Yocto Project release, visit the
|
||||
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
|
||||
and select the manual set by using the
|
||||
"ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
|
||||
pull-down menus.
|
||||
</para></listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
To report any inaccuracies or problems with this
|
||||
(or any other Yocto Project) manual, send an email to
|
||||
the Yocto Project documentation mailing list at
|
||||
<filename>docs@lists.yoctoproject.org</filename> or
|
||||
log into the freenode <filename>#yocto</filename> channel.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</note>
|
||||
</legalnotice>
|
||||
|
||||
</bookinfo>
|
||||
|
||||
<xi:include href="sdk-intro.xml"/>
|
||||
|
||||
<xi:include href="sdk-extensible.xml"/>
|
||||
|
||||
<xi:include href="sdk-using.xml"/>
|
||||
|
||||
<xi:include href="sdk-working-projects.xml"/>
|
||||
|
||||
<xi:include href="sdk-appendix-obtain.xml"/>
|
||||
|
||||
<xi:include href="sdk-appendix-customizing.xml"/>
|
||||
|
||||
<xi:include href="sdk-appendix-customizing-standard.xml"/>
|
||||
|
||||
<!-- <index id='index'>
|
||||
<title>Index</title>
|
||||
</index>
|
||||
-->
|
||||
|
||||
</book>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
@@ -1,991 +0,0 @@
|
||||
/*
|
||||
|
||||
SPDX-License-Identifier: CC-BY-2.0-UK
|
||||
|
||||
Generic XHTML / DocBook XHTML CSS Stylesheet.
|
||||
|
||||
Browser wrangling and typographic design by
|
||||
Oyvind Kolas / pippin@gimp.org
|
||||
|
||||
Customised for Poky by
|
||||
Matthew Allum / mallum@o-hand.com
|
||||
|
||||
Thanks to:
|
||||
Liam R. E. Quin
|
||||
William Skaggs
|
||||
Jakub Steiner
|
||||
|
||||
Structure
|
||||
---------
|
||||
|
||||
The stylesheet is divided into the following sections:
|
||||
|
||||
Positioning
|
||||
Margins, paddings, width, font-size, clearing.
|
||||
Decorations
|
||||
Borders, style
|
||||
Colors
|
||||
Colors
|
||||
Graphics
|
||||
Graphical backgrounds
|
||||
Nasty IE tweaks
|
||||
Workarounds needed to make it work in internet explorer,
|
||||
currently makes the stylesheet non validating, but up until
|
||||
this point it is validating.
|
||||
Mozilla extensions
|
||||
Transparency for footer
|
||||
Rounded corners on boxes
|
||||
|
||||
*/
|
||||
|
||||
|
||||
/*************** /
|
||||
/ Positioning /
|
||||
/ ***************/
|
||||
|
||||
body {
|
||||
font-family: Verdana, Sans, sans-serif;
|
||||
|
||||
min-width: 640px;
|
||||
width: 80%;
|
||||
margin: 0em auto;
|
||||
padding: 2em 5em 5em 5em;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
h1,h2,h3,h4,h5,h6,h7 {
|
||||
font-family: Arial, Sans;
|
||||
color: #00557D;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2em;
|
||||
text-align: left;
|
||||
padding: 0em 0em 0em 0em;
|
||||
margin: 2em 0em 0em 0em;
|
||||
}
|
||||
|
||||
h2.subtitle {
|
||||
margin: 0.10em 0em 3.0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-size: 1.8em;
|
||||
padding-left: 20%;
|
||||
font-weight: normal;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin: 2em 0em 0.66em 0em;
|
||||
padding: 0.5em 0em 0em 0em;
|
||||
font-size: 1.5em;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h3.subtitle {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-size: 142.14%;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 140%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h4 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 120%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h5 {
|
||||
margin: 1em 0em 0.5em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 110%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
h6 {
|
||||
margin: 1em 0em 0em 0em;
|
||||
padding: 1em 0em 0em 0em;
|
||||
font-size: 110%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.authorgroup {
|
||||
background-color: transparent;
|
||||
background-repeat: no-repeat;
|
||||
padding-top: 256px;
|
||||
background-image: url("figures/sdk-title.png");
|
||||
background-position: left top;
|
||||
margin-top: -256px;
|
||||
padding-right: 50px;
|
||||
margin-left: 0px;
|
||||
text-align: right;
|
||||
width: 740px;
|
||||
}
|
||||
|
||||
h3.author {
|
||||
margin: 0em 0me 0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
font-weight: normal;
|
||||
font-size: 100%;
|
||||
color: #333;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.author tt.email {
|
||||
font-size: 66%;
|
||||
}
|
||||
|
||||
.titlepage hr {
|
||||
width: 0em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.revhistory {
|
||||
padding-top: 2em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.toc,
|
||||
.list-of-tables,
|
||||
.list-of-examples,
|
||||
.list-of-figures {
|
||||
padding: 1.33em 0em 2.5em 0em;
|
||||
color: #00557D;
|
||||
}
|
||||
|
||||
.toc p,
|
||||
.list-of-tables p,
|
||||
.list-of-figures p,
|
||||
.list-of-examples p {
|
||||
padding: 0em 0em 0em 0em;
|
||||
padding: 0em 0em 0.3em;
|
||||
margin: 1.5em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc p b,
|
||||
.list-of-tables p b,
|
||||
.list-of-figures p b,
|
||||
.list-of-examples p b{
|
||||
font-size: 100.0%;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.toc dl,
|
||||
.list-of-tables dl,
|
||||
.list-of-figures dl,
|
||||
.list-of-examples dl {
|
||||
margin: 0em 0em 0.5em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc dt {
|
||||
margin: 0em 0em 0em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.toc dd {
|
||||
margin: 0em 0em 0em 2.6em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
div.glossary dl,
|
||||
div.variablelist dl {
|
||||
}
|
||||
|
||||
.glossary dl dt,
|
||||
.variablelist dl dt,
|
||||
.variablelist dl dt span.term {
|
||||
font-weight: normal;
|
||||
width: 20em;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
.variablelist dl dt {
|
||||
margin-top: 0.5em;
|
||||
}
|
||||
|
||||
.glossary dl dd,
|
||||
.variablelist dl dd {
|
||||
margin-top: -1em;
|
||||
margin-left: 25.5em;
|
||||
}
|
||||
|
||||
.glossary dd p,
|
||||
.variablelist dd p {
|
||||
margin-top: 0em;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
|
||||
div.calloutlist table td {
|
||||
padding: 0em 0em 0em 0em;
|
||||
margin: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
div.calloutlist table td p {
|
||||
margin-top: 0em;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
div p.copyright {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
div.legalnotice p.legalnotice-title {
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
p {
|
||||
line-height: 1.5em;
|
||||
margin-top: 0em;
|
||||
|
||||
}
|
||||
|
||||
dl {
|
||||
padding-top: 0em;
|
||||
}
|
||||
|
||||
hr {
|
||||
border: solid 1px;
|
||||
}
|
||||
|
||||
|
||||
.mediaobject,
|
||||
.mediaobjectco {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
img {
|
||||
border: none;
|
||||
}
|
||||
|
||||
ul {
|
||||
padding: 0em 0em 0em 1.5em;
|
||||
}
|
||||
|
||||
ul li {
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
ul li p {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
table {
|
||||
width :100%;
|
||||
}
|
||||
|
||||
th {
|
||||
padding: 0.25em;
|
||||
text-align: left;
|
||||
font-weight: normal;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
td {
|
||||
padding: 0.25em;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
p a[id] {
|
||||
margin: 0px;
|
||||
padding: 0px;
|
||||
display: inline;
|
||||
background-image: none;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration: underline;
|
||||
color: #444;
|
||||
}
|
||||
|
||||
pre {
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
text-decoration: underline;
|
||||
/*font-weight: bold;*/
|
||||
}
|
||||
|
||||
/* This style defines how the permalink character
|
||||
appears by itself and when hovered over with
|
||||
the mouse. */
|
||||
|
||||
[alt='Permalink'] { color: #eee; }
|
||||
[alt='Permalink']:hover { color: black; }
|
||||
|
||||
|
||||
div.informalfigure,
|
||||
div.informalexample,
|
||||
div.informaltable,
|
||||
div.figure,
|
||||
div.table,
|
||||
div.example {
|
||||
margin: 1em 0em;
|
||||
padding: 1em;
|
||||
page-break-inside: avoid;
|
||||
}
|
||||
|
||||
|
||||
div.informalfigure p.title b,
|
||||
div.informalexample p.title b,
|
||||
div.informaltable p.title b,
|
||||
div.figure p.title b,
|
||||
div.example p.title b,
|
||||
div.table p.title b{
|
||||
padding-top: 0em;
|
||||
margin-top: 0em;
|
||||
font-size: 100%;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
.mediaobject .caption,
|
||||
.mediaobject .caption p {
|
||||
text-align: center;
|
||||
font-size: 80%;
|
||||
padding-top: 0.5em;
|
||||
padding-bottom: 0.5em;
|
||||
}
|
||||
|
||||
.epigraph {
|
||||
padding-left: 55%;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
.epigraph p {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.epigraph .quote {
|
||||
font-style: italic;
|
||||
}
|
||||
.epigraph .attribution {
|
||||
font-style: normal;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
span.application {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.programlisting {
|
||||
font-family: monospace;
|
||||
font-size: 80%;
|
||||
white-space: pre;
|
||||
margin: 1.33em 0em;
|
||||
padding: 1.33em;
|
||||
}
|
||||
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
margin-top: 1em;
|
||||
margin-bottom: 1em;
|
||||
|
||||
}
|
||||
|
||||
/* force full width of table within div */
|
||||
.tip table,
|
||||
.warning table,
|
||||
.caution table,
|
||||
.note table {
|
||||
border: none;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
padding: 0.8em 0.0em 0.0em 0.0em;
|
||||
margin : 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.tip p,
|
||||
.warning p,
|
||||
.caution p,
|
||||
.note p {
|
||||
margin-top: 0.5em;
|
||||
margin-bottom: 0.5em;
|
||||
padding-right: 1em;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.acronym {
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
padding: 0.09em 0.3em;
|
||||
margin: 0em;
|
||||
}
|
||||
|
||||
.itemizedlist li {
|
||||
clear: none;
|
||||
}
|
||||
|
||||
.filename {
|
||||
font-size: medium;
|
||||
font-family: Courier, monospace;
|
||||
}
|
||||
|
||||
|
||||
div.navheader, div.heading{
|
||||
position: absolute;
|
||||
left: 0em;
|
||||
top: 0em;
|
||||
width: 100%;
|
||||
background-color: #cdf;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navfooter, div.footing{
|
||||
position: fixed;
|
||||
left: 0em;
|
||||
bottom: 0em;
|
||||
background-color: #eee;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
|
||||
div.navheader td,
|
||||
div.navfooter td {
|
||||
font-size: 66%;
|
||||
}
|
||||
|
||||
div.navheader table th {
|
||||
/*font-family: Georgia, Times, serif;*/
|
||||
/*font-size: x-large;*/
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
div.navheader table {
|
||||
border-left: 0em;
|
||||
border-right: 0em;
|
||||
border-top: 0em;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navfooter table {
|
||||
border-left: 0em;
|
||||
border-right: 0em;
|
||||
border-bottom: 0em;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
div.navheader table td a,
|
||||
div.navfooter table td a {
|
||||
color: #777;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
/* normal text in the footer */
|
||||
div.navfooter table td {
|
||||
color: black;
|
||||
}
|
||||
|
||||
div.navheader table td a:visited,
|
||||
div.navfooter table td a:visited {
|
||||
color: #444;
|
||||
}
|
||||
|
||||
|
||||
/* links in header and footer */
|
||||
div.navheader table td a:hover,
|
||||
div.navfooter table td a:hover {
|
||||
text-decoration: underline;
|
||||
background-color: transparent;
|
||||
color: #33a;
|
||||
}
|
||||
|
||||
div.navheader hr,
|
||||
div.navfooter hr {
|
||||
display: none;
|
||||
}
|
||||
|
||||
|
||||
.qandaset tr.question td p {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
|
||||
.qandaset tr.answer td p {
|
||||
margin: 0em 0em 1em 0em;
|
||||
padding: 0em 0em 0em 0em;
|
||||
}
|
||||
.answer td {
|
||||
padding-bottom: 1.5em;
|
||||
}
|
||||
|
||||
.emphasis {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
|
||||
/************* /
|
||||
/ decorations /
|
||||
/ *************/
|
||||
|
||||
.titlepage {
|
||||
}
|
||||
|
||||
.part .title {
|
||||
}
|
||||
|
||||
.subtitle {
|
||||
border: none;
|
||||
}
|
||||
|
||||
/*
|
||||
h1 {
|
||||
border: none;
|
||||
}
|
||||
|
||||
h2 {
|
||||
border-top: solid 0.2em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h3 {
|
||||
border-top: 0em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h4 {
|
||||
border: 0em;
|
||||
border-bottom: solid 0.06em;
|
||||
}
|
||||
|
||||
h5 {
|
||||
border: 0em;
|
||||
}
|
||||
*/
|
||||
|
||||
.programlisting {
|
||||
border: solid 1px;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample,
|
||||
div.example {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
border-bottom: 1px solid;
|
||||
}
|
||||
|
||||
.question td {
|
||||
border-top: 1px solid black;
|
||||
}
|
||||
|
||||
.answer {
|
||||
}
|
||||
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
border: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
div.navheader, div.heading{
|
||||
border-bottom: 1px solid;
|
||||
}
|
||||
|
||||
|
||||
div.navfooter, div.footing{
|
||||
border-top: 1px solid;
|
||||
}
|
||||
|
||||
/********* /
|
||||
/ colors /
|
||||
/ *********/
|
||||
|
||||
body {
|
||||
color: #333;
|
||||
background: white;
|
||||
}
|
||||
|
||||
a {
|
||||
background: transparent;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
background-color: #dedede;
|
||||
}
|
||||
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
h7,
|
||||
h8 {
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
hr {
|
||||
border-color: #aaa;
|
||||
}
|
||||
|
||||
|
||||
.tip, .warning, .caution, .note {
|
||||
border-color: #fff;
|
||||
}
|
||||
|
||||
|
||||
.tip table th,
|
||||
.warning table th,
|
||||
.caution table th,
|
||||
.note table th {
|
||||
border-bottom-color: #fff;
|
||||
}
|
||||
|
||||
|
||||
.warning {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.caution {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.tip {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.note {
|
||||
background-color: #f0f0f2;
|
||||
}
|
||||
|
||||
.writernotes {
|
||||
color: #ff0000;
|
||||
}
|
||||
|
||||
.glossary dl dt,
|
||||
.variablelist dl dt,
|
||||
.variablelist dl dt span.term {
|
||||
color: #044;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.example,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample {
|
||||
border-color: #aaa;
|
||||
}
|
||||
|
||||
pre.programlisting {
|
||||
color: black;
|
||||
background-color: #fff;
|
||||
border-color: #aaa;
|
||||
border-width: 2px;
|
||||
}
|
||||
|
||||
.guimenu,
|
||||
.guilabel,
|
||||
.guimenuitem {
|
||||
background-color: #eee;
|
||||
}
|
||||
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
background-color: #eee;
|
||||
border-color: #999;
|
||||
}
|
||||
|
||||
|
||||
div.navheader {
|
||||
border-color: black;
|
||||
}
|
||||
|
||||
|
||||
div.navfooter {
|
||||
border-color: black;
|
||||
}
|
||||
|
||||
|
||||
/*********** /
|
||||
/ graphics /
|
||||
/ ***********/
|
||||
|
||||
/*
|
||||
body {
|
||||
background-image: url("images/body_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.navheader,
|
||||
.note,
|
||||
.tip {
|
||||
background-image: url("images/note_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.warning,
|
||||
.caution {
|
||||
background-image: url("images/warning_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
.figure,
|
||||
.informalfigure,
|
||||
.example,
|
||||
.informalexample,
|
||||
.table,
|
||||
.informaltable {
|
||||
background-image: url("images/figure_bg.jpg");
|
||||
background-attachment: fixed;
|
||||
}
|
||||
|
||||
*/
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
h7{
|
||||
}
|
||||
|
||||
/*
|
||||
Example of how to stick an image as part of the title.
|
||||
|
||||
div.article .titlepage .title
|
||||
{
|
||||
background-image: url("figures/white-on-black.png");
|
||||
background-position: center;
|
||||
background-repeat: repeat-x;
|
||||
}
|
||||
*/
|
||||
|
||||
div.preface .titlepage .title,
|
||||
div.colophon .title,
|
||||
div.chapter .titlepage .title,
|
||||
div.article .titlepage .title
|
||||
{
|
||||
}
|
||||
|
||||
div.section div.section .titlepage .title,
|
||||
div.sect2 .titlepage .title {
|
||||
background: none;
|
||||
}
|
||||
|
||||
|
||||
h1.title {
|
||||
background-color: transparent;
|
||||
background-repeat: no-repeat;
|
||||
height: 256px;
|
||||
text-indent: -9000px;
|
||||
overflow:hidden;
|
||||
}
|
||||
|
||||
h2.subtitle {
|
||||
background-color: transparent;
|
||||
text-indent: -9000px;
|
||||
overflow:hidden;
|
||||
width: 0px;
|
||||
display: none;
|
||||
}
|
||||
|
||||
/*************************************** /
|
||||
/ pippin.gimp.org specific alterations /
|
||||
/ ***************************************/
|
||||
|
||||
/*
|
||||
div.heading, div.navheader {
|
||||
color: #777;
|
||||
font-size: 80%;
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
text-align: left;
|
||||
position: absolute;
|
||||
top: 0px;
|
||||
left: 0px;
|
||||
width: 100%;
|
||||
height: 50px;
|
||||
background: url('/gfx/heading_bg.png') transparent;
|
||||
background-repeat: repeat-x;
|
||||
background-attachment: fixed;
|
||||
border: none;
|
||||
}
|
||||
|
||||
div.heading a {
|
||||
color: #444;
|
||||
}
|
||||
|
||||
div.footing, div.navfooter {
|
||||
border: none;
|
||||
color: #ddd;
|
||||
font-size: 80%;
|
||||
text-align:right;
|
||||
|
||||
width: 100%;
|
||||
padding-top: 10px;
|
||||
position: absolute;
|
||||
bottom: 0px;
|
||||
left: 0px;
|
||||
|
||||
background: url('/gfx/footing_bg.png') transparent;
|
||||
}
|
||||
*/
|
||||
|
||||
|
||||
|
||||
/****************** /
|
||||
/ nasty ie tweaks /
|
||||
/ ******************/
|
||||
|
||||
/*
|
||||
div.heading, div.navheader {
|
||||
width:expression(document.body.clientWidth + "px");
|
||||
}
|
||||
|
||||
div.footing, div.navfooter {
|
||||
width:expression(document.body.clientWidth + "px");
|
||||
margin-left:expression("-5em");
|
||||
}
|
||||
body {
|
||||
padding:expression("4em 5em 0em 5em");
|
||||
}
|
||||
*/
|
||||
|
||||
/**************************************** /
|
||||
/ mozilla vendor specific css extensions /
|
||||
/ ****************************************/
|
||||
/*
|
||||
div.navfooter, div.footing{
|
||||
-moz-opacity: 0.8em;
|
||||
}
|
||||
|
||||
div.figure,
|
||||
div.table,
|
||||
div.informalfigure,
|
||||
div.informaltable,
|
||||
div.informalexample,
|
||||
div.example,
|
||||
.tip,
|
||||
.warning,
|
||||
.caution,
|
||||
.note {
|
||||
-moz-border-radius: 0.5em;
|
||||
}
|
||||
|
||||
b.keycap,
|
||||
.keycap {
|
||||
-moz-border-radius: 0.3em;
|
||||
}
|
||||
*/
|
||||
|
||||
table tr td table tr td {
|
||||
display: none;
|
||||
}
|
||||
|
||||
|
||||
hr {
|
||||
display: none;
|
||||
}
|
||||
|
||||
table {
|
||||
border: 0em;
|
||||
}
|
||||
|
||||
.photo {
|
||||
float: right;
|
||||
margin-left: 1.5em;
|
||||
margin-bottom: 1.5em;
|
||||
margin-top: 0em;
|
||||
max-width: 17em;
|
||||
border: 1px solid gray;
|
||||
padding: 3px;
|
||||
background: white;
|
||||
}
|
||||
.seperator {
|
||||
padding-top: 2em;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
#validators {
|
||||
margin-top: 5em;
|
||||
text-align: right;
|
||||
color: #777;
|
||||
}
|
||||
@media print {
|
||||
body {
|
||||
font-size: 8pt;
|
||||
}
|
||||
.noprint {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
.tip,
|
||||
.note {
|
||||
background: #f0f0f2;
|
||||
color: #333;
|
||||
padding: 20px;
|
||||
margin: 20px;
|
||||
}
|
||||
|
||||
.tip h3,
|
||||
.note h3 {
|
||||
padding: 0em;
|
||||
margin: 0em;
|
||||
font-size: 2em;
|
||||
font-weight: bold;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
.tip a,
|
||||
.note a {
|
||||
color: #333;
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.footnote {
|
||||
font-size: small;
|
||||
color: #333;
|
||||
}
|
||||
|
||||
/* Changes the announcement text */
|
||||
.tip h3,
|
||||
.warning h3,
|
||||
.caution h3,
|
||||
.note h3 {
|
||||
font-size:large;
|
||||
color: #00557D;
|
||||
}
|
||||
@@ -1,201 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<chapter id='sdk-using-the-standard-sdk'>
|
||||
<title>Using the Standard SDK</title>
|
||||
|
||||
<para>
|
||||
This chapter describes the standard SDK and how to install it.
|
||||
Information includes unique installation and setup aspects for the
|
||||
standard SDK.
|
||||
<note>
|
||||
For a side-by-side comparison of main features supported for a
|
||||
standard SDK as compared to an extensible SDK, see the
|
||||
"<link linkend='sdk-manual-intro'>Introduction</link>"
|
||||
section.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can use a standard SDK to work on Makefile and Autotools-based
|
||||
projects.
|
||||
See the
|
||||
"<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>"
|
||||
chapter for more information.
|
||||
</para>
|
||||
|
||||
<section id='sdk-standard-sdk-intro'>
|
||||
<title>Why use the Standard SDK and What is in It?</title>
|
||||
|
||||
<para>
|
||||
The Standard SDK provides a cross-development toolchain and
|
||||
libraries tailored to the contents of a specific image.
|
||||
You would use the Standard SDK if you want a more traditional
|
||||
toolchain experience as compared to the extensible SDK, which
|
||||
provides an internal build system and the
|
||||
<filename>devtool</filename> functionality.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The installed Standard SDK consists of several files and
|
||||
directories.
|
||||
Basically, it contains an SDK environment setup script, some
|
||||
configuration files, and host and target root filesystems to
|
||||
support usage.
|
||||
You can see the directory structure in the
|
||||
"<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
|
||||
section.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-installing-the-sdk'>
|
||||
<title>Installing the SDK</title>
|
||||
|
||||
<para>
|
||||
The first thing you need to do is install the SDK on your
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
|
||||
by running the <filename>*.sh</filename> installation script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can download a tarball installer, which includes the
|
||||
pre-built toolchain, the <filename>runqemu</filename>
|
||||
script, and support files from the appropriate
|
||||
<ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchain</ulink>
|
||||
directory within the Index of Releases.
|
||||
Toolchains are available for several 32-bit and 64-bit
|
||||
architectures with the <filename>x86_64</filename> directories,
|
||||
respectively.
|
||||
The toolchains the Yocto Project provides are based off the
|
||||
<filename>core-image-sato</filename> and
|
||||
<filename>core-image-minimal</filename> images and contain
|
||||
libraries appropriate for developing against that image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The names of the tarball installer scripts are such that a
|
||||
string representing the host system appears first in the
|
||||
filename and then is immediately followed by a string
|
||||
representing the target architecture.
|
||||
<literallayout class='monospaced'>
|
||||
poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
|
||||
|
||||
Where:
|
||||
<replaceable>host_system</replaceable> is a string representing your development system:
|
||||
|
||||
i686 or x86_64.
|
||||
|
||||
<replaceable>image_type</replaceable> is the image for which the SDK was built:
|
||||
|
||||
core-image-minimal or core-image-sato.
|
||||
|
||||
<replaceable>arch</replaceable> is a string representing the tuned target architecture:
|
||||
|
||||
aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon.
|
||||
|
||||
<replaceable>release_version</replaceable> is a string representing the release number of the Yocto Project:
|
||||
|
||||
&DISTRO;, &DISTRO;+snapshot
|
||||
</literallayout>
|
||||
For example, the following SDK installer is for a 64-bit
|
||||
development host system and a i586-tuned target architecture
|
||||
based off the SDK for <filename>core-image-sato</filename> and
|
||||
using the current &DISTRO; snapshot:
|
||||
<literallayout class='monospaced'>
|
||||
poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
|
||||
</literallayout>
|
||||
<note>
|
||||
As an alternative to downloading an SDK, you can build the
|
||||
SDK installer.
|
||||
For information on building the installer, see the
|
||||
"<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
|
||||
section.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The SDK and toolchains are self-contained and by default are
|
||||
installed into the <filename>poky_sdk</filename> folder in your
|
||||
home directory.
|
||||
You can choose to install the extensible SDK in any location when
|
||||
you run the installer.
|
||||
However, because files need to be written under that directory
|
||||
during the normal course of operation, the location you choose
|
||||
for installation must be writable for whichever
|
||||
users need to use the SDK.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following command shows how to run the installer given a
|
||||
toolchain tarball for a 64-bit x86 development host system and
|
||||
a 64-bit x86 target architecture.
|
||||
The example assumes the SDK installer is located in
|
||||
<filename>~/Downloads/</filename> and has execution rights.
|
||||
<note>
|
||||
If you do not have write permissions for the directory
|
||||
into which you are installing the SDK, the installer
|
||||
notifies you and exits.
|
||||
For that case, set up the proper permissions in the directory
|
||||
and run the installer again.
|
||||
</note>
|
||||
<literallayout class='monospaced'>
|
||||
$ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
|
||||
Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
|
||||
===============================================================
|
||||
Enter target directory for SDK (default: /opt/poky/&DISTRO;):
|
||||
You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed [Y/n]? Y
|
||||
Extracting SDK........................................ ..............................done
|
||||
Setting it up...done
|
||||
SDK has been successfully set up and is ready to be used.
|
||||
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
|
||||
$ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Again, reference the
|
||||
"<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
|
||||
section for more details on the resulting directory structure of
|
||||
the installed SDK.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='sdk-running-the-sdk-environment-setup-script'>
|
||||
<title>Running the SDK Environment Setup Script</title>
|
||||
|
||||
<para>
|
||||
Once you have the SDK installed, you must run the SDK environment
|
||||
setup script before you can actually use the SDK.
|
||||
This setup script resides in the directory you chose when you
|
||||
installed the SDK, which is either the default
|
||||
<filename>/opt/poky/&DISTRO;</filename> directory or the directory
|
||||
you chose during installation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before running the script, be sure it is the one that matches the
|
||||
architecture for which you are developing.
|
||||
Environment setup scripts begin with the string
|
||||
"<filename>environment-setup</filename>" and include as part of
|
||||
their name the tuned target architecture.
|
||||
As an example, the following commands set the working directory
|
||||
to where the SDK was installed and then source the environment
|
||||
setup script.
|
||||
In this example, the setup script is for an IA-based
|
||||
target machine using i586 tuning:
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
</literallayout>
|
||||
When you run the setup script, the same environment variables are
|
||||
defined as are when you run the setup script for an extensible SDK.
|
||||
See the
|
||||
"<link linkend='sdk-running-the-extensible-sdk-environment-setup-script'>Running the Extensible SDK Environment Setup Script</link>"
|
||||
section for more information.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
@@ -1,511 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||||
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||||
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
|
||||
|
||||
<chapter id='sdk-working-projects'>
|
||||
|
||||
<title>Using the SDK Toolchain Directly</title>
|
||||
|
||||
<para>
|
||||
You can use the SDK toolchain directly with Makefile and
|
||||
Autotools-based projects.
|
||||
</para>
|
||||
|
||||
<section id='autotools-based-projects'>
|
||||
<title>Autotools-Based Projects</title>
|
||||
|
||||
<para>
|
||||
Once you have a suitable
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain'>cross-development toolchain</ulink>
|
||||
installed, it is very easy to develop a project using the
|
||||
<ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>GNU Autotools-based</ulink>
|
||||
workflow, which is outside of the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following figure presents a simple Autotools workflow.
|
||||
<imagedata fileref="figures/sdk-autotools-flow.png" width="7in" height="8in" align="center" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these steps to create a simple Autotools-based
|
||||
"Hello World" project:
|
||||
<note>
|
||||
For more information on the GNU Autotools workflow,
|
||||
see the same example on the
|
||||
<ulink url='https://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en'>GNOME Developer</ulink>
|
||||
site.
|
||||
</note>
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Create a Working Directory and Populate It:</emphasis>
|
||||
Create a clean directory for your project and then make
|
||||
that directory your working location.
|
||||
<literallayout class='monospaced'>
|
||||
$ mkdir $HOME/helloworld
|
||||
$ cd $HOME/helloworld
|
||||
</literallayout>
|
||||
After setting up the directory, populate it with files
|
||||
needed for the flow.
|
||||
You need a project source file, a file to help with
|
||||
configuration, and a file to help create the Makefile,
|
||||
and a README file:
|
||||
<filename>hello.c</filename>,
|
||||
<filename>configure.ac</filename>,
|
||||
<filename>Makefile.am</filename>, and
|
||||
<filename>README</filename>, respectively.</para>
|
||||
|
||||
<para> Use the following command to create an empty README
|
||||
file, which is required by GNU Coding Standards:
|
||||
<literallayout class='monospaced'>
|
||||
$ touch README
|
||||
</literallayout>
|
||||
Create the remaining three files as follows:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis><filename>hello.c</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
#include <stdio.h>
|
||||
|
||||
main()
|
||||
{
|
||||
printf("Hello World!\n");
|
||||
}
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis><filename>configure.ac</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
AC_INIT(hello,0.1)
|
||||
AM_INIT_AUTOMAKE([foreign])
|
||||
AC_PROG_CC
|
||||
AC_CONFIG_FILES(Makefile)
|
||||
AC_OUTPUT
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis><filename>Makefile.am</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
bin_PROGRAMS = hello
|
||||
hello_SOURCES = hello.c
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Source the Cross-Toolchain
|
||||
Environment Setup File:</emphasis>
|
||||
As described earlier in the manual, installing the
|
||||
cross-toolchain creates a cross-toolchain
|
||||
environment setup script in the directory that the SDK
|
||||
was installed.
|
||||
Before you can use the tools to develop your project,
|
||||
you must source this setup script.
|
||||
The script begins with the string "environment-setup"
|
||||
and contains the machine architecture, which is
|
||||
followed by the string "poky-linux".
|
||||
For this example, the command sources a script from the
|
||||
default SDK installation directory that uses the
|
||||
32-bit Intel x86 Architecture and the
|
||||
&DISTRO_NAME; Yocto Project release:
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Create the <filename>configure</filename> Script:</emphasis>
|
||||
Use the <filename>autoreconf</filename> command to
|
||||
generate the <filename>configure</filename> script.
|
||||
<literallayout class='monospaced'>
|
||||
$ autoreconf
|
||||
</literallayout>
|
||||
The <filename>autoreconf</filename> tool takes care
|
||||
of running the other Autotools such as
|
||||
<filename>aclocal</filename>,
|
||||
<filename>autoconf</filename>, and
|
||||
<filename>automake</filename>.
|
||||
<note>
|
||||
If you get errors from
|
||||
<filename>configure.ac</filename>, which
|
||||
<filename>autoreconf</filename> runs, that indicate
|
||||
missing files, you can use the "-i" option, which
|
||||
ensures missing auxiliary files are copied to the build
|
||||
host.
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Cross-Compile the Project:</emphasis>
|
||||
This command compiles the project using the
|
||||
cross-compiler.
|
||||
The
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
|
||||
environment variable provides the minimal arguments for
|
||||
GNU configure:
|
||||
<literallayout class='monospaced'>
|
||||
$ ./configure ${CONFIGURE_FLAGS}
|
||||
</literallayout>
|
||||
For an Autotools-based project, you can use the
|
||||
cross-toolchain by just passing the appropriate host
|
||||
option to <filename>configure.sh</filename>.
|
||||
The host option you use is derived from the name of the
|
||||
environment setup script found in the directory in which
|
||||
you installed the cross-toolchain.
|
||||
For example, the host option for an ARM-based target that
|
||||
uses the GNU EABI is
|
||||
<filename>armv5te-poky-linux-gnueabi</filename>.
|
||||
You will notice that the name of the script is
|
||||
<filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
|
||||
Thus, the following command works to update your project
|
||||
and rebuild it using the appropriate cross-toolchain tools:
|
||||
<literallayout class='monospaced'>
|
||||
$ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Make and Install the Project:</emphasis>
|
||||
These two commands generate and install the project
|
||||
into the destination directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ make
|
||||
$ make install DESTDIR=./tmp
|
||||
</literallayout>
|
||||
<note>
|
||||
To learn about environment variables established
|
||||
when you run the cross-toolchain environment setup
|
||||
script and how they are used or overridden when
|
||||
the Makefile, see the
|
||||
"<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
|
||||
section.
|
||||
</note>
|
||||
This next command is a simple way to verify the
|
||||
installation of your project.
|
||||
Running the command prints the architecture on which
|
||||
the binary file can run.
|
||||
This architecture should be the same architecture that
|
||||
the installed cross-toolchain supports.
|
||||
<literallayout class='monospaced'>
|
||||
$ file ./tmp/usr/local/bin/hello
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Execute Your Project:</emphasis>
|
||||
To execute the project, you would need to run it on your
|
||||
target hardware.
|
||||
If your target hardware happens to be your build host,
|
||||
you could run the project as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ ./tmp/usr/local/bin/hello
|
||||
</literallayout>
|
||||
As expected, the project displays the "Hello World!"
|
||||
message.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='makefile-based-projects'>
|
||||
<title>Makefile-Based Projects</title>
|
||||
|
||||
<para>
|
||||
Simple Makefile-based projects use and interact with the
|
||||
cross-toolchain environment variables established when you run
|
||||
the cross-toolchain environment setup script.
|
||||
The environment variables are subject to general
|
||||
<filename>make</filename> rules.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section presents a simple Makefile development flow and
|
||||
provides an example that lets you see how you can use
|
||||
cross-toolchain environment variables and Makefile variables
|
||||
during development.
|
||||
<imagedata fileref="figures/sdk-makefile-flow.png" width="6in" height="7in" align="center" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The main point of this section is to explain the following three
|
||||
cases regarding variable behavior:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Case 1 - No Variables Set in the
|
||||
<filename>Makefile</filename> Map to Equivalent
|
||||
Environment Variables Set in the SDK Setup Script:</emphasis>
|
||||
Because matching variables are not specifically set in the
|
||||
<filename>Makefile</filename>, the variables retain their
|
||||
values based on the environment setup script.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Case 2 - Variables Are Set in the Makefile that
|
||||
Map to Equivalent Environment Variables from the SDK
|
||||
Setup Script:</emphasis>
|
||||
Specifically setting matching variables in the
|
||||
<filename>Makefile</filename> during the build results in
|
||||
the environment settings of the variables being
|
||||
overwritten.
|
||||
In this case, the variables you set in the
|
||||
<filename>Makefile</filename> are used.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Case 3 - Variables Are Set Using the Command Line
|
||||
that Map to Equivalent Environment Variables from the
|
||||
SDK Setup Script:</emphasis>
|
||||
Executing the <filename>Makefile</filename> from the
|
||||
command line results in the environment variables being
|
||||
overwritten.
|
||||
In this case, the command-line content is used.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
<note>
|
||||
Regardless of how you set your variables, if you use
|
||||
the "-e" option with <filename>make</filename>, the
|
||||
variables from the SDK setup script take precedence:
|
||||
<literallayout class='monospaced'>
|
||||
$ make -e <replaceable>target</replaceable>
|
||||
</literallayout>
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this section presents a simple Makefile example
|
||||
that demonstrates these variable behaviors.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In a new shell environment variables are not established for the
|
||||
SDK until you run the setup script.
|
||||
For example, the following commands show a null value for the
|
||||
compiler variable (i.e.
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>).
|
||||
<literallayout class='monospaced'>
|
||||
$ echo ${CC}
|
||||
|
||||
$
|
||||
</literallayout>
|
||||
Running the SDK setup script for a 64-bit build host and an
|
||||
i586-tuned target architecture for a
|
||||
<filename>core-image-sato</filename> image using the current
|
||||
&DISTRO; Yocto Project release and then echoing that variable
|
||||
shows the value established through the script:
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
$ echo ${CC}
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To illustrate variable use, work through this simple "Hello World!"
|
||||
example:
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Create a Working Directory and Populate It:</emphasis>
|
||||
Create a clean directory for your project and then make
|
||||
that directory your working location.
|
||||
<literallayout class='monospaced'>
|
||||
$ mkdir $HOME/helloworld
|
||||
$ cd $HOME/helloworld
|
||||
</literallayout>
|
||||
After setting up the directory, populate it with files
|
||||
needed for the flow.
|
||||
You need a <filename>main.c</filename> file from which you
|
||||
call your function, a <filename>module.h</filename> file
|
||||
to contain headers, and a <filename>module.c</filename>
|
||||
that defines your function.
|
||||
</para>
|
||||
|
||||
<para>Create the three files as follows:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis><filename>main.c</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
#include "module.h"
|
||||
void sample_func();
|
||||
int main()
|
||||
{
|
||||
sample_func();
|
||||
return 0;
|
||||
}
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis><filename>module.h</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
#include <stdio.h>
|
||||
void sample_func();
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis><filename>module.c</filename>:</emphasis>
|
||||
<literallayout class='monospaced'>
|
||||
#include "module.h"
|
||||
void sample_func()
|
||||
{
|
||||
printf("Hello World!");
|
||||
printf("\n");
|
||||
}
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Source the Cross-Toolchain Environment Setup File:</emphasis>
|
||||
As described earlier in the manual, installing the
|
||||
cross-toolchain creates a cross-toolchain environment setup
|
||||
script in the directory that the SDK was installed.
|
||||
Before you can use the tools to develop your project,
|
||||
you must source this setup script.
|
||||
The script begins with the string "environment-setup"
|
||||
and contains the machine architecture, which is
|
||||
followed by the string "poky-linux".
|
||||
For this example, the command sources a script from the
|
||||
default SDK installation directory that uses the
|
||||
32-bit Intel x86 Architecture and the
|
||||
&DISTRO_NAME; Yocto Project release:
|
||||
<literallayout class='monospaced'>
|
||||
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Create the <filename>Makefile</filename>:</emphasis>
|
||||
For this example, the Makefile contains two lines that
|
||||
can be used to set the <filename>CC</filename> variable.
|
||||
One line is identical to the value that is set when you
|
||||
run the SDK environment setup script, and the other line
|
||||
sets <filename>CC</filename> to "gcc", the default GNU
|
||||
compiler on the build host:
|
||||
<literallayout class='monospaced'>
|
||||
# CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
|
||||
# CC="gcc"
|
||||
all: main.o module.o
|
||||
${CC} main.o module.o -o target_bin
|
||||
main.o: main.c module.h
|
||||
${CC} -I . -c main.c
|
||||
module.o: module.c module.h
|
||||
${CC} -I . -c module.c
|
||||
clean:
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Make the Project:</emphasis>
|
||||
Use the <filename>make</filename> command to create the
|
||||
binary output file.
|
||||
Because variables are commented out in the Makefile,
|
||||
the value used for <filename>CC</filename> is the value
|
||||
set when the SDK environment setup file was run:
|
||||
<literallayout class='monospaced'>
|
||||
$ make
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
|
||||
</literallayout>
|
||||
From the results of the previous command, you can see that
|
||||
the compiler used was the compiler established through
|
||||
the <filename>CC</filename> variable defined in the
|
||||
setup script.</para>
|
||||
|
||||
<para>You can override the <filename>CC</filename>
|
||||
environment variable with the same variable as set from
|
||||
the Makefile by uncommenting the line in the Makefile
|
||||
and running <filename>make</filename> again.
|
||||
<literallayout class='monospaced'>
|
||||
$ make clean
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
#
|
||||
# Edit the Makefile by uncommenting the line that sets CC to "gcc"
|
||||
#
|
||||
$ make
|
||||
gcc -I . -c main.c
|
||||
gcc -I . -c module.c
|
||||
gcc main.o module.o -o target_bin
|
||||
</literallayout>
|
||||
As shown in the previous example, the cross-toolchain
|
||||
compiler is not used.
|
||||
Rather, the default compiler is used.</para>
|
||||
|
||||
<para>This next case shows how to override a variable
|
||||
by providing the variable as part of the command line.
|
||||
Go into the Makefile and re-insert the comment character
|
||||
so that running <filename>make</filename> uses
|
||||
the established SDK compiler.
|
||||
However, when you run <filename>make</filename>, use a
|
||||
command-line argument to set <filename>CC</filename>
|
||||
to "gcc":
|
||||
<literallayout class='monospaced'>
|
||||
$ make clean
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
#
|
||||
# Edit the Makefile to comment out the line setting CC to "gcc"
|
||||
#
|
||||
$ make
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
|
||||
$ make clean
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
$ make CC="gcc"
|
||||
gcc -I . -c main.c
|
||||
gcc -I . -c module.c
|
||||
gcc main.o module.o -o target_bin
|
||||
</literallayout>
|
||||
In the previous case, the command-line argument overrides
|
||||
the SDK environment variable.</para>
|
||||
|
||||
<para>In this last case, edit Makefile again to use the
|
||||
"gcc" compiler but then use the "-e" option on the
|
||||
<filename>make</filename> command line:
|
||||
<literallayout class='monospaced'>
|
||||
$ make clean
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
#
|
||||
# Edit the Makefile to use "gcc"
|
||||
#
|
||||
$ make
|
||||
gcc -I . -c main.c
|
||||
gcc -I . -c module.c
|
||||
gcc main.o module.o -o target_bin
|
||||
$ make clean
|
||||
rm -rf *.o
|
||||
rm target_bin
|
||||
$ make -e
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
|
||||
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
|
||||
</literallayout>
|
||||
In the previous case, the "-e" option forces
|
||||
<filename>make</filename> to use the SDK environment
|
||||
variables regardless of the values in the Makefile.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Execute Your Project:</emphasis>
|
||||
To execute the project (i.e.
|
||||
<filename>target_bin</filename>), use the following
|
||||
command:
|
||||
<literallayout class='monospaced'>
|
||||
$ ./target_bin
|
||||
Hello World!
|
||||
</literallayout>
|
||||
<note>
|
||||
If you used the cross-toolchain compiler to build
|
||||
<filename>target_bin</filename> and your build host
|
||||
differs in architecture from that of the target
|
||||
machine, you need to run your project on the target
|
||||
device.
|
||||
</note>
|
||||
As expected, the project displays the "Hello World!"
|
||||
message.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
||||
Reference in New Issue
Block a user