[Dune-devel] Introduction of dune_add_test

[Dominic Kempf]

Dear dune developers,

as talked about on the Dune developer meeting, I have introduced a function
dune_add_test, that handles tests in the Dune context. I have also ported
all tests in the Dune core modules. After testing on some machines, I
merged those changes into master. The interface is documented in the Sphinx
docu, but I would like to mention it here once to make sure, everybody is
aware of it:

dune_add_test([NAME name]
              [SOURCES source1 [source2 ...]]
              [TARGET target]
              [MPI_RANKS ranks1 [ranks2 ...]]
              [COMPILE_DEFINITIONS def1 [def2 ...]]
              [LINK_LIBRARIES lib1 [lib2 ...]]
              [COMPILE_FLAGS flag1 [flag2 ...]]
              [CMD_ARGS arg1 [arg2 ...]]
              [EXPECT_FAIL]
              [EXPECT_COMPILE_FAIL]
              [SKIP_ON_77]

 )

General usage.
SOURCES specifies from which source files the test should be built. If this
is a single one, the test NAME can be decuced from it. Alternatively, an
existing TARGET may be reused. COMPILE_DEFINITIONS, LINK_LIBRARIES and
COMPILE_FLAGS may be used to modifying the addition of the executable,
although only those not part of add_dune_all_flags have to be specified.
CMD_ARGS specifies command line arguments for the test execution.
EXPECT_FAIL, EXPECT_COMPILE_FAIL and SKIP_ON_77 reimplement our autotools
testing tools.

Concerning parallel testing:
MPI_RANKS specifies a list of core numbers, that the test should be
executed with. The tests with more than one core get "-mpi-n" appended to
their name. As talked about the user may give an upperbound through
DUNE_MAX_TEST_CORES, which defaults to 2. Executing a parallel test with m
jobs interacts with concurrent test execution through "ctest -jn" in the
following way:
* There is no checking that a test with m>n is discarded. This is
implemented through DUNE_MAX_TEST_CORES.Y
* ctest knows however how many processors each test needs and _only_
exceeds n cores, if a test with m>n exists.
I think this is perfectly fine, as with proper usage of the two mechanisms
(DUNE_MAX_TEST_CORES and ctest -j), cmake can aim for a good schedule while
guaranteeing the upperbound.

Transition phase:
I have disabled the standard add_test command to force people in switching
to dune_add_test. This also affects all downstream modules. There is
however the possilibilty to (temporarily, of course :D) reenable it by
setting REENABLE_ADD_TEST through the opts file or in the toplevel
CMakeLists.txt file of a project before including the DuneMacros!

If you have further questions, please ask (or consult the docs :D)
Once all your feedback is incorporated, I will write a similar mail to the
other Dune list.

Best,
Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20151023/a274699e/attachment.htm>