In the
general workflow figure,
the output labeled "Application Development SDK" represents an
SDK.
The SDK generation process differs depending on whether you
build an extensible SDK (e.g.
bitbake -c populate_sdk_ext
imagename
)
or a standard SDK (e.g.
bitbake -c populate_sdk
imagename
).
This section takes a closer look at this output:
![]() |
The specific form of this output is a set of files that
includes a self-extracting SDK installer
(*.sh
), host and target manifest files,
and files used for SDK testing.
When the SDK installer file is run, it installs the SDK.
The SDK consists of a cross-development toolchain, a set of
libraries and headers, and an SDK environment setup script.
Running this installer essentially sets up your
cross-development environment.
You can think of the cross-toolchain as the "host"
part because it runs on the SDK machine.
You can think of the libraries and headers as the "target"
part because they are built for the target hardware.
The environment setup script is added so that you can
initialize the environment before using the tools.
The Yocto Project supports several methods by which you can set up this cross-development environment. These methods include downloading pre-built SDK installers or building and installing your own SDK installer.
For background information on cross-development toolchains in the Yocto Project development environment, see the "Cross-Development Toolchain Generation" section.
For information on setting up a cross-development environment, see the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual.
All the output files for an SDK are written to the
deploy/sdk
folder inside the
Build Directory
as shown in the previous figure.
Depending on the type of SDK, several variables exist that help
configure these files.
The following list shows the variables associated with an
extensible SDK:
DEPLOY_DIR
:
Points to the deploy
directory.
SDK_EXT_TYPE
:
Controls whether or not shared state artifacts are
copied into the extensible SDK.
By default, all required shared state artifacts are
copied into the SDK.
SDK_INCLUDE_PKGDATA
:
Specifies whether or not packagedata is included in the
extensible SDK for all recipes in the "world" target.
SDK_INCLUDE_TOOLCHAIN
:
Specifies whether or not the toolchain is included
when building the extensible SDK.
SDK_LOCAL_CONF_WHITELIST
:
A list of variables allowed through from the build
system configuration into the extensible SDK
configuration.
SDK_LOCAL_CONF_BLACKLIST
:
A list of variables not allowed through from the build
system configuration into the extensible SDK
configuration.
SDK_INHERIT_BLACKLIST
:
A list of classes to remove from the
INHERIT
value globally within the extensible SDK configuration.
This next list, shows the variables associated with a standard SDK:
DEPLOY_DIR
:
Points to the deploy
directory.
SDKMACHINE
:
Specifies the architecture of the machine on which the
cross-development tools are run to create packages for
the target hardware.
SDKIMAGE_FEATURES
:
Lists the features to include in the "target" part
of the SDK.
TOOLCHAIN_HOST_TASK
:
Lists packages that make up the host part of the SDK
(i.e. the part that runs on the
SDKMACHINE
).
When you use
bitbake -c populate_sdk
to create the SDK, a set of default packages apply.
This variable allows you to add more packages.
imagename
TOOLCHAIN_TARGET_TASK
:
Lists packages that make up the target part of the SDK
(i.e. the part built for the target hardware).
SDKPATH
:
Defines the default SDK installation path offered by
the installation script.
SDK_HOST_MANIFEST
:
Lists all the installed packages that make up the host
part of the SDK.
This variable also plays a minor role for extensible
SDK development as well.
However, it is mainly used for the standard SDK.
SDK_TARGET_MANIFEST
:
Lists all the installed packages that make up the
target part of the SDK.
This variable also plays a minor role for extensible
SDK development as well.
However, it is mainly used for the standard SDK.