fundamentally, BitBake is a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex inter-task dependency constraints. One of BitBake's main users, OpenEmbedded, takes this core and builds embedded Linux software stacks using a task-oriented approach. Conceptually, BitBake is similar to GNU Make in some regards but has significant differences: BitBake executes tasks according to provided metadata that builds up the tasks. Metadata is stored in recipe (.bb), configuration (.conf), and class (.bbclass) files and provides BitBake with instructions on what tasks to run and the dependencies between those tasks. BitBake includes a fetcher library for obtaining source code from various places such as source control systems or websites. The instructions for each unit to be built (e.g. a piece of software) are known as recipe files and contain all the information about the unit (dependencies, source file locations, checksums, description and so on). BitBake includes a client/server abstraction and can be used from a command line or used as a service over XMLRPC and has several different user interfaces.

BitBake was originally a part of the OpenEmbedded project. It was inspired by the Portage package management system used by the Gentoo Linux distribution. On December 7, 2004, OpenEmbedded project team member, Chris Larson split the project into two distinct pieces: BitBake, a generic task executor OpenEmbedded, a metadata set utilized by BitBake Today, BitBake is the primary basis of the OpenEmbedded project, which is being used to build and maintain a number of projects and embedded Linux distributions such as the Angstrom Distribution and the Yocto Project. Prior to BitBake, no other build tool adequately met the needs of an aspiring embedded Linux distribution. All of the build systems used by traditional desktop Linux distributions lacked important functionality, and none of the ad-hoc buildroot systems, prevalent in the embedded space, were scalable or maintainable. Some important original goals for BitBake were: Handle cross-compilation. Handle inter-package dependencies (build time on target architecture, build time on native architecture, and runtime). Support running any number of tasks within a given package, including, but not limited to, fetching upstream sources, unpacking them, patching them, configuring them, and so forth. Be Linux distribution agnostic for both build and target systems. Be architecture agnostic. Support multiple build and target operating systems (e.g. Cygwin, the BSDs, and so forth). Be self contained, rather than tightly integrated into the build machine's root filesystem. Handle conditional metadata on the target architecture, operating system, distribution, and machine. Be easy to use the tools to supply local metadata and packages against which to operate. Be easy to use BitBake to collaborate between multiple projects for their builds. Provide an inheritance mechanism that share common metadata between many packages. Over time it became apparent that some further requirements were necessary: Handle variants of a base recipe (e.g. native, sdk, and multilib). Split metadata into layers and allow layers to override each other. Allow representation of a given set of input variables to a task as a checksum. Based on that checksum, allow acceleration of builds with prebuilt components. BitBake satisfies all the original requirements and many more with extensions being made to the basic functionality to reflect the additional requirements. Flexibility and power have always been the priorities. BitBake is highly extensible and supports embedded Python code and execution of any arbitrary tasks.

BitBake is a program written in the Python language. At the highest level, BitBake interprets metadata, decides what tasks are required to run, and executes those tasks. Similar to GNU Make, BitBake controls how software is built. GNU Make achieves its control through "makefiles". BitBake uses "recipes". BitBake extends the capabilities of a simple tool like GNU Make by allowing for much more complex tasks to be completed, such as assembling entire embedded Linux distributions. The remainder of this section introduces several concepts that should be understood in order to better leverage the power of BitBake.

BitBake Recipes, which are denoted by the file extension .bb, are the most basic metadata files. These recipe files provide BitBake the following: Descriptive information about the package The version of the recipe When dependencies exist Where the source code resides Whether the source code requires any patches How to compile the source code Where on the target machine to install the package being compiled Within the context of BitBake, or any project utilizing BitBake as it's build system, files with the .bb extension are referred to as recipes. The term "package" is also commonly used to describe recipes. However, since the same word is used to describe packaged output from a project, it is best to maintain a single descriptive term, "recipes".

Configuration files, which are denoted by the .conf extension, define various configuration variables that govern the project's build process. These files fall into several areas that define machine configuration options, distribution configuration options, compiler tuning options, general common configuration options, and user configuration options. The main configuration file is the sample bitbake.conf file, which is located within the BitBake source tree conf directory.

Class files, which are denoted by the .bbclass extension, contain information that is useful to share between metadata files. The BitBake source tree currently comes with one class metadata file called base.bbclass. You can find this file in the classes directory. The base.bbclass is special in that any new classes that a developer adds to a project are required to inherit base.bbclass automatically. This class contains definitions for standard basic tasks such as fetching, unpacking, configuring (empty by default), compiling (runs any Makefile present), installing (empty by default) and packaging (empty by default). These tasks are often overridden or extended by other classes added during the project development process.

You can obtain BitBake several different ways: Installation using your Distribution Package Management System: This method is not recommended because the BitBake version, in most cases provided by your distribution, is several releases behind a snapshot of the BitBake repository. Taking a snapshot of BitBake: Downloading a snapshot of BitBake from the source code repository is the recommended method as you are assured of having the most recent stable BitBake release. The following example downloads a snapshot of BitBake version 1.17.0: $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz $ tar zxpvf bitbake-1.17.0.tar.gz After extraction of the tarball using the tar utility, you have a directory entitled bitbake-1.17.0. Cloning BitBake: Using Git to clone the BitBake source code repository is also a recommended method when you need the absolute latest BitBake source. Realize that using this method could expose you to areas of BitBake that are under development. Here is an example: $ git clone git://git.openembedded.org/bitbake This command clones the BitBake Git repository into a directory called bitbake. Alternatively, you can designate a directory after the git clone command if you want to call the new directory something other than bitbake. Here is an example that names the directory bbdev: $ git clone git://git.openembedded.org/bitbake bbdev