Peter Eisentraut wrote:
>Tom Lane wrote:
>
>
>>Where the buildfarm falls down a bit is on the cross-product
>>coverage. But I think you're not going to get the cross product
>>without a call for port reports; there aren't that many people who
>>are going to offer dedicated time on every random platform there is.
>>
>>
>
>Once RC1 is out and the build farm has picked it up, we should start
>filling out our little table with the build farm results and then look
>for ways to fill the holes. Does the build farm turn on all the
>compiler options? It really should. I'm looking for
>
>/configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \
>--with-perl --with-python --with-krb5 --with-pam -with-openssl
>make
>make install
>make check
>
>
I know you're busy, but please take a few moments to check out how it works.
The configuration is chosen in the config file for each member, rather
than being dictated centrally. Every report (success and failure) shows
the config settings. The only setting that buildfarm needs to set itself
is --prefix which is chosen relative to another config file setting.
Everything else is up to the farm member sysadmin to choose appropriately.
A single member can run more than one branch, and per-branch config can
be set up. A single machine can run more than one farm member (e.g. to
use different compilers).
In addition to the steps above, we do the following:
initdb
pg_ctl start
make installcheck
make contrib
make contrib::installcheck
pg_ctl stop
The worth of these extra steps has already been shown - a number of bugs
of unknown age and provenance have been fixed, especially in contrib.
It is possible to run the buildfarm yourself without even being
registered on www.pgbuildfarm.org - the script has a --nosend option
which means it doesn't try to upload its results to the server. I
encourage anyone interested in running buildfarm to try this option first.
cheers
andrew
