For multicore machines, whenever running the testsuite in parallel, it
makes sense to start the longer-running tests earlier, to make better
use of the CPU parallelism (in particular, to minimize the possibility
that the test harness will be left stuck to wait a single tests to
finish, thus leaving all cores but one idle).
In the previous commit '
v1.11b-129-g1690aca', we started defining the
automake $(TESTS) through a call to the $(wildcard) function. This has
many positive effects, but also the drawback that the tests are now
ordered randomly, so that there is an unpredictable possibility that
some long-running will be executed late, which is bad in light of what
explained above.
But luckily, we can be still able to ensure longer tests are run early,
by using a simple trick (which relies on those very GNU make features
that the parallel testsuite harness has only recently learned to grasp).
* Makefile.am (long_running_TESTS, all_TESTS): New variables.
(TESTS): Redefine in function of them, in a way that ensures the tests
in $(long_running_TESTS) are run first.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
# All tests, both hand-written and autogenerated.
# IMPORTANT: This assumes that the autogenerated tests are placed
# in the $(srcdir) as well!
-TESTS = \
+all_TESTS = \
$(wildcard $(srcdir)/t/*.sh) \
$(wildcard $(srcdir)/t/*.tap) \
$(wildcard $(srcdir)/t/pm/*.pl)
+# This is to ensure longer-running tests will be run earlier, which is
+# useful when running the testsuite in parallel on multicore machines.
+# Here too we assume that the autogenerated tests are placed in $(srcdir).
+long_running_TESTS = \
+ $(srcdir)/t/add-missing.tap \
+ $(srcdir)/t/instspc.tap \
+ $(wildcard $(srcdir)/t/depcomp-*.tap) \
+ $(wildcard $(srcdir)/t/*libtool*.sh) \
+ $(wildcard $(srcdir)/t/lt*.sh) \
+ $(wildcard $(srcdir)/t/remake*.sh)
+
+TESTS = \
+ $(long_running_TESTS) \
+ $(filter-out $(long_running_TESTS), $(all_TESTS))
+
EXTRA_DIST += $(TESTS)
# FIXME: this "expected failures" are in truth an hack used to