Andrew Dunstan wrote:
> For several reasons. It's not simply a matter of running that
> command. You also have to bundle up the various log files. Also, if
> all we do is "check-world" and it fails that fact gives us
> relatively little information, whereas if it passes "make check" but
> fails "make -C contrib check" we'll have more information. So I'm
> not terribly excited about combining steps too much.
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.
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?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
