Provide the ability to configure CTest with settings different from the ones
available in the source tree by checking first if CTestConfig.cmake
exists in the build tree.
The motivation is to allow build system checking out external project to
test and/or package them and submit the associated results to a different
dashboard than the one specified (or not) in the source of the external
project.
For example, the build system of Slicer can checkout, build, test
and package what I will call "extensions". These extensions can be developed
by third parties who can test and submit to their own dashboard / project.
When checked out by Slicer build system, the default dashboard can now be
overwritten by adding a custom CTestConfig.cmake to the build directory.
And if not overwritten, it would avoid to create CTestConfig.cmake within
the source checkout of the extension.
Important when calling ctest commands in a loop from a script.
Each time Populate gets called, it uses the current definition
of the variable. Without the clear, it was accumulating additional
identical values each time through the loop.
In the log entry, the newline is missing. The output without the newline
character is a bit strange, like
SetCTestConfigurationFromCMakeVariable:MemoryCheckCommand:CTEST_MEMORYCHECK_COMMANDSetCTestConfiguration:MemoryCheckCommand:/usr/bin/valgrind
Instead of
SetCTestConfigurationFromCMakeVariable:MemoryCheckCommand:CTEST_MEMORYCHECK_COMMAND
SetCTestConfiguration:MemoryCheckCommand:/usr/bin/valgrind
This patch changes this to add a newline.
Signed-off-by: Bernhard Walle <walle@corscience.de>
This command allows a user to quickly see the list of all available
test labels. The labels are also printed in verbose show only mode,
alongside their corresponding tests.
Allow the user to set the CMake variable CTEST_COST_DATA_FILE, which will be used to store the cost data from test runs. If not set, defaults to the original location in the build tree Testing/Temporary dir.
If APPEND is given to ctest_start, it will read the tag from the current existing Testing/TAG file rather than creating a new one based on the current time stamp. This allows a developer to run several dashboard scripts in a row, all of which will share the same tag/stamp/buildid when they finally get submitted to CDash. Now you can split the running of build phases and test phases for the same dashboard row into multiple scripts.
In CTest command-driven script mode we support starting without a source
tree. Previously the ctest_start() command would do some initialization
but could not do anything that required CTestConfig.cmake from the input
source tree. Later, ctest_update() would run CTEST_CHECKOUT_COMMAND to
create the source tree, and then re-initialize everything. This
delayed-initialization approach led to many complicated cases of which
only some worked. For example, the second initialization only worked
correctly in Nightly mode and simply failed for Experimental and
Continuous builds.
A simpler solution is to run CTEST_CHECKOUT_COMMAND during ctest_start()
and then have a single initialization path. In principle this change in
behavior could break scripts that set the checkout command after
ctest_start() but before ctest_update(). However, the convention we've
always followed has been to set all variables before ctest_start().
See issue #9450.
We make the cmCTest::Initialize method private since it is only called
from inside the class implementation. We also combine the two boolean
arguments into one since they both meant the same thing.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
David Cole
Jean-Christophe Fillion-Robin
Bernhard Walle
Thomas Jarosch
Zach Mullen
Brad King
Kai Wasserbäch
Bill Hoffman