Revert "Revert "poky: subtree update:b23aa6b753..ad30a6d470""
This reverts commit 4873add6e11c1bd421c83cd08df589f1184aa673.
A fix has been put up for openbmc/openbmc#3720 so we can bring
this back now
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: If59020a5b502f70aa7149fbef4ad2f50824d1ce6
diff --git a/poky/documentation/sdk-manual/history.rst b/poky/documentation/sdk-manual/history.rst
index af027c9..8c10f6d 100644
--- a/poky/documentation/sdk-manual/history.rst
+++ b/poky/documentation/sdk-manual/history.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
***********************
Manual Revision History
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst b/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
index f6f2b66..90b6345 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
+++ b/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
****************************
Customizing the Standard SDK
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.xml b/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.xml
deleted file mode 100644
index 3a6b4c8..0000000
--- a/poky/documentation/sdk-manual/sdk-appendix-customizing-standard.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing.rst b/poky/documentation/sdk-manual/sdk-appendix-customizing.rst
index 7743e3c..5a33f63 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/sdk-appendix-customizing.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
******************************
Customizing the Extensible SDK
diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml b/poky/documentation/sdk-manual/sdk-appendix-customizing.xml
deleted file mode 100644
index 08054f8..0000000
--- a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst b/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
index 97ab916..a51c22e 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
*****************
Obtaining the SDK
diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml
deleted file mode 100644
index de7f75e..0000000
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-extensible.rst b/poky/documentation/sdk-manual/sdk-extensible.rst
index 0f92ac9..5ff75ad 100644
--- a/poky/documentation/sdk-manual/sdk-extensible.rst
+++ b/poky/documentation/sdk-manual/sdk-extensible.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
************************
Using the Extensible SDK
diff --git a/poky/documentation/sdk-manual/sdk-extensible.xml b/poky/documentation/sdk-manual/sdk-extensible.xml
deleted file mode 100644
index a73a07a..0000000
--- a/poky/documentation/sdk-manual/sdk-extensible.xml
+++ /dev/null
@@ -1,1847 +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-extensible'>
-
- <title>Using the Extensible SDK</title>
-
- <para>
- This chapter describes the extensible SDK and how to install it.
- Information covers the pieces of the SDK, how to install it, and
- presents a look at using the <filename>devtool</filename>
- functionality.
- The extensible SDK makes it easy to add new applications and libraries
- to an image, modify the source for an existing component, test
- changes on the target hardware, and ease integration into the rest of
- the
- <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
- <note>
- For a side-by-side comparison of main features supported for an
- extensible SDK as compared to a standard SDK, see the
- "<link linkend='sdk-manual-intro'>Introduction</link>"
- section.
- </note>
- </para>
-
- <para>
- In addition to the functionality available through
- <filename>devtool</filename>, you can alternatively make use of the
- toolchain directly, for example from Makefile and Autotools.
- See the
- "<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>"
- chapter for more information.
- </para>
-
- <section id='sdk-extensible-sdk-intro'>
- <title>Why use the Extensible SDK and What is in It?</title>
-
- <para>
- The extensible SDK provides a cross-development toolchain and
- libraries tailored to the contents of a specific image.
- You would use the Extensible SDK if you want a toolchain experience
- supplemented with the powerful set of <filename>devtool</filename>
- commands tailored for the Yocto Project environment.
- </para>
-
- <para>
- The installed extensible SDK consists of several files and
- directories.
- Basically, it contains an SDK environment setup script, some
- configuration files, an internal build system, and the
- <filename>devtool</filename> functionality.
- </para>
- </section>
-
- <section id='sdk-installing-the-extensible-sdk'>
- <title>Installing the Extensible 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, the internal build system, <filename>devtool</filename>,
- 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.
- An extensible SDK has the string "-ext" as part of the name.
- Following is the general form:
- <literallayout class='monospaced'>
- poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-ext-<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-sato or core-image-minimal
-
- <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-ext-&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-minimal-core2-64-toolchain-ext-2.5.sh
- Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5
- ==========================================================================
- Enter target directory for SDK (default: ~/poky_sdk):
- You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed [Y/n]? Y
- Extracting SDK..............done
- Setting it up...
- Extracting buildtools...
- Preparing build system...
- Parsing recipes: 100% |##################################################################| Time: 0:00:52
- Initialising tasks: 100% |###############################################################| Time: 0:00:00
- Checking sstate mirror object availability: 100% |#######################################| Time: 0:00:00
- Loading cache: 100% |####################################################################| Time: 0:00:00
- Initialising tasks: 100% |###############################################################| Time: 0:00:00
- 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.
- $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
-
- </literallayout>
- </para>
- </section>
-
- <section id='sdk-running-the-extensible-sdk-environment-setup-script'>
- <title>Running the Extensible 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>poky_sdk</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'>
- $ cd /home/scottrif/poky_sdk
- $ source environment-setup-core2-64-poky-linux
- SDK environment now set up; additionally you may now run devtool to perform development tasks.
- Run devtool --help for further details.
- </literallayout>
- Running the setup script defines many environment variables needed
- in order to use the SDK (e.g. <filename>PATH</filename>,
- <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>,
- <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>,
- and so forth).
- If you want to see all the environment variables the script
- exports, examine the installation file itself.
- </para>
- </section>
-
- <section id='using-devtool-in-your-sdk-workflow'>
- <title>Using <filename>devtool</filename> in Your SDK Workflow</title>
-
- <para>
- The cornerstone of the extensible SDK is a command-line tool
- called <filename>devtool</filename>.
- This tool provides a number of features that help
- you build, test and package software within the extensible SDK, and
- optionally integrate it into an image built by the OpenEmbedded
- build system.
- <note><title>Tip</title>
- The use of <filename>devtool</filename> is not limited to
- the extensible SDK.
- You can use <filename>devtool</filename> to help you easily
- develop any project whose build output must be part of an
- image built using the build system.
- </note>
- </para>
-
- <para>
- The <filename>devtool</filename> command line is organized
- similarly to
- <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink> in that it
- has a number of sub-commands for each function.
- You can run <filename>devtool --help</filename> to see all the
- commands.
- <note>
- See the
- "<ulink url='&YOCTO_DOCS_REF_URL;#ref-devtool-reference'><filename>devtool</filename> Quick Reference</ulink>"
- in the Yocto Project Reference Manual for a
- <filename>devtool</filename> quick reference.
- </note>
- </para>
-
- <para>
- Three <filename>devtool</filename> subcommands exist that provide
- entry-points into development:
- <itemizedlist>
- <listitem><para>
- <emphasis><filename>devtool add</filename></emphasis>:
- Assists in adding new software to be built.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>devtool modify</filename></emphasis>:
- Sets up an environment to enable you to modify the source of
- an existing component.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>devtool upgrade</filename></emphasis>:
- Updates an existing recipe so that you can build it for
- an updated set of source files.
- </para></listitem>
- </itemizedlist>
- As with the build system, "recipes" represent software packages
- within <filename>devtool</filename>.
- When you use <filename>devtool add</filename>, a recipe is
- automatically created.
- When you use <filename>devtool modify</filename>, the specified
- existing recipe is used in order to determine where to get the
- source code and how to patch it.
- In both cases, an environment is set up so that when you build the
- recipe a source tree that is under your control is used in order to
- allow you to make changes to the source as desired.
- By default, new recipes and the source go into a "workspace"
- directory under the SDK.
- </para>
-
- <para>
- The remainder of this section presents the
- <filename>devtool add</filename>,
- <filename>devtool modify</filename>, and
- <filename>devtool upgrade</filename> workflows.
- </para>
-
- <section id='sdk-use-devtool-to-add-an-application'>
- <title>Use <filename>devtool add</filename> to Add an Application</title>
-
- <para>
- The <filename>devtool add</filename> command generates
- a new recipe based on existing source code.
- This command takes advantage of the
- <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>
- layer that many <filename>devtool</filename> commands
- use.
- The command is flexible enough to allow you to extract source
- code into both the workspace or a separate local Git repository
- and to use existing code that does not need to be extracted.
- </para>
-
- <para>
- Depending on your particular scenario, the arguments and options
- you use with <filename>devtool add</filename> form different
- combinations.
- The following diagram shows common development flows
- you would use with the <filename>devtool add</filename>
- command:
- </para>
-
- <para>
- <imagedata fileref="figures/sdk-devtool-add-flow.png" align="center" />
- </para>
-
- <para>
- <orderedlist>
- <listitem><para><emphasis>Generating the New Recipe</emphasis>:
- The top part of the flow shows three scenarios by which
- you could use <filename>devtool add</filename> to
- generate a recipe based on existing source code.</para>
-
- <para>In a shared development environment, it is
- typical for other developers to be responsible for
- various areas of source code.
- As a developer, you are probably interested in using
- that source code as part of your development within
- the Yocto Project.
- All you need is access to the code, a recipe, and a
- controlled area in which to do your work.</para>
-
- <para>Within the diagram, three possible scenarios
- feed into the <filename>devtool add</filename> workflow:
- <itemizedlist>
- <listitem><para>
- <emphasis>Left</emphasis>:
- The left scenario in the figure represents a
- common situation where the source code does not
- exist locally and needs to be extracted.
- In this situation, the source code is extracted
- to the default workspace - you do not
- want the files in some specific location
- outside of the workspace.
- Thus, everything you need will be located in
- the workspace:
- <literallayout class='monospaced'>
- $ devtool add <replaceable>recipe fetchuri</replaceable>
- </literallayout>
- With this command, <filename>devtool</filename>
- extracts the upstream source files into a local
- Git repository within the
- <filename>sources</filename> folder.
- The command then creates a recipe named
- <replaceable>recipe</replaceable> and a
- corresponding append file in the workspace.
- If you do not provide
- <replaceable>recipe</replaceable>, the command
- makes an attempt to determine the recipe name.
- </para></listitem>
- <listitem><para>
- <emphasis>Middle</emphasis>:
- The middle scenario in the figure also
- represents a situation where the source code
- does not exist locally.
- In this case, the code is again upstream
- and needs to be extracted to some
- local area - this time outside of the default
- workspace.
- <note>
- If required, <filename>devtool</filename>
- always creates
- a Git repository locally during the
- extraction.
- </note>
- Furthermore, the first positional argument
- <replaceable>srctree</replaceable> in this
- case identifies where the
- <filename>devtool add</filename> command
- will locate the extracted code outside of the
- workspace.
- You need to specify an empty directory:
- <literallayout class='monospaced'>
- $ devtool add <replaceable>recipe srctree fetchuri</replaceable>
- </literallayout>
- In summary, the source code is pulled from
- <replaceable>fetchuri</replaceable> and
- extracted into the location defined by
- <replaceable>srctree</replaceable> as a local
- Git repository.</para>
-
- <para>Within workspace,
- <filename>devtool</filename> creates a
- recipe named <replaceable>recipe</replaceable>
- along with an associated append file.
- </para></listitem>
- <listitem><para>
- <emphasis>Right</emphasis>:
- The right scenario in the figure represents a
- situation where the
- <replaceable>srctree</replaceable> has been
- previously prepared outside of the
- <filename>devtool</filename> workspace.</para>
-
- <para>The following command provides a new
- recipe name and identifies the existing source
- tree location:
- <literallayout class='monospaced'>
- $ devtool add <replaceable>recipe srctree</replaceable>
- </literallayout>
- The command examines the source code and
- creates a recipe named
- <replaceable>recipe</replaceable> for the code
- and places the recipe into the workspace.
- </para>
-
- <para>Because the extracted source code already
- exists, <filename>devtool</filename> does not
- try to relocate the source code into the
- workspace - only the new recipe is placed
- in the workspace.</para>
-
- <para>Aside from a recipe folder, the command
- also creates an associated append folder and
- places an initial
- <filename>*.bbappend</filename> file within.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <emphasis>Edit the Recipe</emphasis>:
- You can use <filename>devtool edit-recipe</filename>
- to open up the editor as defined by the
- <filename>$EDITOR</filename> environment variable
- and modify the file:
- <literallayout class='monospaced'>
- $ devtool edit-recipe <replaceable>recipe</replaceable>
- </literallayout>
- From within the editor, you can make modifications to
- the recipe that take affect when you build it later.
- </para></listitem>
- <listitem><para>
- <emphasis>Build the Recipe or Rebuild the Image</emphasis>:
- The next step you take depends on what you are going
- to do with the new code.</para>
-
- <para>If you need to eventually move the build output
- to the target hardware, use the following
- <filename>devtool</filename> command:
- <literallayout class='monospaced'>
- $ devtool build <replaceable>recipe</replaceable>
- </literallayout></para>
-
- <para>On the other hand, if you want an image to
- contain the recipe's packages from the workspace
- for immediate deployment onto a device (e.g. for
- testing purposes), you can use
- the <filename>devtool build-image</filename> command:
- <literallayout class='monospaced'>
- $ devtool build-image <replaceable>image</replaceable>
- </literallayout>
- </para></listitem>
- <listitem><para>
- <emphasis>Deploy the Build Output</emphasis>:
- When you use the <filename>devtool build</filename>
- command to build out your recipe, you probably want to
- see if the resulting build output works as expected
- on the target hardware.
- <note>
- This step assumes you have a previously built
- image that is already either running in QEMU or
- is running on actual hardware.
- Also, it is assumed that for deployment of the
- image to the target, SSH is installed in the image
- and, if the image is running on real hardware,
- you have network access to and from your
- development machine.
- </note>
- You can deploy your build output to that target
- hardware by using the
- <filename>devtool deploy-target</filename> command:
- <literallayout class='monospaced'>
- $ devtool deploy-target <replaceable>recipe target</replaceable>
- </literallayout>
- The <replaceable>target</replaceable> is a live target
- machine running as an SSH server.</para>
-
- <para>You can, of course, also deploy the image you
- build to actual hardware by using the
- <filename>devtool build-image</filename> command.
- However, <filename>devtool</filename> does not provide
- a specific command that allows you to deploy the
- image to actual hardware.
- </para></listitem>
- <listitem><para>
- <emphasis>Finish Your Work With the Recipe</emphasis>:
- The <filename>devtool finish</filename> command creates
- any patches corresponding to commits in the local
- Git repository, moves the new recipe to a more permanent
- layer, and then resets the recipe so that the recipe is
- built normally rather than from the workspace.
- <literallayout class='monospaced'>
- $ devtool finish <replaceable>recipe layer</replaceable>
- </literallayout>
- <note>
- Any changes you want to turn into patches must be
- committed to the Git repository in the source tree.
- </note></para>
-
- <para>As mentioned, the
- <filename>devtool finish</filename> command moves the
- final recipe to its permanent layer.
- </para>
-
- <para>As a final process of the
- <filename>devtool finish</filename> command, the state
- of the standard layers and the upstream source is
- restored so that you can build the recipe from those
- areas rather than the workspace.
- <note>
- You can use the <filename>devtool reset</filename>
- command to put things back should you decide you
- do not want to proceed with your work.
- If you do use this command, realize that the source
- tree is preserved.
- </note>
- </para></listitem>
- </orderedlist>
- </para>
- </section>
-
- <section id='sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component'>
- <title>Use <filename>devtool modify</filename> to Modify the Source of an Existing Component</title>
-
- <para>
- The <filename>devtool modify</filename> command prepares the
- way to work on existing code that already has a local recipe in
- place that is used to build the software.
- The command is flexible enough to allow you to extract code
- from an upstream source, specify the existing recipe, and
- keep track of and gather any patch files from other developers
- that are associated with the code.
- </para>
-
- <para>
- Depending on your particular scenario, the arguments and options
- you use with <filename>devtool modify</filename> form different
- combinations.
- The following diagram shows common development flows for the
- <filename>devtool modify</filename> command:
- </para>
-
- <para>
- <imagedata fileref="figures/sdk-devtool-modify-flow.png" align="center" />
- </para>
-
- <para>
- <orderedlist>
- <listitem><para>
- <emphasis>Preparing to Modify the Code</emphasis>:
- The top part of the flow shows three scenarios by which
- you could use <filename>devtool modify</filename> to
- prepare to work on source files.
- Each scenario assumes the following:
- <itemizedlist>
- <listitem><para>
- The recipe exists locally in a layer external
- to the <filename>devtool</filename> workspace.
- </para></listitem>
- <listitem><para>
- The source files exist either upstream in an
- un-extracted state or locally in a previously
- extracted state.
- </para></listitem>
- </itemizedlist>
- The typical situation is where another developer has
- created a layer for use with the Yocto Project and
- their recipe already resides in that layer.
- Furthermore, their source code is readily available
- either upstream or locally.
- <itemizedlist>
- <listitem><para>
- <emphasis>Left</emphasis>:
- The left scenario in the figure represents a
- common situation where the source code does
- not exist locally and it needs to be extracted
- from an upstream source.
- In this situation, the source is extracted
- into the default <filename>devtool</filename>
- workspace location.
- The recipe, in this scenario, is in its own
- layer outside the workspace
- (i.e.
- <filename>meta-</filename><replaceable>layername</replaceable>).
- </para>
-
- <para>The following command identifies the
- recipe and, by default, extracts the source
- files:
- <literallayout class='monospaced'>
- $ devtool modify <replaceable>recipe</replaceable>
- </literallayout>
- Once <filename>devtool</filename>locates the
- recipe, <filename>devtool</filename> uses the
- recipe's
- <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
- statements to locate the source code and any
- local patch files from other developers.</para>
-
- <para>With this scenario, no
- <replaceable>srctree</replaceable> argument
- exists.
- Consequently, the default behavior of the
- <filename>devtool modify</filename> command is
- to extract the source files pointed to by the
- <filename>SRC_URI</filename> statements into a
- local Git structure.
- Furthermore, the location for the extracted
- source is the default area within the
- <filename>devtool</filename> workspace.
- The result is that the command sets up both
- the source code and an append file within the
- workspace while the recipe remains in its
- original location.</para>
-
- <para>Additionally, if you have any non-patch
- local files (i.e. files referred to with
- <filename>file://</filename> entries in
- <filename>SRC_URI</filename> statement excluding
- <filename>*.patch/</filename> or
- <filename>*.diff</filename>), these files are
- copied to an
- <filename>oe-local-files</filename> folder
- under the newly created source tree.
- Copying the files here gives you a convenient
- area from which you can modify the files.
- Any changes or additions you make to those
- files are incorporated into the build the next
- time you build the software just as are other
- changes you might have made to the source.
- </para></listitem>
- <listitem><para>
- <emphasis>Middle</emphasis>:
- The middle scenario in the figure represents a
- situation where the source code also does not
- exist locally.
- In this case, the code is again upstream
- and needs to be extracted to some
- local area as a Git repository.
- The recipe, in this scenario, is again local
- and in its own layer outside the workspace.
- </para>
-
- <para>The following command tells
- <filename>devtool</filename> the recipe with
- which to work and, in this case, identifies a
- local area for the extracted source files that
- exists outside of the default
- <filename>devtool</filename> workspace:
- <literallayout class='monospaced'>
- $ devtool modify <replaceable>recipe srctree</replaceable>
- </literallayout>
- <note>
- You cannot provide a URL for
- <replaceable>srctree</replaceable> using
- the <filename>devtool</filename> command.
- </note>
- As with all extractions, the command uses
- the recipe's <filename>SRC_URI</filename>
- statements to locate the source files and any
- associated patch files.
- Non-patch files are copied to an
- <filename>oe-local-files</filename> folder
- under the newly created source tree.</para>
-
- <para>Once the files are located, the command
- by default extracts them into
- <replaceable>srctree</replaceable>.</para>
-
- <para>Within workspace,
- <filename>devtool</filename> creates an append
- file for the recipe.
- The recipe remains in its original location but
- the source files are extracted to the location
- you provide with
- <replaceable>srctree</replaceable>.
- </para></listitem>
- <listitem><para>
- <emphasis>Right</emphasis>:
- The right scenario in the figure represents a
- situation where the source tree
- (<replaceable>srctree</replaceable>) already
- exists locally as a previously extracted Git
- structure outside of the
- <filename>devtool</filename> workspace.
- In this example, the recipe also exists
- elsewhere locally in its own layer.
- </para>
-
- <para>The following command tells
- <filename>devtool</filename> the recipe
- with which to work, uses the "-n" option to
- indicate source does not need to be extracted,
- and uses <replaceable>srctree</replaceable> to
- point to the previously extracted source files:
- <literallayout class='monospaced'>
- $ devtool modify -n <replaceable>recipe srctree</replaceable>
- </literallayout>
- </para>
-
- <para>If an <filename>oe-local-files</filename>
- subdirectory happens to exist and it contains
- non-patch files, the files are used.
- However, if the subdirectory does not exist and
- you run the <filename>devtool finish</filename>
- command, any non-patch files that might exist
- next to the recipe are removed because it
- appears to <filename>devtool</filename> that
- you have deleted those files.</para>
-
- <para>Once the
- <filename>devtool modify</filename> command
- finishes, it creates only an append file for
- the recipe in the <filename>devtool</filename>
- workspace.
- The recipe and the source code remain in their
- original locations.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <emphasis>Edit the Source</emphasis>:
- Once you have used the
- <filename>devtool modify</filename> command, you are
- free to make changes to the source files.
- You can use any editor you like to make and save
- your source code modifications.
- </para></listitem>
- <listitem><para>
- <emphasis>Build the Recipe or Rebuild the Image</emphasis>:
- The next step you take depends on what you are going
- to do with the new code.</para>
-
- <para>If you need to eventually move the build output
- to the target hardware, use the following
- <filename>devtool</filename> command:
- <literallayout class='monospaced'>
- $ devtool build <replaceable>recipe</replaceable>
- </literallayout></para>
-
- <para>On the other hand, if you want an image to
- contain the recipe's packages from the workspace
- for immediate deployment onto a device (e.g. for
- testing purposes), you can use
- the <filename>devtool build-image</filename> command:
- <literallayout class='monospaced'>
- $ devtool build-image <replaceable>image</replaceable>
- </literallayout>
- </para></listitem>
- <listitem><para>
- <emphasis>Deploy the Build Output</emphasis>:
- When you use the <filename>devtool build</filename>
- command to build out your recipe, you probably want to
- see if the resulting build output works as expected
- on target hardware.
- <note>
- This step assumes you have a previously built
- image that is already either running in QEMU or
- running on actual hardware.
- Also, it is assumed that for deployment of the image
- to the target, SSH is installed in the image and if
- the image is running on real hardware that you have
- network access to and from your development machine.
- </note>
- You can deploy your build output to that target
- hardware by using the
- <filename>devtool deploy-target</filename> command:
- <literallayout class='monospaced'>
- $ devtool deploy-target <replaceable>recipe target</replaceable>
- </literallayout>
- The <replaceable>target</replaceable> is a live target
- machine running as an SSH server.</para>
-
- <para>You can, of course, use other methods to deploy
- the image you built using the
- <filename>devtool build-image</filename> command to
- actual hardware.
- <filename>devtool</filename> does not provide
- a specific command to deploy the image to actual
- hardware.
- </para></listitem>
- <listitem><para>
- <emphasis>Finish Your Work With the Recipe</emphasis>:
- The <filename>devtool finish</filename> command creates
- any patches corresponding to commits in the local
- Git repository, updates the recipe to point to them
- (or creates a <filename>.bbappend</filename> file to do
- so, depending on the specified destination layer), and
- then resets the recipe so that the recipe is built
- normally rather than from the workspace.
- <literallayout class='monospaced'>
- $ devtool finish <replaceable>recipe layer</replaceable>
- </literallayout>
- <note>
- Any changes you want to turn into patches must be
- staged and committed within the local Git
- repository before you use the
- <filename>devtool finish</filename> command.
- </note></para>
-
- <para>Because there is no need to move the recipe,
- <filename>devtool finish</filename> either updates the
- original recipe in the original layer or the command
- creates a <filename>.bbappend</filename> file in a
- different layer as provided by
- <replaceable>layer</replaceable>.
- Any work you did in the
- <filename>oe-local-files</filename> directory is
- preserved in the original files next to the recipe
- during the <filename>devtool finish</filename>
- command.</para>
-
- <para>As a final process of the
- <filename>devtool finish</filename> command, the state
- of the standard layers and the upstream source is
- restored so that you can build the recipe from those
- areas rather than from the workspace.
- <note>
- You can use the <filename>devtool reset</filename>
- command to put things back should you decide you
- do not want to proceed with your work.
- If you do use this command, realize that the source
- tree is preserved.
- </note>
- </para></listitem>
- </orderedlist>
- </para>
- </section>
-
- <section id='sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software'>
- <title>Use <filename>devtool upgrade</filename> to Create a Version of the Recipe that Supports a Newer Version of the Software</title>
-
- <para>
- The <filename>devtool upgrade</filename> command upgrades
- an existing recipe to that of a more up-to-date version
- found upstream.
- Throughout the life of software, recipes continually undergo
- version upgrades by their upstream publishers.
- You can use the <filename>devtool upgrade</filename>
- workflow to make sure your recipes you are using for builds
- are up-to-date with their upstream counterparts.
- <note>
- Several methods exist by which you can upgrade recipes -
- <filename>devtool upgrade</filename> happens to be one.
- You can read about all the methods by which you can
- upgrade recipes in the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#gs-upgrading-recipes'>Upgrading Recipes</ulink>"
- section of the Yocto Project Development Tasks Manual.
- </note>
- </para>
-
- <para>
- The <filename>devtool upgrade</filename> command is flexible
- enough to allow you to specify source code revision and
- versioning schemes, extract code into or out of the
- <filename>devtool</filename>
- <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>,
- and work with any source file forms that the
- <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink>
- support.
- </para>
-
- <para>
- The following diagram shows the common development flow
- used with the <filename>devtool upgrade</filename> command:
- </para>
-
- <para>
- <imagedata fileref="figures/sdk-devtool-upgrade-flow.png" align="center" />
- </para>
-
- <para>
- <orderedlist>
- <listitem><para>
- <emphasis>Initiate the Upgrade</emphasis>:
- The top part of the flow shows the typical scenario by
- which you use the <filename>devtool upgrade</filename>
- command.
- The following conditions exist:
- <itemizedlist>
- <listitem><para>
- The recipe exists in a local layer external
- to the <filename>devtool</filename> workspace.
- </para></listitem>
- <listitem><para>
- The source files for the new release
- exist in the same location pointed to by
- <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
- in the recipe (e.g. a tarball with the new
- version number in the name, or as a different
- revision in the upstream Git repository).
- </para></listitem>
- </itemizedlist>
- A common situation is where third-party software has
- undergone a revision so that it has been upgraded.
- The recipe you have access to is likely in your own
- layer.
- Thus, you need to upgrade the recipe to use the
- newer version of the software:
- <literallayout class='monospaced'>
- $ devtool upgrade -V <replaceable>version recipe</replaceable>
- </literallayout>
- By default, the <filename>devtool upgrade</filename>
- command extracts source code into the
- <filename>sources</filename> directory in the
- <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>.
- If you want the code extracted to any other location,
- you need to provide the
- <replaceable>srctree</replaceable> positional argument
- with the command as follows:
- <literallayout class='monospaced'>
- $ devtool upgrade -V <replaceable>version recipe srctree</replaceable>
- </literallayout>
- <note>
- In this example, the "-V" option specifies the new
- version.
- If you don't use "-V", the command upgrades the
- recipe to the latest version.
- </note>
- If the source files pointed to by the
- <filename>SRC_URI</filename> statement in the recipe
- are in a Git repository, you must provide the "-S"
- option and specify a revision for the software.</para>
-
- <para>Once <filename>devtool</filename> locates the
- recipe, it uses the <filename>SRC_URI</filename>
- variable to locate the source code and any local patch
- files from other developers.
- The result is that the command sets up the source
- code, the new version of the recipe, and an append file
- all within the workspace.</para>
-
- <para>Additionally, if you have any non-patch
- local files (i.e. files referred to with
- <filename>file://</filename> entries in
- <filename>SRC_URI</filename> statement excluding
- <filename>*.patch/</filename> or
- <filename>*.diff</filename>), these files are
- copied to an
- <filename>oe-local-files</filename> folder
- under the newly created source tree.
- Copying the files here gives you a convenient
- area from which you can modify the files.
- Any changes or additions you make to those
- files are incorporated into the build the next
- time you build the software just as are other
- changes you might have made to the source.
- </para></listitem>
- <listitem><para>
- <emphasis>Resolve any Conflicts created by the Upgrade</emphasis>:
- Conflicts could exist due to the software being
- upgraded to a new version.
- Conflicts occur if your recipe specifies some patch
- files in <filename>SRC_URI</filename> that conflict
- with changes made in the new version of the software.
- For such cases, you need to resolve the conflicts
- by editing the source and following the normal
- <filename>git rebase</filename> conflict resolution
- process.</para>
-
- <para>Before moving onto the next step, be sure to
- resolve any such conflicts created through use of a
- newer or different version of the software.
- </para></listitem>
- <listitem><para>
- <emphasis>Build the Recipe or Rebuild the Image</emphasis>:
- The next step you take depends on what you are going
- to do with the new code.</para>
-
- <para>If you need to eventually move the build output
- to the target hardware, use the following
- <filename>devtool</filename> command:
- <literallayout class='monospaced'>
- $ devtool build <replaceable>recipe</replaceable>
- </literallayout></para>
-
- <para>On the other hand, if you want an image to
- contain the recipe's packages from the workspace
- for immediate deployment onto a device (e.g. for
- testing purposes), you can use
- the <filename>devtool build-image</filename> command:
- <literallayout class='monospaced'>
- $ devtool build-image <replaceable>image</replaceable>
- </literallayout>
- </para></listitem>
- <listitem><para>
- <emphasis>Deploy the Build Output</emphasis>:
- When you use the <filename>devtool build</filename>
- command or <filename>bitbake</filename> to build
- your recipe, you probably want to see if the resulting
- build output works as expected on target hardware.
- <note>
- This step assumes you have a previously built
- image that is already either running in QEMU or
- running on actual hardware.
- Also, it is assumed that for deployment of the
- image to the target, SSH is installed in the image
- and if the image is running on real hardware that
- you have network access to and from your
- development machine.
- </note>
- You can deploy your build output to that target
- hardware by using the
- <filename>devtool deploy-target</filename> command:
- <literallayout class='monospaced'>
- $ devtool deploy-target <replaceable>recipe target</replaceable>
- </literallayout>
- The <replaceable>target</replaceable> is a live target
- machine running as an SSH server.</para>
-
- <para>You can, of course, also deploy the image you
- build using the
- <filename>devtool build-image</filename> command
- to actual hardware.
- However, <filename>devtool</filename> does not provide
- a specific command that allows you to do this.
- </para></listitem>
- <listitem><para>
- <emphasis>Finish Your Work With the Recipe</emphasis>:
- The <filename>devtool finish</filename> command creates
- any patches corresponding to commits in the local
- Git repository, moves the new recipe to a more
- permanent layer, and then resets the recipe so that
- the recipe is built normally rather than from the
- workspace.</para>
-
- <para>Any work you did in the
- <filename>oe-local-files</filename> directory is
- preserved in the original files next to the recipe
- during the <filename>devtool finish</filename>
- command.</para>
-
- <para>
- If you specify a destination layer that is the same as
- the original source, then the old version of the
- recipe and associated files are removed prior to
- adding the new version.
- <literallayout class='monospaced'>
- $ devtool finish <replaceable>recipe layer</replaceable>
- </literallayout>
- <note>
- Any changes you want to turn into patches must be
- committed to the Git repository in the source tree.
- </note></para>
-
- <para>As a final process of the
- <filename>devtool finish</filename> command, the state
- of the standard layers and the upstream source is
- restored so that you can build the recipe from those
- areas rather than the workspace.
- <note>
- You can use the <filename>devtool reset</filename>
- command to put things back should you decide you
- do not want to proceed with your work.
- If you do use this command, realize that the source
- tree is preserved.
- </note>
- </para></listitem>
- </orderedlist>
- </para>
- </section>
- </section>
-
- <section id='sdk-a-closer-look-at-devtool-add'>
- <title>A Closer Look at <filename>devtool add</filename></title>
-
- <para>
- The <filename>devtool add</filename> command automatically creates
- a recipe based on the source tree you provide with the command.
- Currently, the command has support for the following:
- <itemizedlist>
- <listitem><para>
- Autotools (<filename>autoconf</filename> and
- <filename>automake</filename>)
- </para></listitem>
- <listitem><para>
- CMake
- </para></listitem>
- <listitem><para>
- Scons
- </para></listitem>
- <listitem><para>
- <filename>qmake</filename>
- </para></listitem>
- <listitem><para>
- Plain <filename>Makefile</filename>
- </para></listitem>
- <listitem><para>
- Out-of-tree kernel module
- </para></listitem>
- <listitem><para>
- Binary package (i.e. "-b" option)
- </para></listitem>
- <listitem><para>
- Node.js module
- </para></listitem>
- <listitem><para>
- Python modules that use <filename>setuptools</filename>
- or <filename>distutils</filename>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Apart from binary packages, the determination of how a source tree
- should be treated is automatic based on the files present within
- that source tree.
- For example, if a <filename>CMakeLists.txt</filename> file is found,
- then the source tree is assumed to be using
- CMake and is treated accordingly.
- <note>
- In most cases, you need to edit the automatically generated
- recipe in order to make it build properly.
- Typically, you would go through several edit and build cycles
- until the recipe successfully builds.
- Once the recipe builds, you could use possible further
- iterations to test the recipe on the target device.
- </note>
- </para>
-
- <para>
- The remainder of this section covers specifics regarding how parts
- of the recipe are generated.
- </para>
-
- <section id='sdk-name-and-version'>
- <title>Name and Version</title>
-
- <para>
- If you do not specify a name and version on the command
- line, <filename>devtool add</filename> uses various metadata
- within the source tree in an attempt to determine
- the name and version of the software being built.
- Based on what the tool determines, <filename>devtool</filename>
- sets the name of the created recipe file accordingly.
- </para>
-
- <para>
- If <filename>devtool</filename> cannot determine the name and
- version, the command prints an error.
- For such cases, you must re-run the command and provide
- the name and version, just the name, or just the version as
- part of the command line.
- </para>
-
- <para>
- Sometimes the name or version determined from the source tree
- might be incorrect.
- For such a case, you must reset the recipe:
- <literallayout class='monospaced'>
- $ devtool reset -n <replaceable>recipename</replaceable>
- </literallayout>
- After running the <filename>devtool reset</filename> command,
- you need to run <filename>devtool add</filename> again and
- provide the name or the version.
- </para>
- </section>
-
- <section id='sdk-dependency-detection-and-mapping'>
- <title>Dependency Detection and Mapping</title>
-
- <para>
- The <filename>devtool add</filename> command attempts to
- detect build-time dependencies and map them to other recipes
- in the system.
- During this mapping, the command fills in the names of those
- recipes as part of the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
- variable within the recipe.
- If a dependency cannot be mapped, <filename>devtool</filename>
- places a comment in the recipe indicating such.
- The inability to map a dependency can result from naming not
- being recognized or because the dependency simply is not
- available.
- For cases where the dependency is not available, you must use
- the <filename>devtool add</filename> command to add an
- additional recipe that satisfies the dependency.
- Once you add that recipe, you need to update the
- <filename>DEPENDS</filename> variable in the original recipe
- to include the new recipe.
- </para>
-
- <para>
- If you need to add runtime dependencies, you can do so by
- adding the following to your recipe:
- <literallayout class='monospaced'>
- RDEPENDS_${PN} += "<replaceable>dependency1 dependency2 ...</replaceable>"
- </literallayout>
- <note>
- The <filename>devtool add</filename> command often cannot
- distinguish between mandatory and optional dependencies.
- Consequently, some of the detected dependencies might
- in fact be optional.
- When in doubt, consult the documentation or the configure
- script for the software the recipe is building for further
- details.
- In some cases, you might find you can substitute the
- dependency with an option that disables the associated
- functionality passed to the configure script.
- </note>
- </para>
- </section>
-
- <section id='sdk-license-detection'>
- <title>License Detection</title>
-
- <para>
- The <filename>devtool add</filename> command attempts to
- determine if the software you are adding is able to be
- distributed under a common, open-source license.
- If so, the command sets the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
- value accordingly.
- You should double-check the value added by the command against
- the documentation or source files for the software you are
- building and, if necessary, update that
- <filename>LICENSE</filename> value.
- </para>
-
- <para>
- The <filename>devtool add</filename> command also sets the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink>
- value to point to all files that appear to be license-related.
- Realize that license statements often appear in comments at
- the top of source files or within the documentation.
- In such cases, the command does not recognize those license
- statements.
- Consequently, you might need to amend the
- <filename>LIC_FILES_CHKSUM</filename> variable to point to one
- or more of those comments if present.
- Setting <filename>LIC_FILES_CHKSUM</filename> is particularly
- important for third-party software.
- The mechanism attempts to ensure correct licensing should you
- upgrade the recipe to a newer upstream version in future.
- Any change in licensing is detected and you receive an error
- prompting you to check the license text again.
- </para>
-
- <para>
- If the <filename>devtool add</filename> command cannot
- determine licensing information, <filename>devtool</filename>
- sets the <filename>LICENSE</filename> value to "CLOSED" and
- leaves the <filename>LIC_FILES_CHKSUM</filename> value unset.
- This behavior allows you to continue with development even
- though the settings are unlikely to be correct in all cases.
- You should check the documentation or source files for the
- software you are building to determine the actual license.
- </para>
- </section>
-
- <section id='sdk-adding-makefile-only-software'>
- <title>Adding Makefile-Only Software</title>
-
- <para>
- The use of Make by itself is very common in both proprietary
- and open-source software.
- Unfortunately, Makefiles are often not written with
- cross-compilation in mind.
- Thus, <filename>devtool add</filename> often cannot do very
- much to ensure that these Makefiles build correctly.
- It is very common, for example, to explicitly call
- <filename>gcc</filename> instead of using the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
- variable.
- Usually, in a cross-compilation environment,
- <filename>gcc</filename> is the compiler for the build host
- and the cross-compiler is named something similar to
- <filename>arm-poky-linux-gnueabi-gcc</filename> and might
- require arguments (e.g. to point to the associated sysroot
- for the target machine).
- </para>
-
- <para>
- When writing a recipe for Makefile-only software, keep the
- following in mind:
- <itemizedlist>
- <listitem><para>
- You probably need to patch the Makefile to use
- variables instead of hardcoding tools within the
- toolchain such as <filename>gcc</filename> and
- <filename>g++</filename>.
- </para></listitem>
- <listitem><para>
- The environment in which Make runs is set up with
- various standard variables for compilation (e.g.
- <filename>CC</filename>, <filename>CXX</filename>, and
- so forth) in a similar manner to the environment set
- up by the SDK's environment setup script.
- One easy way to see these variables is to run the
- <filename>devtool build</filename> command on the
- recipe and then look in
- <filename>oe-logs/run.do_compile</filename>.
- Towards the top of this file, a list of environment
- variables exists that are being set.
- You can take advantage of these variables within the
- Makefile.
- </para></listitem>
- <listitem><para>
- If the Makefile sets a default for a variable using "=",
- that default overrides the value set in the environment,
- which is usually not desirable.
- For this case, you can either patch the Makefile
- so it sets the default using the "?=" operator, or
- you can alternatively force the value on the
- <filename>make</filename> command line.
- To force the value on the command line, add the
- variable setting to
- <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE'><filename>EXTRA_OEMAKE</filename></ulink>
- or
- <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink>
- within the recipe.
- Here is an example using <filename>EXTRA_OEMAKE</filename>:
- <literallayout class='monospaced'>
- EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
- </literallayout>
- In the above example, single quotes are used around the
- variable settings as the values are likely to contain
- spaces because required default options are passed to
- the compiler.
- </para></listitem>
- <listitem><para>
- Hardcoding paths inside Makefiles is often problematic
- in a cross-compilation environment.
- This is particularly true because those hardcoded paths
- often point to locations on the build host and thus
- will either be read-only or will introduce
- contamination into the cross-compilation because they
- are specific to the build host rather than the target.
- Patching the Makefile to use prefix variables or other
- path variables is usually the way to handle this
- situation.
- </para></listitem>
- <listitem><para>
- Sometimes a Makefile runs target-specific commands such
- as <filename>ldconfig</filename>.
- For such cases, you might be able to apply patches that
- remove these commands from the Makefile.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='sdk-adding-native-tools'>
- <title>Adding Native Tools</title>
-
- <para>
- Often, you need to build additional tools that run on the
- <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
- as opposed to the target.
- You should indicate this requirement by using one of the
- following methods when you run
- <filename>devtool add</filename>:
- <itemizedlist>
- <listitem><para>
- Specify the name of the recipe such that it ends
- with "-native".
- Specifying the name like this produces a recipe that
- only builds for the build host.
- </para></listitem>
- <listitem><para>
- Specify the "‐‐also-native" option with the
- <filename>devtool add</filename> command.
- Specifying this option creates a recipe file that still
- builds for the target but also creates a variant with
- a "-native" suffix that builds for the build host.
- </para></listitem>
- </itemizedlist>
- <note>
- If you need to add a tool that is shipped as part of a
- source tree that builds code for the target, you can
- typically accomplish this by building the native and target
- parts separately rather than within the same compilation
- process.
- Realize though that with the "‐‐also-native"
- option, you can add the tool using just one recipe file.
- </note>
- </para>
- </section>
-
- <section id='sdk-adding-node-js-modules'>
- <title>Adding Node.js Modules</title>
-
- <para>
- You can use the <filename>devtool add</filename> command two
- different ways to add Node.js modules: 1) Through
- <filename>npm</filename> and, 2) from a repository or local
- source.
- </para>
-
- <para>
- Use the following form to add Node.js modules through
- <filename>npm</filename>:
- <literallayout class='monospaced'>
- $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"
- </literallayout>
- The name and version parameters are mandatory.
- Lockdown and shrinkwrap files are generated and pointed to by
- the recipe in order to freeze the version that is fetched for
- the dependencies according to the first time.
- This also saves checksums that are verified on future fetches.
- Together, these behaviors ensure the reproducibility and
- integrity of the build.
- <note><title>Notes</title>
- <itemizedlist>
- <listitem><para>
- You must use quotes around the URL.
- The <filename>devtool add</filename> does not require
- the quotes, but the shell considers ";" as a splitter
- between multiple commands.
- Thus, without the quotes,
- <filename>devtool add</filename> does not receive the
- other parts, which results in several "command not
- found" errors.
- </para></listitem>
- <listitem><para>
- In order to support adding Node.js modules, a
- <filename>nodejs</filename> recipe must be part
- of your SDK.
- </para></listitem>
- </itemizedlist>
- </note>
- </para>
-
- <para>
- As mentioned earlier, you can also add Node.js modules
- directly from a repository or local source tree.
- To add modules this way, use <filename>devtool add</filename>
- in the following form:
- <literallayout class='monospaced'>
- $ devtool add https://github.com/diversario/node-ssdp
- </literallayout>
- In this example, <filename>devtool</filename> fetches the
- specified Git repository, detects the code as Node.js
- code, fetches dependencies using <filename>npm</filename>, and
- sets
- <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
- accordingly.
- </para>
- </section>
- </section>
-
- <section id='sdk-working-with-recipes'>
- <title>Working With Recipes</title>
-
- <para>
- When building a recipe using the
- <filename>devtool build</filename> command, the typical build
- progresses as follows:
- <orderedlist>
- <listitem><para>
- Fetch the source
- </para></listitem>
- <listitem><para>
- Unpack the source
- </para></listitem>
- <listitem><para>
- Configure the source
- </para></listitem>
- <listitem><para>
- Compile the source
- </para></listitem>
- <listitem><para>
- Install the build output
- </para></listitem>
- <listitem><para>
- Package the installed output
- </para></listitem>
- </orderedlist>
- For recipes in the workspace, fetching and unpacking is disabled
- as the source tree has already been prepared and is persistent.
- Each of these build steps is defined as a function (task), usually
- with a "do_" prefix (e.g.
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>,
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink>,
- and so forth).
- These functions are typically shell scripts but can instead be
- written in Python.
- </para>
-
- <para>
- If you look at the contents of a recipe, you will see that the
- recipe does not include complete instructions for building the
- software.
- Instead, common functionality is encapsulated in classes inherited
- with the <filename>inherit</filename> directive.
- This technique leaves the recipe to describe just the things that
- are specific to the software being built.
- A
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-base'><filename>base</filename></ulink>
- class exists that is implicitly inherited by all recipes and
- provides the functionality that most recipes typically need.
- </para>
-
- <para>
- The remainder of this section presents information useful when
- working with recipes.
- </para>
-
- <section id='sdk-finding-logs-and-work-files'>
- <title>Finding Logs and Work Files</title>
-
- <para>
- After the first run of the <filename>devtool build</filename>
- command, recipes that were previously created using the
- <filename>devtool add</filename> command or whose sources were
- modified using the <filename>devtool modify</filename>
- command contain symbolic links created within the source tree:
- <itemizedlist>
- <listitem><para>
- <filename>oe-logs</filename>:
- This link points to the directory in which log files
- and run scripts for each build step are created.
- </para></listitem>
- <listitem><para>
- <filename>oe-workdir</filename>:
- This link points to the temporary work area for the
- recipe.
- The following locations under
- <filename>oe-workdir</filename> are particularly
- useful:
- <itemizedlist>
- <listitem><para>
- <filename>image/</filename>:
- Contains all of the files installed during
- the
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
- stage.
- Within a recipe, this directory is referred
- to by the expression
- <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>.
- </para></listitem>
- <listitem><para>
- <filename>sysroot-destdir/</filename>:
- Contains a subset of files installed within
- <filename>do_install</filename> that have
- been put into the shared sysroot.
- For more information, see the
- "<link linkend='sdk-sharing-files-between-recipes'>Sharing Files Between Recipes</link>"
- section.
- </para></listitem>
- <listitem><para>
- <filename>packages-split/</filename>:
- Contains subdirectories for each package
- produced by the recipe.
- For more information, see the
- "<link linkend='sdk-packaging'>Packaging</link>"
- section.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- </itemizedlist>
- You can use these links to get more information on what is
- happening at each build step.
- </para>
- </section>
-
- <section id='sdk-setting-configure-arguments'>
- <title>Setting Configure Arguments</title>
-
- <para>
- If the software your recipe is building uses GNU autoconf,
- then a fixed set of arguments is passed to it to enable
- cross-compilation plus any extras specified by
- <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></ulink>
- or
- <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink>
- set within the recipe.
- If you wish to pass additional options, add them to
- <filename>EXTRA_OECONF</filename> or
- <filename>PACKAGECONFIG_CONFARGS</filename>.
- Other supported build tools have similar variables
- (e.g.
- <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></ulink>
- for CMake,
- <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OESCONS'><filename>EXTRA_OESCONS</filename></ulink>
- for Scons, and so forth).
- If you need to pass anything on the <filename>make</filename>
- command line, you can use <filename>EXTRA_OEMAKE</filename> or the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink>
- variables to do so.
- </para>
-
- <para>
- You can use the <filename>devtool configure-help</filename> command
- to help you set the arguments listed in the previous paragraph.
- The command determines the exact options being passed, and shows
- them to you along with any custom arguments specified through
- <filename>EXTRA_OECONF</filename> or
- <filename>PACKAGECONFIG_CONFARGS</filename>.
- If applicable, the command also shows you the output of the
- configure script's "‐‐help" option as a reference.
- </para>
- </section>
-
- <section id='sdk-sharing-files-between-recipes'>
- <title>Sharing Files Between Recipes</title>
-
- <para>
- Recipes often need to use files provided by other recipes on
- the
- <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>.
- For example, an application linking to a common library needs
- access to the library itself and its associated headers.
- The way this access is accomplished within the extensible SDK is
- through the sysroot.
- One sysroot exists per "machine" for which the SDK is being
- built.
- In practical terms, this means a sysroot exists for the target
- machine, and a sysroot exists for the build host.
- </para>
-
- <para>
- Recipes should never write files directly into the sysroot.
- Instead, files should be installed into standard locations
- during the
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
- task within the
- <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>
- directory.
- A subset of these files automatically goes into the sysroot.
- The reason for this limitation is that almost all files that go
- into the sysroot are cataloged in manifests in order to ensure
- they can be removed later when a recipe is modified or removed.
- Thus, the sysroot is able to remain free from stale files.
- </para>
- </section>
-
- <section id='sdk-packaging'>
- <title>Packaging</title>
-
- <para>
- Packaging is not always particularly relevant within the
- extensible SDK.
- However, if you examine how build output gets into the final image
- on the target device, it is important to understand packaging
- because the contents of the image are expressed in terms of
- packages and not recipes.
- </para>
-
- <para>
- During the
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink>
- task, files installed during the
- <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
- task are split into one main package, which is almost always
- named the same as the recipe, and into several other packages.
- This separation exists because not all of those installed files
- are useful in every image.
- For example, you probably do not need any of the documentation
- installed in a production image.
- Consequently, for each recipe the documentation files are
- separated into a <filename>-doc</filename> package.
- Recipes that package software containing optional modules or
- plugins might undergo additional package splitting as well.
- </para>
-
- <para>
- After building a recipe, you can see where files have gone by
- looking in the <filename>oe-workdir/packages-split</filename>
- directory, which contains a subdirectory for each package.
- Apart from some advanced cases, the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
- and
- <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink>
- variables controls splitting.
- The <filename>PACKAGES</filename> variable lists all of the
- packages to be produced, while the <filename>FILES</filename>
- variable specifies which files to include in each package by
- using an override to specify the package.
- For example, <filename>FILES_${PN}</filename> specifies the
- files to go into the main package (i.e. the main package has
- the same name as the recipe and
- <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
- evaluates to the recipe name).
- The order of the <filename>PACKAGES</filename> value is
- significant.
- For each installed file, the first package whose
- <filename>FILES</filename> value matches the file is the
- package into which the file goes.
- Defaults exist for both the <filename>PACKAGES</filename> and
- <filename>FILES</filename> variables.
- Consequently, you might find you do not even need to set these
- variables in your recipe unless the software the recipe is
- building installs files into non-standard locations.
- </para>
- </section>
- </section>
-
- <section id='sdk-restoring-the-target-device-to-its-original-state'>
- <title>Restoring the Target Device to its Original State</title>
-
- <para>
- If you use the <filename>devtool deploy-target</filename>
- command to write a recipe's build output to the target, and
- you are working on an existing component of the system, then you
- might find yourself in a situation where you need to restore the
- original files that existed prior to running the
- <filename>devtool deploy-target</filename> command.
- Because the <filename>devtool deploy-target</filename> command
- backs up any files it overwrites, you can use the
- <filename>devtool undeploy-target</filename> command to restore
- those files and remove any other files the recipe deployed.
- Consider the following example:
- <literallayout class='monospaced'>
- $ devtool undeploy-target lighttpd root@192.168.7.2
- </literallayout>
- If you have deployed multiple applications, you can remove them
- all using the "-a" option thus restoring the target device to its
- original state:
- <literallayout class='monospaced'>
- $ devtool undeploy-target -a root@192.168.7.2
- </literallayout>
- Information about files deployed to the target as well as any
- backed up files are stored on the target itself.
- This storage, of course, requires some additional space
- on the target machine.
- <note>
- The <filename>devtool deploy-target</filename> and
- <filename>devtool undeploy-target</filename> commands do not
- currently interact with any package management system on the
- target device (e.g. RPM or OPKG).
- Consequently, you should not intermingle
- <filename>devtool deploy-target</filename> and package
- manager operations on the target device.
- Doing so could result in a conflicting set of files.
- </note>
- </para>
- </section>
-
- <section id='sdk-installing-additional-items-into-the-extensible-sdk'>
- <title>Installing Additional Items Into the Extensible SDK</title>
-
- <para>
- Out of the box the extensible SDK typically only comes with a small
- number of tools and libraries.
- A minimal SDK starts mostly empty and is populated on-demand.
- Sometimes you must explicitly install extra items into the SDK.
- If you need these extra items, you can first search for the items
- using the <filename>devtool search</filename> command.
- For example, suppose you need to link to libGL but you are not sure
- which recipe provides libGL.
- You can use the following command to find out:
- <literallayout class='monospaced'>
- $ devtool search libGL
- mesa A free implementation of the OpenGL API
- </literallayout>
- Once you know the recipe (i.e. <filename>mesa</filename> in this
- example), you can install it:
- <literallayout class='monospaced'>
- $ devtool sdk-install mesa
- </literallayout>
- By default, the <filename>devtool sdk-install</filename> command
- assumes the item is available in pre-built form from your SDK
- provider.
- If the item is not available and it is acceptable to build the item
- from source, you can add the "-s" option as follows:
- <literallayout class='monospaced'>
- $ devtool sdk-install -s mesa
- </literallayout>
- It is important to remember that building the item from source
- takes significantly longer than installing the pre-built artifact.
- Also, if no recipe exists for the item you want to add to the SDK,
- you must instead add the item using the
- <filename>devtool add</filename> command.
- </para>
- </section>
-
- <section id='sdk-applying-updates-to-an-installed-extensible-sdk'>
- <title>Applying Updates to an Installed Extensible SDK</title>
-
- <para>
- If you are working with an installed extensible SDK that gets
- occasionally updated (e.g. a third-party SDK), then you will need
- to manually "pull down" the updates into the installed SDK.
- </para>
-
- <para>
- To update your installed SDK, use <filename>devtool</filename> as
- follows:
- <literallayout class='monospaced'>
- $ devtool sdk-update
- </literallayout>
- The previous command assumes your SDK provider has set the default
- update URL for you through the
- <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
- variable as described in the
- "<link linkend='sdk-providing-updates-to-the-extensible-sdk-after-installation'>Providing Updates to the Extensible SDK After Installation</link>"
- section.
- If the SDK provider has not set that default URL, you need to
- specify it yourself in the command as follows:
- <literallayout class='monospaced'>
- $ devtool sdk-update <replaceable>path_to_update_directory</replaceable>
- </literallayout>
- <note>
- The URL needs to point specifically to a published SDK and
- not to an SDK installer that you would download and install.
- </note>
- </para>
- </section>
-
- <section id='sdk-creating-a-derivative-sdk-with-additional-components'>
- <title>Creating a Derivative SDK With Additional Components</title>
-
- <para>
- You might need to produce an SDK that contains your own custom
- libraries.
- A good example would be if you were a vendor with customers that
- use your SDK to build their own platform-specific software and
- those customers need an SDK that has custom libraries.
- In such a case, you can produce a derivative SDK based on the
- currently installed SDK fairly easily by following these steps:
- <orderedlist>
- <listitem><para>
- If necessary, install an extensible SDK that
- you want to use as a base for your derivative SDK.
- </para></listitem>
- <listitem><para>
- Source the environment script for the SDK.
- </para></listitem>
- <listitem><para>
- Add the extra libraries or other components you want by
- using the <filename>devtool add</filename> command.
- </para></listitem>
- <listitem><para>
- Run the <filename>devtool build-sdk</filename> command.
- </para></listitem>
- </orderedlist>
- The previous steps take the recipes added to the workspace and
- construct a new SDK installer that contains those recipes and the
- resulting binary artifacts.
- The recipes go into their own separate layer in the constructed
- derivative SDK, which leaves the workspace clean and ready for
- users to add their own recipes.
- </para>
- </section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/poky/documentation/sdk-manual/sdk-intro.rst b/poky/documentation/sdk-manual/sdk-intro.rst
index 82b7bcf..5a346fa 100644
--- a/poky/documentation/sdk-manual/sdk-intro.rst
+++ b/poky/documentation/sdk-manual/sdk-intro.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
************
Introduction
diff --git a/poky/documentation/sdk-manual/sdk-intro.xml b/poky/documentation/sdk-manual/sdk-intro.xml
deleted file mode 100644
index f42670e..0000000
--- a/poky/documentation/sdk-manual/sdk-intro.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-manual-customization.xsl b/poky/documentation/sdk-manual/sdk-manual-customization.xsl
deleted file mode 100644
index 4f8816f..0000000
--- a/poky/documentation/sdk-manual/sdk-manual-customization.xsl
+++ /dev/null
@@ -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>
diff --git a/poky/documentation/sdk-manual/sdk-manual.rst b/poky/documentation/sdk-manual/sdk-manual.rst
index d7776b7..177826e 100644
--- a/poky/documentation/sdk-manual/sdk-manual.rst
+++ b/poky/documentation/sdk-manual/sdk-manual.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
========================================================================================
Yocto Project Application Development and the Extensible Software Development Kit (eSDK)
diff --git a/poky/documentation/sdk-manual/sdk-manual.xml b/poky/documentation/sdk-manual/sdk-manual.xml
deleted file mode 100755
index 6344478..0000000
--- a/poky/documentation/sdk-manual/sdk-manual.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-style.css b/poky/documentation/sdk-manual/sdk-style.css
deleted file mode 100644
index e0c4416..0000000
--- a/poky/documentation/sdk-manual/sdk-style.css
+++ /dev/null
@@ -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;
-}
diff --git a/poky/documentation/sdk-manual/sdk-using.rst b/poky/documentation/sdk-manual/sdk-using.rst
index 09a194c..4b151e4 100644
--- a/poky/documentation/sdk-manual/sdk-using.rst
+++ b/poky/documentation/sdk-manual/sdk-using.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
**********************
Using the Standard SDK
diff --git a/poky/documentation/sdk-manual/sdk-using.xml b/poky/documentation/sdk-manual/sdk-using.xml
deleted file mode 100644
index 28ee50d..0000000
--- a/poky/documentation/sdk-manual/sdk-using.xml
+++ /dev/null
@@ -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
--->
diff --git a/poky/documentation/sdk-manual/sdk-working-projects.rst b/poky/documentation/sdk-manual/sdk-working-projects.rst
index 2c20a1e..5c828fd 100644
--- a/poky/documentation/sdk-manual/sdk-working-projects.rst
+++ b/poky/documentation/sdk-manual/sdk-working-projects.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: CC-BY-2.0-UK
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
********************************
Using the SDK Toolchain Directly
diff --git a/poky/documentation/sdk-manual/sdk-working-projects.xml b/poky/documentation/sdk-manual/sdk-working-projects.xml
deleted file mode 100644
index 070d903..0000000
--- a/poky/documentation/sdk-manual/sdk-working-projects.xml
+++ /dev/null
@@ -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
--->