automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: split check target into check and test targets


From: Ralf Wildenhues
Subject: Re: split check target into check and test targets
Date: Wed, 24 Feb 2010 20:49:26 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

* John Calcote wrote on Wed, Feb 24, 2010 at 07:17:08PM CET:
> On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:
> >On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
> >>I attempted to split the "make check" target into "make check" (build
[...]
> >http://www.opensubscriber.com/message/address@hidden/2136673.html
> 
> Additionally, if I want to build a particular check program (perhaps
> as I'm working out the compiler errors, but before I'm ready to
> actually run the tests), I just type "make <check-program-name>"
> from that directory. Alexander's solution is great, though. I'm
> going to use that one myself.

Actually.  I think I should write some more on this, and recommend y'all
rethink.  :-)

Dunno if you've heard of the parallel-tests option (enabling a newer
testsuite driver), but if you haven't, then read
<http://www.gnu.org/software/automake/manual/html_node/Simple-Tests-using-parallel_002dtests.html>

It allows to run tests in parallel (hence the name), but it also allows
interleaving of test program building and test running (a feature that
was IIRC the main motivation for Akim to develop this driver).  It also
allows you to sort of rerun only tests that are out of date (once you
have formulated dependencies for not only test programs, but also test
results).  The way to get interleaved test program building and
execution is to use EXTRA_PROGRAMS instead of check_PROGRAMS (see the
manual), which is nice if you have only a couple of those that need
updating, and building is not a lot faster/slower than test execution.

One other note I think is in place is that one can change check_PROGRAMS
to noinst_PROGRAMS to have them built with 'make all' already (gnulib
encourages this, for example, in order to see build failures at 'all'
time already.  This sort of goes in the other direction, away from
"rebuild as lazily as possible, for more parallelism" but can be very
useful as well (and with lots of test programs, allows a lot of
parallelism too).

Hope that helps.  If you have any questions feel free to ask.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]