To speed up compilations, many Qt users -- and indeed the Trolltech developers themselves -- use Trolltech's Teambuilder product to distribute the build load to all available Unix machines on the local network. In this article, we will give some hints on how to use Teambuilder to its full potential.

• Coping with Different Compiler Versions
• Coping with Different OSes and Architectures
• The Next Level: Cross-Compilers

Some developer teams are lucky enough to have only one target platform to worry about. In such teams, all developers can run the same operating system and compiler on their development machines, and the task of Teambuilder is simply to distribute the compilation jobs -- i.e., the individual source files of the build -- to the machine farm for parallel compilation.

Unfortunately, the reality is often different for developer teams using Qt: multiple target platforms is often the reason Qt was selected in the first place. And more often than not, there are some machines with a different operating system or compiler version accessible on the local network, machines with idle CPU cycles that one would dearly like to use in the compilation farm. Here, we will see how to best use Teambuilder in such heterogeneous environments.

By default, Teambuilder assumes that all compilers in the farm with the same name as the one requested (e.g., gcc) are compatible, so all of them can be used to generate object files that will happily link together at the end of the build. In reality, the output from different versions of the same compiler can be binary incompatible. In particular, this is the case with GCC versions 3.2 and 3.3.

The solution is to tell Teambuilder which compiler versions you will allow to compile your project. This is done by setting the TEAMBUILDER_CC_VERSION environment variable in the shell you use for compilation. For example, if you are running GCC 3.3.3, the following command (which you can type directly or add to your .bashrc file) will allow only 3.3.x versions of GCC to be used for your compilation jobs:

export TEAMBUILDER_CC_VERSION=3.3.*

Teambuilder understands the wildcard constructs *, ?, and [123] with their usual meanings.

Teambuilder automatically detects the operating system and hardware architecture of the machines in the farm. In tbmonitor, this is displayed in the form [OS:arch]. By default, compilation jobs are only distributed to machines with the same operating system as the one initiating the build.

In the case where the farm contains machines with incompatible hardware architectures, but which run the same operating system, you will want to tell Teambuilder to only use machines with the same architecture as your own for your builds. This is done through the TEAMBUILDER_SYSTEM environment variable. For example, if there are 32-bit and 64-bit machines running Linux in the farm, and you are building for 64-bit, set the variable like this:

export TEAMBUILDER_SYSTEM=Linux:x86_64

Rather than simply excluding a machine with another hardware architecture than your own, it is very tempting to use the machine's idle CPU cycles for your own builds by installing a cross-compiler on it.

A natural choice for this is GCC. To set it up as a cross-compiler, your best bet is probably to search the net for pre-built packages for your host and target systems, or to use the tools and help provided at Dan Kegek's homepage to build your own.

When the cross-compiler is in place, we just need to tell Teambuilder about it. On the machine with the cross-compiler, locate (or create) tbdaemon's configuration file. (It is "/etc/tbdaemon.conf" if tbdaemon is started by root; otherwise it is " /.tbdaemonrc".) If, for example, you have installed a 64-bit cross-compiling GCC on a 32-bit Linux machine, the configuration file must contain the following lines:

[Settings]
Compilers=gcc,g++,/path/to/crosscompiler/gcc[Linux:x86_64]

After restarting tbdaemon, Teambuilder will use the cross compiler for builds where TEAMBUILDER_SYSTEM is set to Linux:x86_64. Note that having a Compilers entry in the configuration file will disable tbdaemon's normal auto-discovery of the native compilers, so you will need to include all those that you want to use. Also note that the Compilers line should contain no unnecessary whitespace.

Summing up, we have seen how to use Teambuilder in heterogeneous machine farms. As always, though, remember to not let your bosses in on the secret of speeding up your builds by distributing the compilation jobs -- they just might get funny ideas about not buying new and faster machines this year, and how will you get the necessary iron for playing Half-Life 2 then?