| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
they are built with the type of build.
|
|
|
|
| |
error condition across different make programs so that these tests would pass.
|
| |
|
| |
|
|
|
|
| |
cause the calling ctest to return an error condition.
|
| |
|
|
|
|
| |
not build, tests that segfault, and test executable not found (bad command), as well as some pass and fail regular expressions.
|
|
|
|
|
| |
We create test 'CTest.NoNewline' to print output with no newline.
This tests CTest's ability to handle a missing newline.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
coming soon...
|
|
|
|
|
| |
The QtDialog is our supported cross-platform GUI, so the WXDialog source
is no longer needed.
|
|
|
|
| |
on dashboards driven by CMake 2.4... Good night now.
|
|
|
|
| |
configures with CMake 2.4 -- also check for existence of FindCVS.cmake before doing find_package(CVS QUIET) also for CMake 2.4 sake...
|
|
|
|
| |
file with the last commit... Sorry.
|
|
|
|
| |
write files into the source tree. Also add a test that runs last to check for local modifications in CMake_SOURCE_DIR based on whether 'cvs -q -n up -dP' output is empty. Test fails on dashboard runs when there are local modifications. Test passes on non-dashboard runs with local modifications so that CMake developers may have mods when running the test locally.
|
| |
|
|
|
|
| |
Alex
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
These tests cannot run with cygwin tools unless testing cygwin CTest.
The version control tools do not understand all Windows paths.
|
|
|
|
|
| |
The UpdateBZR and UpdateBZR.CLocale tests should run in different
directories so that they can be executed in parallel.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
is auto-defined now
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
of CPack. Add a test of it in the CPackComponents test. Thanks to Clinton Stimpson for the patch.
|
|
|
|
| |
installer available.
|
|
|
|
| |
installers for OSXX11 applications. Also modify the X11 test to build such an installer on Mac builds that test CPack and have X11 available. Thanks to Wes Turner for the patch.
|
|
|
|
|
| |
This fixes selection of a configuration when none is specified to find
an available configuration of the ctest test-command.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
fixing, more tests and documentation certain to follow as it gets used by others...
|
|
|
|
| |
variables on a per-test basis for ctest using set_test_properties ENVIRONMENT.
|
| |
|
| |
|
| |
|
|
|
|
| |
of cmCPackGenerator.cxx revision 1.16 ever encounters another regression.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
by CMake
|
|
|
|
|
|
|
|
| |
This introduces the unset() command to make it easy to unset CMake
variables, environment variables, and CMake cache variables. Previously
it was not even possible to unset ENV or CACHE variables (as in
completely remove them). Changes based on patch from Philip Lowman.
See issue #7507.
|
|
|
|
|
|
| |
We frequently need to wipe out all the CMake test build directories in
order to run tests from scratch. This change adds a test_clean custom
target to remove all these directories for out-of-source builds.
|
|
|
|
| |
Alex
|
|
|
|
| |
Alex
|