= Bitten Build Configurations =

{{{
#!div class=important
The content on this page is maintained as part of default documentation - see [wiki:Documentation/configure.html]
}}}

While [wiki:BuildRecipes build recipes] tell a slave what is to be built (and how), '''build configurations''' are the means by which the ''build master'' is informed about what needs to be built.

A build configuration is composed of:
 * a name used as identifier, a “pretty” name for display, as well as a description that may contain [wiki:WikiFormatting wiki formatting],
 * a flag to temporarily or permanently deactivate builds of that tree,
 * a path (or branch name) that identifies the subset of the repository that should be built,
 * a [wiki:BuildRecipes build recipe] for the configuration, and
 * a list of ''target platforms'' (see next section).

== Target platforms ==

A target platform is something like ''“NetBSD on x86”'' or ''“Win32 with Java 1.4”''.

Technically, a target platform is a named set of rules against which the properties of build slaves are matched. Each rule is a regular expression matching a particular slave property, such as the operating system or the processor. When a slave connects to the build master, it sends a registration message that includes information about the slave.

A build configuration must have at least one target platform assigned to it before it becomes fully active.

=== Slave Properties ===

By default, the following properties are included:

 `family`:: The basic type of operating system, typically “posix” for Unix-like systems and “nt” for Win32 systems.
 `os`:: The name of the operating system (for example “Darwin”, “Linux” or “Windows”).
 `version`:: The operating system version.
 `machine`:: The hardware platform (for example “i686” or “Power Macintosh”).
 `processor`:: The processor architecture (for example “athlon” or “powerpc”).

Note that not all of these properties may be available for all platforms. For example, the `machine` and `processor` properties are currently empty for build slaves running on Windows. Additional properties can be set up on the slave side using a [wiki:SlaveConfiguration configuration file].

You can get what these properties is by following command:
{{{
bitten-slave <url> -v -k -n
}}}
You'll get some string like
{{{
[DEBUG]  Sending slave configuration:\
 <slave name="mypc"><platform processor="sparc">sun4u</platform>\
<os version="2.8" family="posix">Solaris</os></slave>
}}}
Note the platform sun4u is the machine property.

=== Examples ===

So to set up a target platform, you create rules that are checked against the properties of the slave. For example, a target platform that matches slave running Linux on x86 would look like this:

|| '''Property''' || '''Expression''' ||
|| `os` || `^Linux` ||
|| `machine` || `^[xi]\d?86$` ||

A target platform that matches any slaves running on Windows might look like this:

|| '''Property''' || '''Expression''' ||
|| `family` || `^nt$` ||


The build master will request a build from at most one slave for every target platform. So, for example, if there are three slaves connected that are running NetBSD on x86, only one of them will perform the build of a specific revision. Slaves that match a particular target platform are treated as if they were completely interchangable.

If a slave connects that doesn't match any of the configured target platforms, the build master will reject its registration.