From: Alan W. Irwin <irwin@be...> - 2009-08-25 15:52:31
I am currently working on a new test infrastructure for the core build which
will leave the current ctest infrastructure alone, but which instead adds
equivalent targets that can be run with make (or nmake). The point of this
new test infrastructure is to have proper dependencies (unlike ctest) and
also to be able to run tests in parallel (again unlike ctest) which is an
advantage on a single-cpu machine (since these tests necessarily involve
lots of i/o, one task can grab the cpu while others are waiting for their
i/o to complete) and a huge advantage on multiple-cpu machines.
I have been making quick progress this week because most of the test
elements were already in place for the common CMake code that is also used
for the install-tree tests. All the changes I am making to that common code
are to distinguish locations in the build-tree and installed examples tree
(which are set depending on the CORE_BUILD variable), and to make the
dependencies more complete (which also simultaneously improves the existing
installed examples tests).
Here is what I can do now.
With _nothing_ built in the build-tree, and if cmake has been configured
with BUILD_TEST=ON, I can run
where language is ada, c, cxx, d, f77, or f95. The above command generates
just the minimum parts of the build (bindings and examples builds) required
to do the test (which just runs plplot-test.sh for the language front-end
and the psc device).
I also have implemented a target test_compare_sh which simply runs
test_diff.sh with no dependencies. So the command
make -j4 test_c_psc test_f77_psc test_f95_psc test_compare_psc
will generate our standard PostScript and stdout difference report just for
f77 and f95 versus c, just like the commands
make -j4 all
ctest -R '(examples_c$|examples_f77|examples_f95|examples_compare)'
do now. However, for the reasons noted before the new core-build test
method is _much_ faster on my 2-cpu machine than the ctest method for doing
You probably noted that I have only referred to a subset of our languages
above. That is because there are still some dependency issues to work out
for java, lua, octave, etc. I won't commit the new test infrastructure
until it is matured a bit more, but that is happening rapidly so there is a
good chance I will be able to commit this by tomorrow or Thursday in time
for you to have a good chance to play with it before the release (this
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project