Visual Studio 10 uses MSBuild to drive the build. Custom commands
appear in MSBuild files inside CustomBuild elements, which appear inside
ItemGroup elements. The Outputs and AdditionalInputs elements of each
CustomBuild element are evaluated according to timestamps on disk.
MSBuild does not use inputs/outputs to order CustomBuild steps within a
single ItemGroup or across multiple ItemGroup elements. Instead we must
put only unrelated CustomBuild elements in a single ItemGroup and order
the item groups from top to bottom using a topological order of the
custom command dependency graph.
This fixes CustomCommand and ExternalProject test failures, so we remove
the expectation of these failures.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This test creates a C executable that links to a C++ static library. On
most platforms the executable will not link unless the C++ linker is
chosen correctly.
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This test requires a long time on slower machines, so we need to extend
its timeout. It is an important test, so it does not fall under the
CMAKE_RUN_LONG_TESTS option. In the future we should try to shorten the
test by building simpler external projects.
The test needs to create a cvs repository with 'cvs init', but the CVSNT
client on Windows needs 'cvs init -n' to avoid administrator access.
Previously we required users to explicitly enable CTEST_TEST_UPDATE_CVS
to activate the test on Windows.
This teaches the test to use the '-n' option when necessary. Now we can
enable the test in all cases except when trying to use a cygwin cvs.exe
without cygwin paths.
The BZR xml output plugin can use some encodings that are not recognized
by expat, which leads to "Error parsing bzr log xml: unknown encoding".
This works around the problem by giving expat a mapping, and adds a
test. Patch from Tom Vercauteren. See issue #6857.
This creates cmCTestBZR to drive CTest Update handling on bzr-based work
trees. Currently we always update to the head of the remote tracking
branch (bzr pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. Patch from Tom Vercauteren.
See issue #6857.
This creates cmCTestGIT to drive CTest Update handling on git-based work
trees. Currently we always update to the head of the remote tracking
branch (git pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. See issue #6994.
This teaches functions and macros to use policies recorded at creation
time when they are invoked. It restores the policies as a weak policy
stack entry so that any policies set by a function escape to its caller
as before.
The new 'testing' test behavior of actually running the tests generated
by the project still fails when the test script guesses the Debug
configuration but the CMake build tree was only built Release. The
inner ctest needs to find the ctest executable but is given the wrong
configuration.
The recent change of the 'testing' test to actually drive the tests
within it does not work on Windows with released CMakes 2.6.2 and lower
if no configuration is given to ctest with a -C option. This works
around the problem by detecting the case and changing the empty
configuration to Debug.
The 'testing' CMake test builds a project that uses add_test. This
strengthens the test to actually run CTest on the project build tree
after building it.
When CMake is built by CMake 2.4 or lower the FindCVS module is not
available. In that case we activiate CTest.UpdateCVS by searching for
the cvs command directly.
This creates new tests "CTest.UpdateSVN" and "CTest.UpdateCVS". They
test that the Update.xml produced by CTest for a version-controlled
project contains entries for files added, changed, and removed.