From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Buildfarm coverage (was Re: OK, ready for RC1 or Beta6) |
Date: | 2004-12-03 20:54:25 |
Message-ID: | 12897.1102107265@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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
I was just thinking about what the buildfarm should do with configure
options. IMHO it would be most useful if we could have it testing a
variety of different combinations. For instance, that stupid mistake
I made last night would only have been detected by testing the
combination --with-openssl and *not* --enable-thread-safety. We
obviously are not going to have enough machines to test every possible
combination, let alone every combination on every platform, but maybe we
could make sure that interesting option combinations appear at least
once among the set of buildfarm machines.
I think it would be useful to cover all 16 permutations of
--enable-thread-safety --with-krb5 --with-pam -with-openssl
if possible, since those potentially interact in libpq. The
--with-tcl --with-perl --with-python switches are probably pretty
independent of these, but we should have one or two buildfarm machines
trying each language if possible. Other switches that should be getting
used by some but not all machines:
--enable-integer-datetimes
--enable-nls
--without-readline (just to make sure it builds)
--without-zlib (ditto)
Finally, while I think most of the platforms should use --enable-debug
and --enable-cassert to aid in tracking down problems, there should be
one machine building without these, just to catch silly mistakes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-12-03 21:02:52 | Re: Error handling in plperl and pltcl |
Previous Message | Peter Eisentraut | 2004-12-03 20:37:42 | Re: Buildfarm coverage (was Re: OK, ready for RC1 or Beta6) |