1.1. Introduction

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.

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.

All SDKs consist of the following:

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:

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 if SDK_EXT_TYPE is "full" or SDK_INCLUDE_TOOLCHAIN is "1", which is the default.

     ** Sysroot is managed through the use of devtool.  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.