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. Additionally, the manual also provides information on how to use the popular Eclipse™ IDE as part of your application development workflow within the SDK environment.
All SDKs consist of the following:
Cross-Development Toolchain: This toolchain contains a compiler, debugger, and various miscellaneous tools.
Libraries, Headers, and Symbols: The libraries, headers, and symbols are specific to the image (i.e. they match the image).
Environment Setup Script:
This *.sh
file, once run, sets up the
cross-development environment by defining variables and
preparing for SDK use.
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 OpenEmbedded build system.
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
libc
, 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
populate_sdk
and
populate_sdk_ext
archives.
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 gcc
as a set of compiler options.
Those options are set up by the environment script and contained in
variables such as
CC
and
LD
.
This reduces the space needed for the tools.
Understand, however, that every target still needs a sysroot because
those binaries are target-specific.
The SDK development environment consists of the following:
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
Metadata
configuration and extensions,
which allows you to cross-develop on the host machine for the
target hardware.
Additionally, the extensible SDK contains the
devtool
functionality.
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.
The Eclipse IDE Yocto Plug-in. This plug-in is available for you if you are an Eclipse user. In the same manner as QEMU, the plug-in is not literally part of the SDK but is rather available for use as part of the development process.
Various performance-related tools that can enhance your development experience. These tools are also separate from the actual SDK but can be independently obtained and used in the development process.
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:
Feature | Standard SDK | Extensible SDK |
---|---|---|
Toolchain | Yes | Yes* |
Debugger | Yes | Yes* |
Size | 100+ MBytes | 1+ GBytes (or 300+ MBytes for minimal w/toolchain) |
devtool |
No | Yes |
Build Images | No | Yes |
Updateable | No | Yes |
Managed Sysroot** | No | Yes |
Installed Packages | No*** | Yes**** |
Construction | Packages | Shared State |
* Extensible SDK contains the toolchain and debugger ifSDK_EXT_TYPE
is "full" orSDK_INCLUDE_TOOLCHAIN
is "1", which is the default. ** Sysroot is managed through the use ofdevtool
. 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.