Bob recipes are Yaml files that collectively describe the whole structure of a project, including their tools. Each recipe describes how a package is built and what the input, such as source code or other packages, is. A typical recipe looks like this:
inherit: [autotools]
metaEnvironment:
PKG_VERSION: "4.1.3"
PKG_LICENSE: "GPL-3.0-or-later"
depends:
- libs::mpfr-dev
- use: []
depends:
- libs::mpfr-tgt
checkoutSCM:
scm: url
url: ${GNU_MIRROR}/gawk/gawk-${PKG_VERSION}.tar.xz
digestSHA1: "76b0acbbdeaa0e58466675c5faf68895eedd8306"
stripComponents: 1
buildVars: [GAWK_DISABLE_EXTENSIONS]
buildScript: |
autotoolsBuild $1 \
${GAWK_DISABLE_EXTENSIONS:+--disable-extensions}
packageScript: |
autotoolsPackageTgt
provideDeps: [ "*-tgt" ]
The recipes describe packages in a functional manner. They define the input (source code, other packages, environment variables and tools), how the package is built and what the final output is. In contrast to the usual "sysroot"-approach of other build systems Bob will keep packages separate from each other in the file system. Given this functional approach Bob can track changes very effectively and minimize undetected cross-package dependencies.
Inherit common definitions and functionality from classes. They are used to factor out repeatedly used functions, like supporting standard build systems. Classes can inherit each other.
Define variables that describe the package. These variables can be used in the recipe in other sections.
Only declared dependencies are accessible when the package is built. Each dependency is kept in a separete workspace to not mix results so that changes can be tracked accurately.
Defines one or more sources of the package. Bob has built-in support for fetching URLs (e.g. http), git, svn and cvs. An additional checkoutScript can be used for advanced stuff like applying patches.
Bob tightly controls the environment variables that are set during the script execution. Only declared variables will be available at built time. Using this knowledge Bob can track which variables have an impact on what packages.
A bash script that builds the package. In this case a shell function defined by the autotools class is used that does all the heavy lifting. All scripts are run with errexit, nounset and pipefail to detect errors early.
This bash script extracts the final result from the build workspace. In this case the recipe uses the standard function from the autotools class. The files left in the workspace by this script are the result of the package.
Forward dependencies upwards towards the dependent packages so that they do not need to care about transitive dependencies.
Despite the regular recipes as shown above there are special kinds that describe the build environment. They complete the holistic approach of Bob to control all aspects of the sofware build. Except the usage of some additional keywords they are like any other recipe.
Tool recipes bring in build tools that are used during package compilation. Tools have a name and are declared by the provideTools keyword. Typically this is the C(++)-compiler but it could be any tool that is required, e.g. flex, bison, protoc, you name it. They can be downloaded or even built with the project.
A sandbox is used to almost fully virtualize the host build environment. It is declared by a provideSandbox keyword. Think of it as a file system image which is used by Bob to create a fresh temporary container for each package that is built. Bob uses user namespaces so that no root priviliges are needed.