Lesson

SDKs and Application Development

How to generate SDKs and support application development workflows outside the full Yocto build environment

The Yocto Project Platform Development Lesson 11 of 11

Yocto is not only about building the final image. It also supports the wider development workflow around that image.

In many teams, application developers do not work directly inside the full Yocto build environment every day. Instead, they rely on an SDK, a sysroot, and a clear handoff between platform development and application development.

That handoff is one of the most useful things Yocto provides.

Why the SDK Matters

The full Yocto build environment is powerful, but it is not always the right place for day-to-day application development.

Application teams often need to:

• compile against the same target libraries as the final product
• use the correct cross-toolchain
• integrate with the platform without rebuilding the whole distribution
• work faster than a full image build cycle would allow

This is where the SDK becomes useful.

An SDK gives application developers a controlled development environment that matches the target platform more closely than a generic cross-compiler would.

What an SDK Contains

An SDK normally contains the pieces needed to build software for the target outside the full BitBake workflow.

That usually includes:

Cross-toolchain

The compiler, linker, and related tools that build for the target architecture.

Sysroot

Headers, libraries, and other target development files that match the platform.

Environment setup

A script that sets the paths and variables needed to use the SDK correctly.

Target-specific metadata

Enough platform context for the resulting binaries to match the target system.

This means application developers can build software against the same platform interfaces that the Yocto image uses, without running the whole build system for every change.

Generate an SDK

The common way to generate an SDK is to build the SDK task for an image.

For example:

bitbake -c populate_sdk my-image

This tells Yocto to create an installable SDK for the selected image and configuration.

The SDK is tied to the image and platform choices used to build the system.

If the image changes significantly, the SDK should usually be regenerated so the development environment still matches the platform.

Why Build the SDK from an Image

The SDK is usually generated from an image because the image already expresses:

• which packages are part of the platform
• which libraries and development interfaces exist
• which machine and distro settings are active
• which toolchain and target architecture are relevant

That gives you a much more accurate development environment than assembling one by hand.

Installing and Using the SDK

Once generated, the SDK is normally installed on a developer machine and activated with an environment setup script.

The exact filename varies, but the workflow usually looks like:

./poky-glibc-x86_64-my-image-cortexa53-toolchain.sh
source /opt/poky/<version>/environment-setup-cortexa53-poky-linux

After that, the shell environment is configured so that tools such as:

• gcc
• g++
• pkg-config
• cmake
• meson

use the target-aware cross-development settings instead of the host defaults.

The Role of the Sysroot

One of the most important parts of the SDK is the sysroot.

The sysroot contains the target headers and libraries that application builds should use.

This matters because building with the wrong headers or libraries is one of the fastest ways to create software that compiles on the host but does not work on the target.

With the SDK sysroot, the build sees the target platform’s development files rather than the host system’s versions.

A Typical Application Workflow

A common team workflow looks like this:

1. The platform team builds and maintains the Yocto image.
2. The platform team generates an SDK from that image.
3. Application developers install the SDK on their machines.
4. Application developers build and test software against that SDK.
5. The resulting application is later packaged cleanly into Yocto as a recipe.

This gives teams a useful separation of responsibilities.

The platform team owns:

• the distro
• the BSP
• the image composition
• the platform libraries and interfaces

The application team owns:

• the application source
• day-to-day feature development
• application-level testing
• integration against the provided SDK

Why This Separation Helps

Without an SDK workflow, application teams often end up doing one of two bad things:

• building directly against host libraries
• trying to do every application iteration inside the full Yocto build

The first approach creates environment drift.

The second approach creates friction and slows down normal development.

The SDK gives you a middle ground:

• faster than full image rebuilds for every change
• safer than building against arbitrary host dependencies

SDKs and pkg-config

Many application builds rely on pkg-config to find include paths, compiler flags, and libraries.

Inside the SDK environment, pkg-config is typically set up so it resolves against the SDK sysroot rather than the host system.

That is one reason why using the SDK environment script matters so much. Without it, tools may silently fall back to host paths and produce misleading results.

SDKs and CMake or Meson

Modern application builds often use CMake or Meson.

These build systems can work well with Yocto-generated SDKs because the SDK provides:

• the toolchain
• the sysroot
• the environment variables needed for cross-compilation

That means application developers can often build their software with the normal project build system while still targeting the embedded platform correctly.

When to Use the SDK and When to Use Yocto Recipes

It is important to understand what the SDK is for and what it is not for.

The SDK is good for:

• application development
• library integration testing
• cross-compiling software outside the full build
• giving developers a stable target-matched environment

A Yocto recipe is still needed for:

• reproducible product builds
• packaging software into the image
• CI and release builds
• long-term maintainability

This means the SDK supports development, but the final product integration should still return to proper Yocto metadata.

Do Not Treat the SDK as the Final Delivery Mechanism

A common trap is to build an application with the SDK and then manually copy the result onto the target forever.

That may be acceptable for quick experiments, but it is not a good long-term product workflow.

Once the application needs to become part of the product properly, it should usually be:

• described by a recipe
• packaged through Yocto
• selected by the image or package group

That gives you repeatability and traceability.

A Practical Example

Suppose the platform team maintains an image called my-dev-image.

They generate an SDK with:

bitbake -c populate_sdk my-dev-image

An application developer installs the SDK, sources the environment script, and then builds a Qt or CMake application against the target sysroot.

Later, once the application is ready to become part of the product image, the team creates a proper recipe and adds the package to the image through Yocto.

That keeps the fast development path and the repeatable product path clearly separated.

SDK Version Drift

One practical issue to watch for is SDK drift.

If the platform changes but developers keep using an older SDK, strange problems can appear:

• compile errors due to header mismatches
• runtime errors due to ABI changes
• packages working in development but failing in integration

That is why SDK generation should usually be tied to a known platform version or release process.

eSDKs and Extended Workflows

Some Yocto setups also use the extensible SDK, often called the eSDK.

The main idea is that it can support a deeper integration with Yocto tooling than a basic SDK.

You do not need the eSDK to understand the main workflow in this module, but it is useful to know that Yocto supports more advanced development handoff patterns when a project needs them.

Summary

SDKs are how Yocto supports application development outside the full BitBake environment.

They provide:

• a cross-toolchain
• a target-matched sysroot
• environment setup for correct cross-compilation

This gives application developers a fast and reliable way to work against the platform while keeping final product integration inside normal Yocto recipes and image builds.

Check your understanding

Quick quiz: SDKs and application development

A short review of the SDK handoff model.

Question 1 Why is an SDK often a better day-to-day fit for application teams than working inside the full Yocto build tree?

It provides a target-matched toolchain and sysroot without needing the full Yocto build every time It replaces the need for recipes in production It automatically chooses the target hardware at runtime

Question 2 A developer has been manually copying an SDK-built binary onto the target during prototyping. What should happen once that application becomes part of the product?

Keep the manual copy step because it matches the SDK workflow Create a proper recipe and integrate it through normal Yocto packaging and image selection Move the binary into the BSP layer so it ships with the board

Question 3 The platform team updates libraries and headers, but several application developers keep using last month’s SDK. What kind of failure pattern should you expect?

Header or ABI mismatches that compile badly, link badly, or fail at runtime The image recipe will stop parsing until the old SDK is removed Only deployment artifacts change; application builds stay unaffected

Check answers