Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
Rename cmSystemTools::FindExecutableDirectory to FindCMakeResources.
Teach it to compute the locations of cmake, ctest, cpack, ccmake, and
cmake-gui executables, and the location of CMAKE_ROOT. Provide this
information from static cmSystemTools::Get<resource>() methods.
Refactor code that needs these locations to use the new APIs.
Teach FindCMakeResources to use the OS X system API to lookup the
executable location. When running from the CMake build tree itself,
leave a file in the tree that FindCMakeResources can use to read the
location of the source tree. This avoids the need to compile the source
tree location into a binary that may be installed and used without the
source tree.
Teach the QtDialog on OS X to create a "cmake-gui" symlink in the build
tree next to "cmake" and the other tools, as is already done in the
install tree for the application bundle. This ensures a consistent set
of executables are available in one directory.
Add a new command line argument to ctest. This allows users to
rerun tests that failed during the previous call to ctest. This
is accomplished by analyzing the most recently modified file named
"^LastTestsFailed*" in the Testing/Temporary subdirectory of the
project's binary directory.
Replace use of AppendEnv/RestoreEnv pairs with instances of
SaveRestoreEnvironment. Simplify the signature of AppendEnv and use it
in place of similar loops elsewhere. Move the RestoreEnv implementation
inside the SaveRestoreEnvironment destructor which is the only place
left that calls it.
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.