Build systems

The idea of a build system is to automate all the steps I have described up to this point. A build system should be able to build, from upstream source code, some or all of the following:

• The toolchain
• The bootloader
• The kernel
• The root filesystem

Building from an upstream source is important for a number of reasons. It means that you have peace of mind that you can rebuild at any time, without external dependencies. It also means that you have the source code for debugging and that you can meet your license requirements to distribute that to users where necessary.

Therefore to do its job, a build system has to be able to do the following:

• Download a source from upstream, either directly from the source code control system or as an archive, and cache it locally
• Apply patches to enable cross compilation, fix architecture-dependent bugs, apply local configuration policies, and so on
• Build the various components
• Create a staging area and assemble a root filesystem
• Create image files in various formats ready to be loaded onto the target

Other things that are useful are as follows:

• Add your own packages containing, for example, applications or kernel changes
• Select various root filesystem profiles: large or small, with and without graphics or other features
• Create a standalone SDK that you can distribute to other developers so that they don't have to install the complete build system
• Track which open source licenses are used by the various packages you have selected
• Allow you to create updates for in-field updating
• Have a user-friendly user interface

In all cases, they encapsulate the components of a system into packages, some for the host and some for the target. Each package is defined by a set of rules to get the source, build it, and install the results in the correct location. There are dependencies between the packages and a build mechanism to resolve the dependencies and build the set of packages required.

Open source build systems have matured considerably over the last few years. There are many around, including:

• Buildroot: An easy-to-use system using GNU make and Kconfig (http://buildroot.org)
• EmbToolkit: A simple system for generating root filesystems; the only one at the time of writing that supports LLVM/Clang out of the box (https://www.embtoolkit.org)
• OpenEmbedded: A powerful system which is also a core component of the Yocto Project and others (http://openembedded.org)
• OpenWrt: A build tool oriented towards building firmware for wireless routers (https://openwrt.org)
• PTXdist: An open source build system sponsored by Pengutronix (http://www.pengutronix.de/software/ptxdist/index_en.html)
• Tizen: A comprehensive system, with emphasis on mobile, media, and in-vehicle devices (https://www.tizen.org)
• The Yocto Project: This extends the OpenEmbedded core with configuration, layers, tools, and documentation: probably the most popular system (http://www.yoctoproject.org)

I will concentrate on two of these: Buildroot and The Yocto Project. They approach the problem in different ways and with different objectives.

Buildroot has the primary aim of building root filesystem images, hence the name, although it can build bootloader and kernel images as well. It is easy to install and configure, and generates target images quickly.

The Yocto Project, on the other hand, is more general in the way it defines the target system and so it can build fairly complex embedded devices. Every component is generated as a package in RPM, .dpkg or .ipk format (see the following section) and then the packages are combined together to make the filesystem image. Furthermore, you can install a package manager in the filesystem image, which allows you to update packages at runtime. In other words, when you build with the Yocto Project, you are, in effect, creating your own custom Linux distribution.