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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
