The installation page has a simple test process which will work most of the time to get your system up and running. This page has more detail about running the test process to achieve various things.
The base script which handles everything is the run_build.pl script. The commandline options are:
$ ./run_build.pl --help usage: ./run_build.pl [options] [branch] where options are one or more of: --nosend = don't send results --nostatus = don't set status files --force = force a build run (ignore status files) --from-source=/path = use source in path, not from SCM or --from-source-clean=/path = same as --from-source, run make distclean first --config=/path/to/file = alternative location for config file --keepall = keep directories if an error occurs --verbose[=n] = verbosity (default 1) 2 or more = huge output. --quiet = suppress normal error message --test = short for --nosend --nostatus --verbose --force --skip-steps=list = skip certain steps --only-steps=list = only do certain steps, not allowed with skip-steps lists can be comma, colon, or space separated Default branch is HEAD. Usually only the --config option should be necessary.
In each of the following sample command lines, remember that
--test will force all steps and will not locally store the state of the git checkout nor the state of each of stage, nor will it submit the results to the server.
Most of the time, you probably just want to enable a feature and test if the build process changes. In that case, this command is likely all that you’ll want:
./run_build.pl --test --verbose=2 --only-steps=configure,make
Test mode, run just configure and make steps, and keep the directories:
./run_build.pl --test --only-steps configure,make --keepall
Test mode, debug mode, run just configure and make steps:
./run_build.pl --test --only-steps configure,make --verbose=2
Debug mode, only run configure and make if there is a new commit, submit results to server:
./run_build.pl --only-steps configure,make --verbose=2
Run all steps, only if there is a new commit, configured to also do make_test, but limit the range of tests from 1 to 9:
./run_build.pl --override range_test_num='1 9'
Just build docs, don’t submit results (configure builds the Local/Makefile, which is required for doc building) :
./run_build.pl --force --only-steps=configure,make-doc --nosend
Just build docs, equivalent command:
./run_build.pl --test --only-steps=configure,make-doc
Just build docs, but allow it to submit results (not advised since you aren’t building the actual binary) :
./run_build.pl --force --only-steps=configure,make-doc
Sometimes you need to figure out why one test is failing. To see exactly what is happening, you can create a temporary build, don’t delete it, and then manually run the test in a debug mode. In the following example, I’ll assume that I’m wanting to find why test 433 is failing
PATH="$PATH:/sbin" ./run_build.pl --test --verbose=2 --force --only-steps=configure,make,test \ --override range_num_tests='1 1' --keepall
The above will create a subdirectory of the format exim.$PID (of the script running the build farm). In the example above, the git checkout of the exim sources was in
$HOME/buildfarm/HEAD/exim.4689/, so we change into the test directory and manually instantiate the runtest script, specifying which test we want it to run.
./runtest $HOME/buildfarm/HEAD/exim.4689/src/build-Linux-i386/exim -DEBUG 433 433
It will print out copious debug output and you can hopefully find the problem based on that output.