1# @HEADER 2# ************************************************************************ 3# 4# TriBITS: Tribal Build, Integrate, and Test System 5# Copyright 2013 Sandia Corporation 6# 7# Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, 8# the U.S. Government retains certain rights in this software. 9# 10# Redistribution and use in source and binary forms, with or without 11# modification, are permitted provided that the following conditions are 12# met: 13# 14# 1. Redistributions of source code must retain the above copyright 15# notice, this list of conditions and the following disclaimer. 16# 17# 2. Redistributions in binary form must reproduce the above copyright 18# notice, this list of conditions and the following disclaimer in the 19# documentation and/or other materials provided with the distribution. 20# 21# 3. Neither the name of the Corporation nor the names of the 22# contributors may be used to endorse or promote products derived from 23# this software without specific prior written permission. 24# 25# THIS SOFTWARE IS PROVIDED BY SANDIA CORPORATION "AS IS" AND ANY 26# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 27# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 28# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SANDIA CORPORATION OR THE 29# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 30# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 31# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 32# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 33# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 34# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 35# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 36# 37# ************************************************************************ 38# @HEADER 39 40INCLUDE(TribitsAddTestHelpers) 41 42 43# 44# @FUNCTION: TRIBITS_ADD_TEST() 45# 46# Add a test or a set of tests for a single executable or command using CTest 47# ``ADD_TEST()``. 48# 49# Usage:: 50# 51# TRIBITS_ADD_TEST( 52# <exeRootName> [NOEXEPREFIX] [NOEXESUFFIX] 53# [NAME <testName> | NAME_POSTFIX <testNamePostfix>] 54# [DIRECTORY <directory>] 55# [ADD_DIR_TO_NAME] 56# [RUN_SERIAL] 57# [ARGS "<arg0> <arg1> ..." "<arg2> <arg3> ..." ... 58# | POSTFIX_AND_ARGS_0 <postfix0> <arg0> <arg1> ... 59# POSTFIX_AND_ARGS_1 ... ] 60# [COMM [serial] [mpi]] 61# [NUM_MPI_PROCS <numMpiProcs>] 62# [NUM_TOTAL_CORES_USED <numTotalCoresUsed>] 63# [CATEGORIES <category0> <category1> ...] 64# [HOST <host0> <host1> ...] 65# [XHOST <host0> <host1> ...] 66# [HOSTTYPE <hosttype0> <hosttype1> ...] 67# [XHOSTTYPE <hosttype0> <hosttype1> ...] 68# [EXCLUDE_IF_NOT_TRUE <varname0> <varname1> ...] 69# [DISABLED <messageWhyDisabled>] 70# [STANDARD_PASS_OUTPUT 71# | PASS_REGULAR_EXPRESSION "<regex0>;<regex1>;..."] 72# [FAIL_REGULAR_EXPRESSION "<regex0>;<regex1>;..."] 73# [WILL_FAIL] 74# [ENVIRONMENT <var0>=<value0> <var1>=<value1> ...] 75# [TIMEOUT <maxSeconds>] 76# [ADDED_TESTS_NAMES_OUT <testsNames>] 77# ) 78# 79# The tests are only added if tests are enabled for the SE package 80# (i.e. `${PACKAGE_NAME}_ENABLE_TESTS`_) or the parent package (if this is a 81# subpackage) (i.e. ``${PARENT_PACKAGE_NAME}_ENABLE_TESTS``). (NOTE: A more 82# efficient way to optionally enable tests is to put them in a ``test/`` 83# subdir and then include that subdir with `TRIBITS_ADD_TEST_DIRECTORIES()`_.) 84# 85# *Sections:* 86# 87# * `Formal Arguments (TRIBITS_ADD_TEST())`_ 88# * `Determining the Executable or Command to Run (TRIBITS_ADD_TEST())`_ 89# * `Determining the Full Test Name (TRIBITS_ADD_TEST())`_ 90# * `Adding Multiple Tests (TRIBITS_ADD_TEST())`_ 91# * `Determining Pass/Fail (TRIBITS_ADD_TEST())`_ 92# * `Setting additional test properties (TRIBITS_ADD_TEST())`_ 93# * `Running multiple tests at the same time (TRIBITS_ADD_TEST())`_ 94# * `Setting timeouts for tests (TRIBITS_ADD_TEST())`_ 95# * `Debugging and Examining Test Generation (TRIBITS_ADD_TEST())`_ 96# * `Disabling Tests Externally (TRIBITS_ADD_TEST())`_ 97# * `Adding extra commandline arguments externally (TRIBITS_ADD_TEST())`_ 98# 99# .. _Formal Arguments (TRIBITS_ADD_TEST()): 100# 101# **Formal Arguments (TRIBITS_ADD_TEST())** 102# 103# ``<exeRootName>`` 104# 105# The name of the executable or path to the executable to run for the test 106# (see `Determining the Executable or Command to Run 107# (TRIBITS_ADD_TEST())`_). This name is also the default root name for 108# the test (see `Determining the Full Test Name (TRIBITS_ADD_TEST())`_). 109# 110# ``NOEXEPREFIX`` 111# 112# If specified, then the prefix ``${PACKAGE_NAME}_`` is assumed **not** to 113# be prepended to ``<exeRootName>`` (see `Determining the Executable or 114# Command to Run (TRIBITS_ADD_TEST())`_). 115# 116# ``NOEXESUFFIX`` 117# 118# If specified, then the postfix 119# ``${${PROJECT_NAME}_CMAKE_EXECUTABLE_SUFFIX}`` is assumed **not** to be 120# post-pended to ``<exeRootName>`` (except on Windows platforms, see 121# `Determining the Executable or Command to Run (TRIBITS_ADD_TEST())`_). 122# 123# ``NAME <testRootName>`` 124# 125# If specified, gives the root name of the test. If not specified, then 126# ``<testRootName>`` is taken to be ``<exeRootName>``. The actual test 127# name passed to ``ADD_TEST()`` will always be prefixed as 128# ``${PACKAGE_NAME}_<testRootName>``. The main purpose of this argument 129# is to allow multiple tests to be defined for the same executable. CTest 130# requires all test names to be globally unique in a single project. See 131# `Determining the Full Test Name (TRIBITS_ADD_TEST())`_. 132# 133# ``NAME_POSTFIX <testNamePostfix>`` 134# 135# If specified, gives a postfix that will be added to the standard test 136# name based on ``<exeRootName>`` (appended as ``_<NAME_POSTFIX>``). If 137# the ``NAME <testRootName>`` argument is given, this argument is ignored. 138# See `Determining the Full Test Name (TRIBITS_ADD_TEST())`_. 139# 140# ``DIRECTORY <dir>`` 141# 142# If specified, then the executable is assumed to be in the directory 143# given by ``<dir>``. The directory ``<dir>`` can either be a relative or 144# absolute path. If not specified, the executable is assumed to be in the 145# current binary directory ``${CMAKE_CURRENT_BINARY_DIR}``. See 146# `Determining the Executable or Command to Run (TRIBITS_ADD_TEST())`_. 147# 148# ``ADD_DIR_TO_NAME`` 149# 150# If specified, then the directory name that this test resides in will be 151# added into the name of the test after the package name is added and 152# before the root test name (see `Determining the Full Test Name 153# (TRIBITS_ADD_TEST())`_). The directory name will have the package's 154# base directory stripped off so only the unique part of the test 155# directory will be used. All directory separators ``"/"`` will be 156# changed into underscores ``"_"``. 157# 158# ``RUN_SERIAL`` 159# 160# If specified then no other tests will be allowed to run while this test 161# is running. This is useful for devices (like CUDA GPUs) that require 162# exclusive access for processes/threads. This just sets the CTest test 163# property ``RUN_SERIAL`` using the built-in CMake function 164# ``SET_TESTS_PROPERTIES()``. 165# 166# ``ARGS "<arg0> <arg1> ..." "<arg2> <arg3> ..." ...`` 167# 168# If specified, then a set of arguments can be passed in quotes. If 169# multiple groups of arguments are passed in different quoted clusters of 170# arguments then a different test will be added for each set of arguments. 171# In this way, many different tests can be added for a single executable 172# in a single call to this function. Each of these separate tests will be 173# named ``<fullTestName>_xy`` where ``xy`` = ``00``, ``01``, ``02``, and so 174# on. **WARNING:** When defining multiple tests it is preferred to use the 175# ``POSTFIX_AND_ARGS_<IDX>`` form instead. **WARNING:** Multiple 176# arguments passed to a single test invocation must be quoted or multiple 177# tests taking single arguments will be created instead! See `Adding 178# Multiple Tests (TRIBITS_ADD_TEST())`_ for more details and examples. 179# 180# ``POSTFIX_AND_ARGS_<IDX> <postfix> <arg0> <arg1> ...`` 181# 182# If specified, gives a sequence of sets of test postfix names and 183# arguments lists for different tests (up to ``POSTFIX_AND_ARGS_19``). 184# For example, a set of three different tests with argument lists can be 185# specified as:: 186# 187# POSTIFX_AND_ARGS_0 postfix0 --arg1 --arg2="dummy" 188# POSTIFX_AND_ARGS_1 postfix1 --arg2="fly" 189# POSTIFX_AND_ARGS_2 postfix2 --arg2="bags" 190# 191# This will create three different test cases with the postfix names 192# ``postfix0``, ``postfix1``, and ``postfix2``. The indexes must be 193# consecutive starting a ``0`` and going up to (currently) ``19``. The 194# main advantages of using these arguments instead of just ``ARGS`` are 195# that one can give a meaningful name to each test case and one can 196# specify multiple arguments without having to quote them and one can 197# allow long argument lists to span multiple lines. See `Adding Multiple 198# Tests (TRIBITS_ADD_TEST())`_ for more details and examples. 199# 200# ``COMM [serial] [mpi]`` 201# 202# If specified, determines if the test will be added in serial and/or MPI 203# mode. If the ``COMM`` argument is missing, the test will be added in 204# both serial and MPI builds of the code. That is if ``COMM mpi`` is 205# passed in, then the test will **not** be added if 206# ``TPL_ENABLE_MPI=OFF``. Likewise, if ``COMM serial`` is passed in, then 207# the test will **not** be added if ``TPL_ENABLE_MPI=ON``. If ``COMM 208# serial mpi`` or ``COMM mpi serial`` is passed in, then the value of 209# ``TPL_ENABLE_MPI`` does not determine if the test is added or not. 210# 211# ``NUM_MPI_PROCS <numMpiProcs>`` 212# 213# If specified, gives the number of MPI processes used to run the test 214# with the MPI exec program ``${MPI_EXEC}``. If ``<numMpiProcs>`` is greater 215# than ``${MPI_EXEC_MAX_NUMPROCS}`` then the test will be excluded. If 216# not specified, then the default number of processes for an MPI build 217# (i.e. ``TPL_ENABLE_MPI=ON``) will be ``${MPI_EXEC_DEFAULT_NUMPROCS}``. 218# For serial builds (i.e. ``TPL_ENABLE_MPI=OFF``), this argument is 219# ignored. This will also be set as the built-in test property 220# ``PROCESSORS`` if ``NUM_TOTAL_CORES_USED`` is not specified. 221# 222# ``NUM_TOTAL_CORES_USED <numTotalCoresUsed>`` 223# 224# If specified, gives the total number of processes or cores that is 225# reported to CTest as the built-in CTest ``PROCESSORS`` property. If 226# this is not specified, then ``PROCESSORS`` is specified by the argument 227# ``NUM_MPI_PROCS <numMpiProcs>``. This argument is used for test 228# scripts/executables that use more cores than MPI processes 229# (i.e. ``<numMpiProcs>``) and its only purpose is to inform CTest and 230# TriBITS of the maximum number of processes or cores that are used by the 231# underlying test executable/script. When specified, if 232# ``<numTotalCoresUsed>`` is greater than ``${MPI_EXEC_MAX_NUMPROCS}``, 233# then the test will not be added. Otherwise, the CTest property 234# ``PROCESSORS`` is set to ``<numTotalCoresUsed>`` so that CTest knows how 235# to best schedule the test w.r.t. other tests on a given number of 236# available processes. See `Running multiple tests at the same time 237# (TRIBITS_ADD_TEST())`_. 238# 239# ``CATEGORIES <category0> <category1> ...`` 240# 241# If specified, gives the specific categories of the test. Valid test 242# categories include ``BASIC``, ``CONTINUOUS``, ``NIGHTLY``, ``HEAVY`` 243# and ``PERFORMANCE``. If not specified, the default category is 244# ``BASIC``. When the test category does not match 245# ``${PROJECT_NAME}_TEST_CATEGORIES``, then the test is **not** added. 246# When ``CATEGORIES`` contains ``BASIC`` it will match 247# ``${PROJECT_NAME}_TEST_CATEGORIES`` equal to ``CONTINUOUS``, 248# ``NIGHTLY``, and ``HEAVY``. When ``CATEGORIES`` contains 249# ``CONTINUOUS`` it will match ``${PROJECT_NAME}_TEST_CATEGORIES`` equal 250# to ``CONTINUOUS``, ``NIGHTLY``, and ``HEAVY``. When ``CATEGORIES`` 251# contains ``NIGHTLY`` it will match ``${PROJECT_NAME}_TEST_CATEGORIES`` 252# equal to ``NIGHTLY`` and ``HEAVY``. When ``CATEGORIES`` contains 253# ``PERFORMANCE`` it will match 254# ``${PROJECT_NAME}_TEST_CATEGORIES=PERFORMANCE`` only. 255# 256# ``HOST <host0> <host1> ...`` 257# 258# If specified, gives a list of hostnames where the test will be included. 259# The current hostname is determined by the built-in CMake command 260# ``SITE_NAME(${PROJECT_NAME}_HOSTNAME)``. On Linux/Unix systems, this is 261# typically the value returned by ``uname -n``. If this list is given, 262# the value of ``${${PROJECT_NAME}_HOSTNAME}`` must equal one of the 263# listed host names ``<hosti>`` or test will **not** be added. The value 264# of ``${PROJECT_NAME}_HOSTNAME`` gets printed out in the TriBITS cmake 265# output under the section ``Probing the environment`` (see `Full 266# Processing of TriBITS Project Files`_). 267# 268# ``XHOST <host0> <host1> ...`` 269# 270# If specified, gives a list of hostnames (see ``HOST`` argument) on which 271# the test will **not** be added. This check is performed after the check 272# for the hostnames in the ``HOST`` list if it should exist. Therefore, 273# this exclusion list overrides the ``HOST`` inclusion list. 274# 275# ``HOSTTYPE <hosttype0> <hosttype1> ...`` 276# 277# If specified, gives the names of the host system type (given by the 278# built-in CMake cache variable ``CMAKE_HOST_SYSTEM_NAME`` which is 279# printed in the TriBITS cmake configure output in the section ``Probing 280# the environment``) for which the test is allowed to be added. If 281# ``HOSTTYPE`` is specified and ``CMAKE_HOST_SYSTEM_NAME`` is not equal to 282# one of the values of ``<hosttypei>``, then the test will **not** be 283# added. Typical host system type names include ``Linux``, ``Darwin``, 284# ``Windows``, etc. 285# 286# ``XHOSTTYPE <hosttype0> <hosttype1> ...`` 287# 288# If specified, gives the names of the host system type (see the 289# ``HOSTTYPE`` argument above) for which **not** to include the test on. 290# This check is performed after the check for the host system names in the 291# ``HOSTTYPE`` list if it should exist. Therefore, this exclusion list 292# overrides the ``HOSTTYPE`` inclusion list. 293# 294# ``EXCLUDE_IF_NOT_TRUE <varname0> <varname1> ...`` 295# 296# If specified, gives the names of CMake variables that must evaluate to 297# true, or the test will not be added. 298# 299# ``DISABLED <messageWhyDisabled>`` 300# 301# If ``<messageWhyDisabled>`` is non-empty and does not evaluate to FALSE, 302# then the test will be added by ``add_test()`` (so CTest will see it) but 303# the ctest test property ``DISABLED`` will be set. Therefore, CTest will 304# not run the test and will instead list it as "Not Run" when tests are 305# run locally and when submitting test results to CDash (with test details 306# "Not Run (Disabled)"). Also, the message ``<messageWhyDisabled>`` will 307# be printed to STDOUT by cmake after the line stating the test was added 308# when ``${PROJECT_NAME}_TRACE_ADD_TEST=ON`` is set. If 309# ``<messageWhyDisabled>`` evaluates to FALSE in CMake (e.g. "FALSE", 310# "false", "NO", "no", "0", "", etc.), then the ``DISABLED`` property will 311# not be set. This property can also be set with the CMake cache var ``-D 312# <fullTestName>_SET_DISABLED_AND_MSG="<msgSetByVar>"`` and in fact that 313# var will override the value of ``<messageWhyDisabled>`` passed in here 314# (if ``<msgSetByVar>`` is non-empty). This allows a user to enable tests 315# that are disabled in the CMakeList.txt files using this input. 316# 317# ``STANDARD_PASS_OUTPUT`` 318# 319# If specified, then the standard test output string ``End Result: TEST 320# PASSED`` is grepped in the test stdout for to determine success. This 321# is needed for MPI tests on some platforms since the return value from 322# MPI executables is unreliable. This is set using the built-in CTest 323# property ``PASS_REGULAR_EXPRESSION``. 324# 325# ``PASS_REGULAR_EXPRESSION "<regex0>;<regex1>;..."`` 326# 327# If specified, then the test will be assumed to pass only if one of the 328# regular expressions ``<regex0>``, ``<regex1>`` etc. match the output 329# send to stdout. Otherwise, the test will fail. This is set using the 330# built-in CTest property ``PASS_REGULAR_EXPRESSION``. Consult standard 331# CMake documentation for full behavior. TIPS: Replace ';' with '[;]' or 332# CMake will interpretet this as a array eleemnt boundary. To match '.', 333# use '[.]'. 334# 335# ``FAIL_REGULAR_EXPRESSION "<regex0>;<regex1>;..."`` 336# 337# If specified, then a test will be assumed to fail if one of the regular 338# expressions ``<regex0>``, ``<regex1>`` etc. match the output send to 339# stdout. Otherwise, the test will pass. This is set using the built-in 340# CTest property ``FAIL_REGULAR_EXPRESSION``. Consult standard CMake 341# documentation for full behavior (and see above tips for 342# ``PASS_REGULAR_EXPRESSION``). 343# 344# ``WILL_FAIL`` 345# 346# If passed in, then the pass/fail criteria will be inverted. This is set 347# using the built-in CTest property ``WILL_FAIL``. Consult standard CMake 348# documentation for full behavior. 349# 350# ``ENVIRONMENT <var0>=<value0> <var1>=<value1> ...`` 351# 352# If passed in, the listed environment variables will be set before 353# calling the test. This is set using the built-in CTest property 354# ``ENVIRONMENT``. 355# 356# ``TIMEOUT <maxSeconds>`` 357# 358# If passed in, gives maximum number of seconds the test will be allowed 359# to run before being timed-out and killed. This sets the CTest property 360# ``TIMEOUT``. The value ``<maxSeconds>`` will be scaled by the value of 361# `${PROJECT_NAME}_SCALE_TEST_TIMEOUT`_. See `Setting timeouts for tests 362# (TRIBITS_ADD_TEST())`_ for more details. 363# 364# **WARNING:** Rather than just increasing the timeout for an expensive 365# test, please try to either make the test run faster or relegate the test 366# to being run less often (i.e. set ``CATEGORIES NIGHTLY`` or even 367# ``HEAVY`` for extremely expensive tests). Expensive tests are one of 368# the worse forms of technical debt that a project can have! 369# 370# ``ADDED_TESTS_NAMES_OUT <testsNames>`` 371# 372# If specified, then on output the variable ``<testsNames>`` will be set 373# with the name(S) of the tests passed to ``ADD_TEST()``. If more than 374# one test is added, then this will be a list of test names. Having this 375# name allows the calling ``CMakeLists.txt`` file access and set 376# additional test properties (see `Setting additional test properties 377# (TRIBITS_ADD_TEST())`_). 378# 379# In the end, this function just calls the built-in CMake commands 380# ``ADD_TEST(${TEST_NAME} ...)`` and ``SET_TESTS_PROPERTIES(${TEST_NAME} 381# ...)`` to set up a executable process for ``ctest`` to run, determine 382# pass/fail criteria, and set some other test properties. Therefore, this 383# wrapper function does not provide any fundamentally new features that are 384# not already available in the basic usage if CMake/CTest. However, this 385# wrapper function takes care of many of the details and boiler-plate CMake 386# code that it takes to add such a test (or tests) and enforces consistency 387# across a large project for how tests are defined, run, and named (to avoid 388# test name clashes). 389# 390# If more flexibility or control is needed when defining tests, then the 391# function `TRIBITS_ADD_ADVANCED_TEST()`_ should be used instead. 392# 393# In the following subsections, more details on how tests are defined and run 394# is given. 395# 396# .. _Determining the Executable or Command to Run (TRIBITS_ADD_TEST()): 397# 398# **Determining the Executable or Command to Run (TRIBITS_ADD_TEST())** 399# 400# This function is primarily designed to make it easy to run tests for 401# executables built using the function `TRIBITS_ADD_EXECUTABLE()`_. To set up 402# tests to run arbitrary executables, see below. 403# 404# By default, the executable to run is determined by first getting the 405# executable name which by default is assumed to be:: 406# 407# <fullExeName> = 408# ${PACKAGE_NAME}_<exeRootName>${${PROJECT_NAME}_CMAKE_EXECUTABLE_SUFFIX} 409# 410# which is (by no coincidence) identical to how it is selected in 411# `TRIBITS_ADD_EXECUTABLE()`_ (see `Executable and Target Name 412# (TRIBITS_ADD_EXECUTABLE())`_). This name can be altered by passing in 413# ``NOEXEPREFIX``, ``NOEXESUFFIX``, and ``ADD_DIR_TO_NAME`` as described in 414# `Executable and Target Name (TRIBITS_ADD_EXECUTABLE())`_. 415# 416# By default, this executable is assumed to be in the current CMake binary 417# directory ``${CMAKE_CURRENT_BINARY_DIR}`` but the directory location can be 418# changed using the ``DIRECTORY <dir>`` argument. 419# 420# If an arbitrary executable is to be run (i.e. not build inside of the 421# project), then pass in ``NOEXEPREFIX`` and ``NOEXESUFFIX`` and set 422# ``<exeRootName>`` to the relative or absolute path of the executable to be 423# run. If ``<exeRootName>`` is not an absolute path, then 424# ``${CMAKE_CURRENT_BINARY_DIR}/<exeRootName>`` is set as the executable to 425# run in this case. 426# 427# NOTE: On native Windows platforms, the ``NOEXESUFFIX`` will still allow 428# CTest to run executables that have the ``*.exe`` suffix. 429# 430# Whatever executable path is specified using this logic, if the executable is 431# not found, then when ``ctest`` goes to run the test, it will mark it as 432# ``NOT RUN``. 433# 434# .. _Determining the Full Test Name (TRIBITS_ADD_TEST()): 435# 436# **Determining the Full Test Name (TRIBITS_ADD_TEST())** 437# 438# By default, the base test name is selected to be:: 439# 440# <fullTestName> = ${PACKAGE_NAME}_<exeRootName> 441# 442# If ``NAME <testRootName>`` is passed in, then ``<testRootName>`` is used 443# instead of ``<exeRootName>`` above. 444# 445# If ``NAME_POSTFIX <testNamePostfix>`` is passed in, then the base test name 446# is selected to be:: 447# 448# <fullTestName> = ${PACKAGE_NAME}_<exeRootName>_<testNamePostfix> 449# 450# If ``ADD_DIR_TO_NAME`` is passed in, then the directory name relative to the 451# package base directory is added to the name as well to help disambiguate the 452# test name (see the above). 453# 454# Let the test name determined as described above be ``<fullTestName>``. If 455# no arguments or only a single set of arguments are passed in through 456# ``ARGS``, then this is the test name actually passed in to ``ADD_TEST()``. 457# If multiple tests are defined, then this name becomes the base test name for 458# each of the tests (see `Adding Multiple Tests (TRIBITS_ADD_TEST())`_). 459# 460# Finally, for any test that gets defined, if MPI is enabled 461# (i.e. ``TPL_ENABLE_MPI=ON``), then the terminal suffix 462# ``_MPI_${NUM_MPI_PROCS}`` will be added to the end of the test name (even 463# for multiple tests). No such prefix is added for the serial case 464# (i.e. ``TPL_ENABLE_MPI=OFF``). 465# 466# .. _Adding Multiple Tests (TRIBITS_ADD_TEST()): 467# 468# **Adding Multiple Tests (TRIBITS_ADD_TEST())** 469# 470# Using this function, one can add executable arguments and can even add 471# multiple tests in one of two ways. One can either pass in one or more 472# **quoted** clusters of arguments using:: 473# 474# ARGS "<arg0> <arg1> ..." "<arg2> <arg3> ..." ... 475# 476# or can pass in an explicit test name postfix and arguments with:: 477# 478# POSTFIX_AND_ARGS_0 <postfix0> <arg0> <arg1> ... 479# POSTFIX_AND_ARGS_1 <postfix1> <arg2> ... 480# ... 481# 482# If only one short set of arguments needs to be passed in, then passing:: 483# 484# ARGS "<arg0> <arg1>" 485# 486# may be preferable since it will not add any postfix name to the test. To 487# add more than one test case using ``ARGS``, one will use more than one 488# quoted set of arguments such as with:: 489# 490# ARGS "<arg0> <arg1>" "<arg2> <arg2>" 491# 492# which creates 2 tests with the names ``<fullTestName>_00`` passing 493# arguments ``"<arg0> <arg1>"`` and ``<fullTestName>_01`` passing arguments 494# ``"<arg2> <arg3>"``. However, when passing multiple sets of arguments it is 495# preferable to **not** use ``ARGS`` but instead use:: 496# 497# POSTFIX_AND_ARGS_0 test_a <arg0> <arg1> 498# POSTFIX_AND_ARGS_1 test_b <arg2> <arg2> 499# 500# which also creates the same 2 tests but now with the improved names 501# ``<fullTestName>_test_a`` passing arguments ``"<arg0> <arg1>"`` and 502# ``<fullTestName>_test_b`` passing arguments ``"<arg2> <arg3>"``. In this way, 503# the individual tests can be given more understandable names. 504# 505# The other advantage of the ``POSTFIX_AND_ARGS_<IDX>`` form is that the 506# arguments ``<arg0>``, ``<arg1>``, ... do not need to be quoted and can 507# therefore be extended over multiple lines like:: 508# 509# POSTFIX_AND_ARGS_0 long_args --this-is-the-first-long-arg=very 510# --this-is-the-second-long-arg=verylong 511# 512# If one does not use quotes when using ``ARGS`` one will actually get more 513# than one test. For example, if one passes in:: 514# 515# ARGS --this-is-the-first-long-arg=very 516# --this-is-the-second-long-arg=verylong 517# 518# one actually gets two tests, not one test. This is a common mistake that 519# people make when using the ``ARGS`` form of passing arguments. This can't 520# be fixed or it will break backward compatibility. If this could be designed 521# fresh, the ``ARGS`` argument would only create a single test and the 522# arguments would not be quoted. 523# 524# .. _Determining Pass/Fail (TRIBITS_ADD_TEST()): 525# 526# **Determining Pass/Fail (TRIBITS_ADD_TEST())** 527# 528# The only means to determine pass/fail is to use the built-in CTest 529# properties ``PASS_REGULAR_EXPRESSION`` and ``FAIL_REGULAR_EXPRESSION`` which 530# can only grep the test's STDOUT/STDERR or to check for a 0 return value (or 531# invert these using ``WILL_FAIL``). For simple tests, that is enough. 532# However, for more complex executables, one may need to examine one or more 533# output files to determine pass/fail. Raw CMake/CTest cannot do this. In 534# this case, one should use `TRIBITS_ADD_ADVANCED_TEST()`_ instead to add the 535# test. 536# 537# .. _Setting additional test properties (TRIBITS_ADD_TEST()): 538# 539# **Setting additional test properties (TRIBITS_ADD_TEST())** 540# 541# After this function returns, any tests that get added using ``ADD_TEST()`` 542# can have additional properties set and changed using 543# ``SET_TESTS_PROPERTIES()``. Therefore, any tests properties that are not 544# directly supported and passed through this wrapper function can be set in 545# the outer ``CMakeLists.txt`` file after the call to ``TRIBITS_ADD_TEST()``. 546# 547# If tests are added, then the names of those tests will be returned in the 548# variable ``ADDED_TESTS_NAMES_OUT <testsNames>``. This can be used, for 549# example, to override the ``PROCESSORS`` property for the tests with:: 550# 551# TRIBITS_ADD_TEST( someTest ... 552# ADDED_TESTS_NAMES_OUT someTest_TEST_NAME ) 553# 554# IF (someTest_TEST_NAME) 555# SET_TESTS_PROPERTIES( ${someTest_TEST_NAME} 556# PROPERTIES ATTACHED_FILES someTest.log ) 557# ENDIF() 558# 559# where the test writes a log file ``someTest.log`` that we want to submit to 560# CDash also. 561# 562# This approach will work no matter what TriBITS names the individual test(s) 563# or whether the test(s) are added or not (depending on other arguments like 564# ``COMM``, ``XHOST``, etc.). 565# 566# The following built-in CTest test properties are set through `Formal 567# Arguments (TRIBITS_ADD_TEST())`_ or are otherwise automatically set by this 568# function and should **NOT** be overridden by direct calls to 569# ``SET_TESTS_PROPERTIES()``: ``ENVIRONMENT``, ``FAIL_REGULAR_EXPRESSION``, 570# ``LABELS``, ``PASS_REGULAR_EXPRESSION``, ``RUN_SERIAL``, ``TIMEOUT``, and 571# ``WILL_FAIL``. 572# 573# However, generally, other built-in CTest test properties can be set after 574# the test is added like show above. Examples of test properties that can be 575# set using direct calls to ``SET_TESTS_PROPERTIES()`` include 576# ``ATTACHED_FILES``, ``ATTACHED_FILES_ON_FAIL``, ``COST``, ``DEPENDS``, 577# ``MEASUREMENT``, ``RESOURCE_LOCK`` and ``WORKING_DIRECTORY``. 578# 579# For example, one can set a dependency between two tests using:: 580# 581# TRIBITS_ADD_TEST( test_a [...] 582# ADDED_TESTS_NAMES_OUT test_a_TEST_NAME ) 583# 584# TRIBITS_ADD_TEST( test_b [...] 585# ADDED_TESTS_NAMES_OUT test_z_TEST_NAME ) 586# 587# IF (test_a_TEST_NAME AND test_b_TEST_NAME) 588# SET_TESTS_PROPERTIES(${test_b_TEST_NAME} 589# PROPERTIES DEPENDS ${test_a_TEST_NAME}) 590# ENDIF() 591# 592# This ensures that test ``test_b`` will always be run after ``test_a`` if 593# both tests are run by CTest. 594# 595# .. _Running multiple tests at the same time (TRIBITS_ADD_TEST()): 596# 597# **Running multiple tests at the same time (TRIBITS_ADD_TEST())** 598# 599# By default, CTest will run as many tests defined with ``ADD_TEST()`` at same 600# time as it can according to its parallel level (e.g. ``'ctest -j<N>'`` or 601# the CTest property ``CTEST_PARALLEL_LEVEL``). For example, when raw 602# ``'ctest -j10'`` is run, CTest will run multiple tests at the same time to 603# try to make usage of 10 processors/cores. If all of the defined tests only 604# used one process (which is assumed by default except for MPI tests), then 605# CTest will run 10 tests at the same time and will launch new tests as 606# running tests finish. One can also define tests which use more than one 607# process or use more cores than the number of MPI processes. When passing in 608# ``NUM_MPI_PROCS <numMpiProcs>`` (see above), this TriBITS function will set the 609# built-in CTest property ``PROCESSORS`` to ``<numMpiProcs>`` using:: 610# 611# SET_TESTS_PROPERTIES(<fullTestName> PROPERTIES PROCESSORS <numMpiProcs>) 612# 613# This tells CTest that the defined test uses ``<numMpiProcs>`` processes and 614# CTest will use that information to not exceed the requested parallel level. 615# For example, if several ``NUM_MPI_PROCS 3`` tests are defined and CTest is 616# run with ``'ctest -j12'``, then CTest would schedule and run 4 of these 617# tests at a time (to make use of 12 processors/cores on the machine), 618# starting new tests as running tests finish, until all of the tests have been 619# run. 620# 621# There are some situations where a test will use more processes/cores than 622# specified by ``NUM_MPI_PROCS <numMpiProcs>`` such as when the underlying 623# executable fires off more processes in parallel to do processing. Also, an 624# MPI program may use threading and therefore use overall more cores than the 625# number of MPI processes. For these cases, it is critical to set 626# ``NUM_TOTAL_CORES_USED <numTotalCoresUsed>`` to tell TriBITS and CTest how 627# many cores will be used by a threaded test. This is needed to exclude the 628# test if there are too many processes/cores needed to run the test than are 629# available. Also, if the test is added, then this is needed to set the 630# built-in CTest ``PROCESSORS`` property so CTest can avoid overloading the 631# machine. For example, for test where the MPI executable running on 4 632# processes uses 10 threads per process, one would set:: 633# 634# NUM_MPI_PROCS 4 NUM_TOTAL_CORES_USED 40 635# 636# In this case, it sets the CTest ``PROCESSORS`` property as:: 637# 638# SET_TESTS_PROPERTIES(<fullTestName> PROPERTIES PROCESSORS <numTotalCoresUsed>) 639# 640# When the number of processes a test uses does not cleanly divide into the 641# requested CTest parallel level, it is not clear how CTest schedules the 642# tests (hard to find documentation on this but one could always inspect the 643# CTest source code to find out for sure). However, one boundary case that is 644# well observed is that CTest will run all defined tests regardless of the 645# size of the ``PROCESSORS`` property or the value of 646# ``CTEST_PARALLEL_LEVEL``. For example, if there are tests where 647# ``PROCESSORS`` is set to 20 but ```ctest -j10'`` is used, then CTest will 648# still run those tests (using 20 processes) but will not schedule any other 649# tests while the parallel level is exceeded. This can overload the machine 650# obviously. Therefore, always set ``MPI_EXEC_MAX_NUMPROCS`` to the maximum 651# number of cores/processes that can be comfortably run on a given machine. 652# Also note that MPI tests are very fragile to overloaded machines 653# 654# NOTE: **Never** manually override the ``PROCESSORS`` CTest property. 655# Instead, always using ``NUM_TOTAL_CORES_USED <numTotalCoresUsed>`` to set 656# this. This is important because TriBITS needs to know how many 657# processes/cores are required for test so that it can disable the test if the 658# test requires more cores/processes than a given machine can handle or to 659# exceed an imposed budget of the number processes to be used. The latter is 660# important when running multiple ``ctest -J<N>`` invocations on the same test 661# machine. 662# 663# .. _Setting timeouts for tests (TRIBITS_ADD_TEST()): 664# 665# **Setting timeouts for tests (TRIBITS_ADD_TEST())** 666# 667# By default, all tests have a default timeout (1500 seconds for most 668# projects, see `DART_TESTING_TIMEOUT`_). That means that if they hang 669# (e.g. as is common when deadlocking occurs with multi-process MPI-based 670# tests and multi-threaded tests) then each test may hang for a long time, 671# causing the overall test suite to take a long time to complete. For many 672# CMake projects, this default timeout is way too long. 673# 674# Timeouts for tests can be adjusted in a couple of ways. First, a default 675# timeout for all tests is enforced by CTest given the configured value of the 676# variable `DART_TESTING_TIMEOUT`_ (typically set by the user but set by 677# default to 1500 for most projects). This is a global timeout that applies 678# to all tests that don't otherwise have individual timeouts set using the 679# ``TIMEOUT`` CTest property (see below). The value of 680# ``DART_TESTING_TIMEOUT`` in the CMake cache on input to CMake will get 681# scaled by `${PROJECT_NAME}_SCALE_TEST_TIMEOUT`_ and the scaled value gets 682# written into the file ``DartConfiguration.tcl`` as the field ``TimeOut``. 683# The``ctest`` executable reads ``TimeOut`` from this file when it runs to 684# determine the default global timeout. The value of this default global 685# ``TimeOut`` can be overridden using the ``ctest`` argument ``--timeout 686# <seconds>`` (see `Overriding test timeouts`_). 687# 688# Alternatively, timeouts for individual tests can be set using the input 689# argument ``TIMEOUT`` (see `Formal Arguments (TRIBITS_ADD_TEST())`_ above). 690# The timeout value passed in to this function is then scaled by 691# ``${PROJECT_NAME}_SCALE_TEST_TIMEOUT`` and the scaled timeout is then set as 692# the CTest test property ``TIMEOUT``. One can observe the value of this 693# property in the CMake-generated file ``CTestTestfile.cmake`` in the current 694# build directory. Individual test timeouts set this way are not impacted by 695# the global default timeout ``DART_TESTING_TIMEOUT`` or the ``ctest`` 696# argument ``--timeout <seconds>``. 697# 698# In summary, CTest determines the timeout for any individual test as follows: 699# 700# * If the ``TIMEOUT`` CTest property in ``CTestTestfile.cmake`` for that test 701# is set, then that value is used. 702# 703# * Else if the ``ctest`` commandline option ``--timeout <seconds>`` is 704# provided, then that timeout is used. 705# 706# * Else if the property ``TimeOut`` in the base file 707# ``DartConfiguration.tcl`` is set to non-empty, then that timeout is used. 708# 709# * Else, no timeout is set and the test can run (and hang) forever until 710# manually killed by the user. 711# 712# .. _Debugging and Examining Test Generation (TRIBITS_ADD_TEST()): 713# 714# **Debugging and Examining Test Generation (TRIBITS_ADD_TEST())** 715# 716# In order to see what tests get added and if not then why, configure with 717# ``${PROJECT_NAME}_TRACE_ADD_TEST=ON``. That will print one line per show 718# that the test got added and if not then why the test was not added (i.e. due 719# to ``COMM``, ``NUM_MPI_PROCS``, ``CATEGORIES``, ``HOST``, ``XHOST``, 720# ``HOSTTYPE``, or ``XHOSTTYPE``). 721# 722# Also, CMake writes a file ``CTestTestfile.cmake`` in the current binary 723# directory which contains all of the added tests and test properties that are 724# set. This is the file that is read by ``ctest`` when it runs to determine 725# what tests to run, determine pass/fail and adjust other behavior using test 726# properties. In this file, one can see the exact ``ADD_TEST()`` and 727# ``SET_TESTS_PROPERTIES()`` commands. The is the ultimate way to debug 728# exactly what tests are getting added by this function (or if the test is 729# even being added at all). 730# 731# .. _Disabling Tests Externally (TRIBITS_ADD_TEST()): 732# 733# **Disabling Tests Externally (TRIBITS_ADD_TEST())** 734# 735# The test can be disabled externally by setting the CMake cache variable 736# ``<fullTestName>_DISABLE=TRUE``. This allows tests to be disabled on a 737# case-by-case basis by the user (for whatever reason). Here, 738# ``<fullTestName>`` must be the *exact* name that shows up in 'ctest -N' when 739# running the test. If multiple tests are added in this function through 740# multiple argument sets to ``ARGS`` or through multiple 741# ``POSTFIX_AND_ARGS_<IDX>`` arguments, then ``<fullTestName>_DISABLE=TRUE`` 742# must be set for each test individually. When a test is disabled in this 743# way, TriBITS will always print a warning to the ``cmake`` stdout at 744# configure time warning that the test is being disabled. 745# 746# .. _Adding extra commandline arguments externally (TRIBITS_ADD_TEST()): 747# 748# **Adding extra commandline arguments externally (TRIBITS_ADD_TEST())** 749# 750# One can add additional command-line arguments for any ctest test added using 751# this function. In order to do so, set the CMake cache variable:: 752# 753# SET(<fullTestName>_EXTRA_ARGS "<earg0>;<earg1>;<earg2>;..." 754# CACHE STRING "Extra args") 755# 756# in a ``*.cmake`` configure options fragment file or:: 757# 758# -D <fullTestName>_EXTRA_ARGS="<earg0>;<earg1>;<earg2>;..." 759# 760# on the CMake command-line. 761# 762# These extra command-line arguments are added after any arguments passed in 763# through ``ARGS "<oarg0> <oarg1> ..."`` or ``POSTFIX_AND_ARGS_<IDX> <oarg0> 764# <oarg1> ...``. This allows these extra arguments to override the ealier 765# arguments. 766# 767# The primary motivating use case for ``<fullTestName>_EXTRA_ARGS`` is to 768# allow one to alter how a test runs on a specific platform or build. For 769# example, this allows one to disable specific individual unit tests for a 770# GTest executable such as with:: 771# 772# SET(<fullTestName>_EXTRA_ARGS "--gtest_filter=-<unittest0>:<unittest1>:..." 773# CACHE STRING "Disable specific unit tests" ) 774# 775# For example, this would be an alternative to disabling an entire unit 776# testing executable using ``-D<fullTestName>_DISABLE=ON`` as described above. 777# 778FUNCTION(TRIBITS_ADD_TEST EXE_NAME) 779 780 IF(${PROJECT_NAME}_VERBOSE_CONFIGURE) 781 MESSAGE("") 782 MESSAGE("TRIBITS_ADD_TEST: ${EXE_NAME} ${ARGN}") 783 ENDIF() 784 785 GLOBAL_SET(TRIBITS_ADD_TEST_ADD_TEST_INPUT) 786 GLOBAL_SET(TRIBITS_SET_TEST_PROPERTIES_INPUT) 787 GLOBAL_SET(MESSAGE_WRAPPER_INPUT) 788 789 # 790 # A) Parse the input arguments 791 # 792 793 # Allow for a maximum of 20 (0 through 19) postfix and argument blocks 794 SET(MAX_NUM_POSTFIX_AND_ARGS_IDX 19) 795 796 SET(POSTFIX_AND_ARGS_LIST "") 797 FOREACH( POSTFIX_AND_ARGS_IDX RANGE ${MAX_NUM_POSTFIX_AND_ARGS_IDX}) 798 LIST( APPEND POSTFIX_AND_ARGS_LIST POSTFIX_AND_ARGS_${POSTFIX_AND_ARGS_IDX} ) 799 ENDFOREACH() 800 #PRINT_VAR(POSTFIX_AND_ARGS_LIST) 801 802 CMAKE_PARSE_ARGUMENTS( 803 #prefix 804 PARSE 805 # options 806 "NOEXEPREFIX;NOEXESUFFIX;STANDARD_PASS_OUTPUT;WILL_FAIL;ADD_DIR_TO_NAME;RUN_SERIAL" 807 #one_value_keywords 808 "DISABLED" 809 #multi_value_keywords 810"DIRECTORY;KEYWORDS;COMM;NUM_MPI_PROCS;NUM_TOTAL_CORES_USED;ARGS;${POSTFIX_AND_ARGS_LIST};NAME;NAME_POSTFIX;CATEGORIES;HOST;XHOST;HOSTTYPE;XHOSTTYPE;EXCLUDE_IF_NOT_TRUE;PASS_REGULAR_EXPRESSION;FAIL_REGULAR_EXPRESSION;TIMEOUT;ENVIRONMENT;ADDED_TESTS_NAMES_OUT" 811 ${ARGN} 812 ) 813 814 TRIBITS_CHECK_FOR_UNPARSED_ARGUMENTS() 815 816 IF (NOT "${PARSE_ARGS}" STREQUAL "") 817 LIST(LENGTH PARSE_ARGS NUM_PARSE_ARGS) 818 ELSEIF (PARSE_POSTFIX_AND_ARGS_0) 819 # We will use this list instead 820 ELSE() 821 # Niether 'ARGS' nor 'POSTFIX_AND_ARGS' was selected so just assume one 822 # empty arg 823 SET(PARSE_ARGS " ") 824 SET(NUM_PARSE_ARGS 1) 825 ENDIF() 826 827 IF (${PROJECT_NAME}_VERBOSE_CONFIGURE) 828 MESSAGE("") 829 MESSAGE("TRIBITS_ADD_TEST: EXE_NAME = ${EXE_NAME}") 830 ENDIF() 831 832 IF(PARSE_ADDED_TESTS_NAMES_OUT) 833 SET(${PARSE_ADDED_TESTS_NAMES_OUT} "" PARENT_SCOPE ) 834 ENDIF() 835 836 SET(ADDED_TESTS_NAMES_OUT) 837 838 # 839 # Get test name 840 # 841 842 # If requested create a modifier for the name that will be inserted between 843 # the package name and the given name or exe_name for the test 844 SET(DIRECTORY_NAME "") 845 IF(PARSE_ADD_DIR_TO_NAME) 846 TRIBITS_CREATE_NAME_FROM_CURRENT_SOURCE_DIRECTORY(DIRECTORY_NAME) 847 SET(DIRECTORY_NAME "${DIRECTORY_NAME}_") 848 ENDIF() 849 850 #MESSAGE("TRIBITS_ADD_TEST: ${EXE_NAME}: EXE_BINARY_NAME = ${EXE_BINARY_NAME}") 851 852 IF (PARSE_NAME) 853 SET(TEST_NAME "${DIRECTORY_NAME}${PARSE_NAME}") 854 ELSEIF (PARSE_NAME_POSTFIX) 855 SET(TEST_NAME "${DIRECTORY_NAME}${EXE_NAME}_${PARSE_NAME_POSTFIX}") 856 ELSE() 857 SET(TEST_NAME "${DIRECTORY_NAME}${EXE_NAME}") 858 ENDIF() 859 860 SET(TEST_NAME "${PACKAGE_NAME}_${TEST_NAME}") 861 862 # 863 # B) Add or don't add tests based on a number of criteria 864 # 865 866 SET(ADD_THE_TEST FALSE) 867 TRIBITS_ADD_TEST_PROCESS_ENABLE_TESTS(ADD_THE_TEST) 868 IF (NOT ADD_THE_TEST) 869 RETURN() 870 ENDIF() 871 872 TRIBITS_ADD_TEST_PROCESS_SKIP_CTEST_ADD_TEST(ADD_THE_TEST) 873 IF (NOT ADD_THE_TEST) 874 RETURN() 875 ENDIF() 876 877 SET(ADD_THE_TEST FALSE) 878 TRIBITS_ADD_TEST_PROCESS_CATEGORIES(ADD_THE_TEST) 879 IF (NOT ADD_THE_TEST) 880 RETURN() 881 ENDIF() 882 883 SET(ADD_THE_TEST FALSE) 884 TRIBITS_ADD_TEST_PROCESS_HOST_HOSTTYPE(ADD_THE_TEST) 885 IF (NOT ADD_THE_TEST) 886 RETURN() 887 ENDIF() 888 889 TRIBITS_SET_DISABLED_AND_MSG(${TEST_NAME} "${PARSE_DISABLED}" 890 SET_DISABLED_AND_MSG) # Adds the test but sets DISABLED test prop! 891 892 # 893 # C) Set the name and path of the binary that will be run 894 # 895 896 TRIBITS_ADD_TEST_GET_EXE_BINARY_NAME( 897 "${EXE_NAME}" 898 ${PARSE_NOEXEPREFIX} 899 ${PARSE_NOEXESUFFIX} 900 ${PARSE_ADD_DIR_TO_NAME} EXE_BINARY_NAME 901 ) 902 903 TRIBITS_ADD_TEST_ADJUST_DIRECTORY( ${EXE_BINARY_NAME} "${PARSE_DIRECTORY}" 904 EXECUTABLE_PATH) 905 906 #MESSAGE("TRIBITS_ADD_TEST: ${EXE_NAME}: EXECUTABLE_PATH = ${EXECUTABLE_PATH}") 907 908 # 909 # D) Determine if we will add the serial or MPI tests based on input COMM 910 # and TPL_ENABLE_MPI 911 # 912 913 TRIBITS_PROCESS_COMM_ARGS(ADD_SERIAL_TEST ADD_MPI_TEST ${PARSE_COMM}) 914 915 # 916 # E) Get the MPI options 917 # 918 919 TRIBITS_ADD_TEST_GET_NUM_PROCS_USED("${PARSE_NUM_MPI_PROCS}" 920 "NUM_MPI_PROCS" NUM_PROCS_USED NUM_PROCS_USED_NAME) 921 IF (NUM_PROCS_USED LESS 0) 922 SET(ADD_MPI_TEST FALSE) 923 ENDIF() 924 925 IF (TPL_ENABLE_MPI) 926 SET(MPI_NAME_POSTFIX "_MPI_${NUM_PROCS_USED}") 927 ELSE() 928 SET(MPI_NAME_POSTFIX "") 929 ENDIF() 930 931 TRIBITS_ADD_TEST_GET_NUM_TOTAL_CORES_USED("${TEST_NAME}${MPI_NAME_POSTFIX}" 932 "${PARSE_NUM_TOTAL_CORES_USED}" "NUM_TOTAL_CORES_USED" 933 "${NUM_PROCS_USED}" "${NUM_PROCS_USED_NAME}" 934 NUM_TOTAL_CORES_USED SKIP_TEST) 935 IF (SKIP_TEST) 936 SET(ADD_SERIAL_TEST FALSE) 937 SET(ADD_MPI_TEST FALSE) 938 ENDIF() 939 940 # 941 # F) Add the tests 942 # 943 944 IF (NOT ADD_SERIAL_TEST AND NOT ADD_MPI_TEST) 945 RETURN() 946 ENDIF() 947 948 IF (NOT "${PARSE_ARGS}" STREQUAL "") 949 950 # F.1) Add tests with simple lists of arguments 951 952 SET(COUNTER 0) 953 954 FOREACH(PARSE_ARG ${PARSE_ARGS}) 955 956 IF(${NUM_PARSE_ARGS} EQUAL 1) 957 SET(TEST_NAME_INSTANCE "${TEST_NAME}${MPI_NAME_POSTFIX}") 958 ELSE() 959 SET(TEST_NAME_INSTANCE "${TEST_NAME}_${COUNTER}${MPI_NAME_POSTFIX}") 960 ENDIF() 961 IF(${PROJECT_NAME}_VERBOSE_CONFIGURE) 962 MESSAGE(STATUS "TEST_NAME = ${TEST_NAME_INSTANCE}") 963 ENDIF() 964 965 TRIBITS_CONVERT_CMND_ARG_STRING_TO_ADD_TEST_ARG_ARRAY(${PARSE_ARG} INARGS) 966 IF (${PROJECT_NAME}_VERBOSE_CONFIGURE) 967 PRINT_VAR(INARGS) 968 ENDIF() 969 970 TRIBITS_ADD_TEST_ADD_TEST_ALL( ${TEST_NAME_INSTANCE} 971 "${EXECUTABLE_PATH}" "${PARSE_CATEGORIES}" "${NUM_PROCS_USED}" 972 "${NUM_TOTAL_CORES_USED}" 973 ${PARSE_RUN_SERIAL} "${SET_DISABLED_AND_MSG}" ADDED_TEST_NAME ${INARGS} 974 "${${TEST_NAME_INSTANCE}_EXTRA_ARGS}" ) 975 IF(PARSE_ADDED_TESTS_NAMES_OUT AND ADDED_TEST_NAME) 976 LIST(APPEND ADDED_TESTS_NAMES_OUT ${ADDED_TEST_NAME}) 977 ENDIF() 978 979 MATH(EXPR COUNTER ${COUNTER}+1 ) 980 981 ENDFOREACH() 982 983 ELSEIF (PARSE_POSTFIX_AND_ARGS_0) 984 985 # F.2) Add tests with different postfixes for each set of arguments 986 987 FOREACH( POSTFIX_AND_ARGS_IDX RANGE ${MAX_NUM_POSTFIX_AND_ARGS_IDX}) 988 989 IF(${PROJECT_NAME}_VERBOSE_CONFIGURE) 990 PRINT_VAR(PARSE_POSTFIX_AND_ARGS_${POSTFIX_AND_ARGS_IDX}) 991 ENDIF() 992 993 IF (NOT PARSE_POSTFIX_AND_ARGS_${POSTFIX_AND_ARGS_IDX}) 994 BREAK() 995 ENDIF() 996 997 SET( POSTFIX_AND_ARGS ${PARSE_POSTFIX_AND_ARGS_${POSTFIX_AND_ARGS_IDX}} ) 998 999 LIST( GET POSTFIX_AND_ARGS 0 POSTFIX ) 1000 SET( INARGS ${POSTFIX_AND_ARGS} ) # Initially contains postfix as ele 0 1001 LIST( REMOVE_AT INARGS 0 ) # Strip off the postfix name 1002 1003 SET(TEST_NAME_INSTANCE "${TEST_NAME}_${POSTFIX}${MPI_NAME_POSTFIX}") 1004 1005 TRIBITS_ADD_TEST_ADD_TEST_ALL( ${TEST_NAME_INSTANCE} 1006 "${EXECUTABLE_PATH}" "${PARSE_CATEGORIES}" "${NUM_PROCS_USED}" 1007 "${NUM_TOTAL_CORES_USED}" 1008 ${PARSE_CREATE_WORKING_DIR} 1009 ${PARSE_RUN_SERIAL} "${SET_DISABLED_AND_MSG}" ADDED_TEST_NAME ${INARGS} 1010 "${${TEST_NAME_INSTANCE}_EXTRA_ARGS}" 1011 ) 1012 IF(PARSE_ADDED_TESTS_NAMES_OUT AND ADDED_TEST_NAME) 1013 LIST(APPEND ADDED_TESTS_NAMES_OUT ${ADDED_TEST_NAME}) 1014 ENDIF() 1015 1016 ENDFOREACH() 1017 1018 ENDIF() 1019 1020 IF(PARSE_ADDED_TESTS_NAMES_OUT) 1021 SET(${PARSE_ADDED_TESTS_NAMES_OUT} "${ADDED_TESTS_NAMES_OUT}" 1022 PARENT_SCOPE ) 1023 ENDIF() 1024 1025ENDFUNCTION() 1026