| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | A build configuration is composed of: |
| | 6 | * the ''tree'' (aka branch) of the repository that should be built, |
| | 7 | * a flag to temporarily or permanently deactivate builds of that tree, |
| | 8 | * a “pretty” name for display, as well as a description that may contain [wiki:WikiFormatting wiki formatting], and |
| | 9 | * a list of ''target platforms'' (see next section). |
| | 10 | |
| | 11 | == Target platforms == |
| | 12 | |
| | 13 | 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 build slaves are matched. Each rule is a regular expression matching a particular slave property, such as the operating system or the processor. |
| | 14 | |
| | 15 | 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. |
| | 16 | |
| | 17 | If a slave connects that doesn't match any of the configured target platforms, the build master will reject its registration. |
| | 18 | |
| | 19 | '''TODO''': ''What about overlapping rules?'' |
