If defined and non-empty, the value of CMAKE_TESTS_CDASH_SERVER should point
to a CDash server willing to accept submissions for a project named
PublicDashboard. On machines that also run a CDash dashboard, set this
variable to "http://localhost/CDash-trunk-Testing" so that the CMake tests
that submit dashboards do not have to send those submissions over the wire.
The CTestSubmitLargeOutput test runs a dashboard that has a test that produces
very large amount of output on stdout/stderr. Since we do not even want to
attempt to send such large output over the wire, this test is off by default
unless the CMAKE_TESTS_CDASH_SERVER server is localhost. This test is expected
to cause a submission failure when sent to CDash. It passes if the submit
results contain error output. It fails if the submit succeeds.
CMAKE_TESTS_CDASH_SERVER: CDash server used by CMake/Tests.
If not defined or "", this variable defaults to the server at
http://www.cdash.org/CDash.
If set explicitly to "NOTFOUND", curl tests and ctest tests that use the
network are skipped.
If set to something starting with "http://localhost/", the CDash is expected
to be an instance of CDash used for CDash testing, pointing to a
cdash4simpletest database. In these cases, the CDash dashboards should be
run first.
Commit "Teach CTest.Update tests to strongly check entries" (2010-02-09)
started checking Update.xml entries strongly. This revealed that some
cvs clients report "U CTestConfig.cmake" during update even though the
file did not change and it selects the same revision. As a result the
test fails with
Update.xml has extra unexpected entries:
Updated{CTestConfig.cmake}
We fix the test to tolerate this particular extra entry without failing.
We wrap the git executable in a shell script that touches one source
file after 'git pull'. This makes the file newer than the index even
though it has not actually changed. If CTest does not refresh the index
properly then the test will fail with a bogus modified file.
Previously these tests just checked for matching file names in the
Update.xml files. Now we check the update types (Updated, Modified, or
Conflicting) and reject unexpected extra entries.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
The PathScale compiler silently accepts unknown options that start in
more than one '-':
$ touch foo.c
$ pathcc -c foo.c --junk
$ echo $?
0
$ pathcc -c foo.c ---junk
$ echo $?
0
$ pathcc -c foo.c -junk
pathcc ERROR parsing -junk: unknown flag
$ echo $?
2
We teach the TryCompile to pass a bogus flag with only one '-' instead
of three '-'s for this compiler.
We disable this test because PathScale Fortran mangles module symbols as
"MYSUB.in.MYMODULE" so we cannot interface with it from C. We already
did this for SunPro and MIPSpro.
Makefile dependencies must be escaped using cmLocalGenerator::Convert
with the cmLocalGenerator::MAKEFILE option. This fixes Fortran module
dependencies with spaces in the path. We test the fix by adding a space
to one of the module paths in the Fortran test.
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.
The commit "Make CTestTestTimeout time configurable" added a CMake cache
variable CTestTestTimeout_TIME to configure the length of the timeout
used by the inner CTestTestTimeout test. The reason was to allow users
on slow machines to give this test some extra time without extending the
timeout for everyone. However, Cygwin CMake seems to load slowly enough
that it is worth a longer default timeout for that platform.
The commit "Submit Subversion directory path in Update.xml" added the
element <SVNPath>...</SVNPath> to Update.xml for Subversion work trees.
This commit teaches the CTest.UpdateSVN test to verify the presence of
the element.
We teach CTest to report in a <Revision> element the revision of the
source tree that was tested. This makes sense for all modern VCS tools
because they version the whole tree. We simply omit this element for
CVS because it only versions files. See issue #7541.
We teach ADD_TEST_MACRO to transform names of the form "Namespace.Name"
to the directory "Namespace/Name" and the project name "Name". This
will allow new tests to be better organized.
The test overrides the CMAKE_C_FLAGS and CMAKE_Fortran_FLAGS to test
passing a specific flag to the compiler wrapper scripts. We fix it to
honor any outside flags needed for the real compiler.
The commit "FortranCInterface: Honor language flags in checks" taught
the FortranCInterface module to pass C and Fortran flags into its
detection and verification checks. We improve on the change to allow
the '=' character in the language flags. This requires passing the
cache entry type with the -D options.
We create test FortranC.Flags to try passing per-language flags from a
project into its FortranCInterface detect/verify checks. We wrap the
compilers with scripts that enforce presence of expected flags.
CMake does not enable Fortran for its own build, but it needs to find a
Fortran compiler to know if it is possible to enable Fortran tests.
Previously we searched for a hard-coded list of Fortran compilers which
was duplicated from the CMakeDetermineFortranCompiler.cmake module. We
now run CMake on a small test project that enables the Fortran language
and reports the compiler it found. This represents a more realistic
check of whether the Fortran tests will be able to find a compiler.
Previously our EnforceConfig script that loads at test-time would only
enforce a non-empty CTEST_CONFIGURATION_TYPE for CMake 2.6.2 and lower.
Now we simply always enforce use of a configuration, and select one of
the configurations that was built if none is given.
This is necessary to run tests like CMake.Install that need to know the
configuration with which CMake was built.
We create option CMake_TEST_INSTALL to enable a new CMake.Install test.
It tests running the "make install" target to install CMake itself into
a test directory. We enable the option by default for dashboard builds.
We configure an EnforceConfig.cmake script to load at CTest time.
Previously we loaded it from Tests/CTestTestfile.cmake, but now we load
it from the top level so it applies to all tests.
Xcode 2.x forgets to create the target output directory before linking
the individual architecture pieces of a universal binary for the target
CMakeLibTests. Then it passes the directory to -L and -F options when
linking the and warns that the directory does not exist. We work around
the problem by using a pre-build rule on the target to create the output
directory.
We re-arrange EXECUTABLE_OUTPUT_PATH settings to avoid putting utility
and test executables in the 'bin' directory of the build tree. This
makes the directory look like that in the installation tree, except that
on multi-configuration generators we still use a per-config
subdirectory.
The DumpDocumentation executable and some supporting code and tests were
completely unused by CMake. Generation of documentation is done by the
individual executables with --help* options. In this commit we simply
remove the unused code, executable, and test.
Zach Mullen
David Cole
Bill Hoffman
Brad King