On 03/27/2014 01:09 PM, Tom Lane wrote:
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
Note that "make check" in contrib is substantially slower than "make
installcheck" --- it creates a temporary installation for each contrib
module. If we make buildfarm run installcheck for all modules, that
might be a problem for some animals. Would it be possible to have a
target that runs "make installcheck" for most modules and "make check"
only for those that need the separate installation? Maybe we can have a
file listing modules that don't support installcheck, for instance, and
then use $(filter) and $(filter-out) to produce appropriate "$(MAKE) -C"
loops.
This seems like a good idea to me; the slower animals will be putting lots
of cycles into pretty-much-useless "make check" builds if we don't.
Rather than a separate file, though, I think a distinct target in
contrib/Makefile would be the best mechanism for keeping the list of
modules that lack installcheck support. Perhaps "make special-check"
or some name along that line?
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Should we consider redoing that stuff in a way that allows both MSVC and
make-based systems to run those tests?
Agreed, but I'm not volunteering to fix that one ;-)
I've been kind of hoping that someone would step up on both these items,
but the trail seems to have gone cold.
I'm going to put out the new buildfarm release with the new module to
run test_decoding check. But of course It won't have MSVC support.
These can go on my long TOO list unless someone else gets there first.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
