Chapter 8. Developing with the Yocto Project

So far, we have used Poky as a build tool; in other words, we have used it as a tool to design and generate the image that will be used on products. In this chapter, we will look at how the tool can help us with application or kernel development, create external compilation tools, produce a root filesystem suitable for cross development, and generate an image with the tools for use in the target machine for development.

Deciphering the software development kit

A software development kit (SDK) is a set of tools and files used to develop and debug. These tools include compilers, linkers, debuggers, external library headers, and binaries, and may include custom utilities and applications. This set of programming tools is called a toolchain.

In embedded development, the toolchain is often composed of cross-platform tools or tools executed on one architecture that then produces a binary for use in another architecture. For example, a gcc binary that runs on an x86-64-compatible machine and produces one binary for an ARM machine is a cross-compiler. When the tool and resultant binary are executed on the same architecture, it is called a native build.

Usually, when we work on custom source code and use external libraries, for example, libusb or libgl, these libraries are used to build at runtime. The custom source may be built against the library header files, and the binary may be moved somewhere during the execution...

Working with the Poky SDK

Usually, the standard Poky workflow includes creating package recipes and images, and deciding what will be installed on the final product image. However, a huge amount of time is spent developing, writing, testing, or adapting source code for our application.

When we write and test our application, we only care about the application itself, providing the libraries that the application requires before application development, although this can be an iterative process. However, we want a test environment that looks as similar as possible to the final one, mainly because of toolchain compatibility but also to avoid behavioral changes when we integrate the application into our product.

To help with this task, we can create a toolchain to be used externally with the Poky environment. Poky generates an SDK package that can be installed on any computer, regardless of whether Poky is installed on it. In addition, the installed toolchain is compatible with the internal one...

Integrating with Eclipse

Eclipse is a very powerful IDE, and is widely used for the development and debugging of custom applications. It can be configured to work with the Poky SDK. In the Yocto Project SDK Developer's Guide at http://www.yoctoproject.org/docs/2.4/sdk-manual/sdk-manual.html, we can find the supported Eclipse version and can learn how to configure it. Included in the manual are the Yocto Project ADT and an image based on generic toolchain integration.

As soon as our Eclipse is configured, we can use it for development. We can use the IDE to write the source code, and the Poky toolchain can be used to cross-compile it, as Eclipse supports the use of this external toolchain.

In addition, we can use Eclipse to deploy the generated binary file to the target, connected with Eclipse by Ethernet. The binary file and any other required artifacts are copied to the target root filesystem, and it is possible to use the filesystem right after the transfer.

As soon as the binary is copied...

Summary

In this chapter, we learned that the Yocto Project can be used for development as well as for image creation. We learned how to create two types of toolchains, image-based and generic, how to use them, and how to create a development image in order to build and deploy our application on the target machine. In addition, we learned how we can use Eclipse in the development phase to write, build, and debug our applications.

In the next chapter, we will look at how we can configure Poky to help us in the debugging process, how we can configure our system to provide the required tools for a remote debug using GDB, how we can track our changes using buildhistory, and how we can use a handy tool called devshell.