<div dir="ltr"><div><div>Dear dune developers,<br><br></div>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:<br><br><pre>dune_add_test([NAME name]<br>              [SOURCES source1 [source2 ...]]<br>              [TARGET target]<br>              [MPI_RANKS ranks1 [ranks2 ...]]
              [COMPILE_DEFINITIONS def1 [def2 ...]]
              [LINK_LIBRARIES lib1 [lib2 ...]]
              [COMPILE_FLAGS flag1 [flag2 ...]]
              [CMD_ARGS arg1 [arg2 ...]]
              [EXPECT_FAIL]<br>              [EXPECT_COMPILE_FAIL]<br>              [SKIP_ON_77]<br></pre><pre> )<br><br></pre>General usage.<br>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. <br></div>CMD_ARGS specifies command line arguments for the test execution. EXPECT_FAIL, EXPECT_COMPILE_FAIL and SKIP_ON_77 reimplement our autotools testing tools.<br><div><br>Concerning parallel testing:<br>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:<br></div><div>* There is no checking that a test with m>n is discarded. This is implemented through DUNE_MAX_TEST_CORES.Y</div><div>* ctest knows however how many processors each test needs and _only_ exceeds n cores, if a test with m>n exists.<br></div><div>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.<br><br></div><div>Transition phase:<br></div><div>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!<br><br></div><div>If you have further questions, please ask (or consult the docs :D)<br></div><div>Once all your feedback is incorporated, I will write a similar mail to the other Dune list.<br><br></div><div>Best,<br></div><div>Dominic<br></div></div>