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"

Also, there's the business.  The way it essentially
duplicates pg_upgrade/ 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      
PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to