Introduction

Bob is a build automation tool inspired by bitbake and portage. Its main purpose is to build software packages, very much like packages in a Linux distribution. It typically works on coarse entities i.e. not on individual source files.

../_images/overview.png

In contrast to similar tools, Bob tries to focus on the following requirements that are special when building complex embedded systems:

  • Holistic approach: Bob can be used to describe and build the whole software stack of a project. At the same time, Bob can be used to build, change and test arbitrary parts of the project by involved developers.

  • Cross compilation with multiple tool chains: Some of these tool chains may have to be built during the build process. Bob can also be used to verify the build environment, override specific host tools or abort the process if some prerequisites are not met.

  • Reproducible builds: Bob aims to provide a framework which enables reproducible and even bit identical builds. To do so, each package declares its required environment, tools and dependencies. With this information Bob executes the build steps in a controlled environment.

  • Continuous integration: building from live branches and not just fixed tarballs is fully supported. All packages are described in a declarative way. Using this information, the packages can be built locally but also as separate jobs on a build server (e.g. Jenkins). Bob can track all dependencies between the packages, and commits can trigger rebuilds of all affected packages.

  • Variant management: because all packages declare their input environment explicitly, Bob can compute if a package must be built differently or can be reused from another build.

All in all Bob is just a framework for the controlled execution of shell scripts. To maximize reproducibility, Bob tracks the environment and the input of these scripts. If in doubt, Bob will rebuild the (supposedly) changed package.

What sets Bob apart from other systems is the functional approach. Bob viewes build recipes as (sometimes imperfect) functions where the source code and dependencies are the input and the built package is the result. Every package is kept separately and only declared dependencies are available to the package build scripts.

In contrast to that, typical other package build systems describe dependencies that must be satisfied in a shared root file system. This ensures that required files are present at the known locations but it is perfectly ok that more is there. Bob on the other hand has no concept of “installation”. Packages are computed with their scripts and from the declared input.