In this test we start up a cmake script that runs a process that sleeps,
and the timeout for the script is shorter than the sleep time. However,
in order to properly detect that the sleeping grandchild is killed when
the script times out we need to give sufficient time for the script to
start the grandchild. Otherwise the log file for the grandchild is not
available.
On some (cygwin) builds our previous 1 second timeout for the script was
not long enough to let the interpreter load and start the grandchild.
We make the timeout time configurable by setting CTestTestTimeout_TIME
in the cache for CMake itself. It tells the test how long to let the
script run. The grandchild always sleeps for 4 seconds longer to ensure
a comfortable window during which the process tree can be killed.
This test requires that the dashboard script it drives be invoked with
"ctest -C <config> -S ...". We create a "CTestTest_CONFIG" variable to
hold a configuration selected at test time. We use the configuration
given to the outer CTest, if any, and then default to either Debug or
the CMAKE_BUILD_TYPE.
We extend the CTestTestTimeout test to check that when a test times out
its children (grandchildren of ctest) are killed. Instead of running
the timeout executable directly, we run it through a cmake script that
redirects the timeout executable output to a file. A second test later
runs and verifies that the timeout executable was unable to complete and
write data to the log file. Only if the first inner test times out and
the second inner test passes (log is empty) does the CTestTestTimeout
test pass.
The commit "Fake $HOME to isolate tests from user" started setting $HOME
in the CTest script environment. On some platforms tests depend on some
local configuration in the home directory, such as the "cvs login" for
KWSys in CTestTest3.
In this commit we now construct a fake home dir during CMake config step
and populate it with a .cvspass file needed by the test. We also check
CTEST_NO_TEST_HOME to optionally disable the test home.
See issue #9949.
On platforms with $HOME in the environment, some of our features use it
to store information in the user home directory. However, tests for
these features should not touch the real user home directory. Instead
we configure a fake $HOME that points inside the build tree for use
during testing.
See issue #9949.
The commit "Fix get_filename_component ABSOLUTE mode" broke REALPATH
treatment of relative paths because it stopped storing the absolute path
in local variable 'filename'. This commit fixes the call to GetRealPath
to use the proper local variable and adds a test.
Some compilers use implicit link options of the form
-lcrt*.o
-lgcc*
-lSystem (on Mac)
-lSystemStubs (on Mac)
that provide system-wide symbols not specific to any language.
These need not be listed explicitly for mixed-language linking.
We teach CMake to remove the above items from the implicit library list
of each language. This change makes it possible to mix GNU compiler
versions in some cases.
This allows for a built in bzip and zip capability, so external tools
will not be needed for these packagers. The cmake -E tar xf should be
able to handle all compression types now as well.
The commit "Test per-config OUTPUT_DIRECTORY properties" added this test
with a find_library() call in a CMake script, which requires an explicit
list of possible library prefixes and suffixes. This commit adds more
suffixes to match the libraries built on HP, MinGW, and Cygwin.
We test (ARCHIVE|LIBRARY|RUNTIME)_OUTPUT_DIRECTORY_<CONFIG> properties
by building COnly as a subdirectory and setting the properties to put
its files in specific locations. We build an executable that verifies
the targets actually appear where expected.
The BuildDepends test exercises incremental linking with MSVC and Intel
tools on Windows. In some cases the Intel compiler creates objects that
cause the MS linker it invokes to crash during incremental linking. We
avoid the problem for this test by disabling incremental linking.
We introduce the "CMake.If" test to try out conversion of constants and
variables to boolean values in the if() command. We cover both OLD and
NEW behavior for policy CMP0012.
The commit "Test all target types in Fortran" enabled a SHARED library
in the Fortran test. However, we do not yet implement support for
shared libraries with XL Fortran (it seems this requires using the C
compiler to link). Furthermore, the old g77 2.97 from Red Hat does not
support shared libs on Itanium because the g2c lib is not -fPIC.
For now we just disable SHARED libs in the test for these tools.
We add Intel and MinGW Fortran linker options to create the import
library portion of a DLL. This allows other binaries to link to a
Fortran DLL.
We also update the Fortran test to use a .def file to specify exports
since there is no __declspec(dllexport) markup syntax in Fortran.
To enable this test, the option TEST_KDE4_STABLE_BRANCH must be switched on.
It can only be switched on if CMAKE_RUN_LONG_TESTS is ON.
Then the test will only be added if Qt >= 4.5 can be found, Perl can be
found and ZLIB can be found.
Alex
This commit re-writes Borland compiler build rules. We split the rules
into modern <os>-<id>-<lang> information modules but share a common
macro between languages to avoid duplication.
We also address a bug in the previous rules that would build some target
types against the static Borland runtime and others against the shared
Borland runtime in one build tree. Now we always use the shared runtime
as is the default in the rules for MS tools.
Previously we passed inputs to the decision to each Complex test and let
the test source decide. This commit moves the decision out of the tests
and makes it an option() in their source. This makes it possible to
build the Complex tests from outside the CMake test tree.
When <pkg>_DIR is set to an incorrect version we search again and store
the result in the variable, even if it is <pkg>_DIR-NOTFOUND.
There was a bug in the case when the new search does not find anything
and the old value came from a cache entry with UNINITALIZED type. The
command used to try to load a package configuration file from the last
place searched, and would leave the old wrong value in the entry. This
commit fixes the behavior to avoid trying to load a missing file and to
set the value to <pkg>_DIR-NOTFOUND as expected.
The regex used by CMAKE_PARSE_IMPLICIT_LINK_INFO to detect link lines
should not match lines that happen to have ".../ld.../..." in them. A
linker name should match only as the last component of a path.
See issue #9666.
This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log
its actions. We store the log in CMakeFiles/CMakeOutput.log at the top
of the project build tree. This will make diagnosis of implicit link
information parsing problems easier.
In the Fortran test we use a custom command to build another Fortran
project internally. The project provides a Fortran module and library
to which to link. This commit teaches the test to build the extra
project using the same build configuration as the main project.
We need to leave out the '%' character from tests with the Intel
compiler. Since '%' needs to be written '%%' in NMake when not using a
response file but just '%' when using a response file, we just skip the
character for now. It works with MSVC in NMake only because that
compiler expects '%%' inside response files, which do get used.
CMake defines MSVC only for a VS compiler, but the Intel compiler adds
the preprocessor definition _MSC_VER. Instead of relying on separate
tests to decide whether to use example_dll_2, we do one test in CMake
and then add our own preprocessor definition.
We test this by adding export(TARGETS) to the LinkLanguage test to
export the executable before the library is linked to it. Since
export(TARGETS) computes the link interface of the target (so that it
can export it), this ensures that the information is recomputed after
the link library is added.
This adds a "ModuleDefinition" test enabled when using MSVC tools. It
checks that .def files can be used to export .dll and .exe symbols and
create corresponding .lib files that can be linked. See issue #9613.
Policy CMP0002's OLD behavior allows duplicate non-custom targets. We
test it with a project that builds two executables of the same name by
setting CMP0002 to OLD.
The flag "-_this_is_not_a_flag_" was not rejected by GCC 4.0 on older
Mac OS X. We now use "---_this_is_not_a_flag_" instead, which will
hopefully be rejected by all compilers.
The CMake.File test runs several scripts through "cmake -P" and checks
the output and result against known good values. This commit factors
out the checking code into a separate CMakeCheckTest module. The module
may be used by new tests.
This commit teaches the FunctionTest to check variable scope behavior
when a subdirectory is added inside a function call. Any PARENT_SCOPE
sets in the subdirectory should affect only the function scope which
called add_subdirectory and not its parent scope.
CMake now looks for a Fortran compiler matching any C or C++ compiler
already enabled. We test this by enabling C and C++ first in the
Fortran test, which is what user projects will likely do.
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.
Part of this test does "git pull" on a dirty work tree. We need to make
sure that 'branch.master.rebase' is false for the test repository.
Otherwise if it is true in the user configuration then pull will refuse
to rebase and the test will fail.
We teach the FindPackageTest to build a sample project that stores its
build tree in the user package registry using export(PACKAGE), and then
find it with find_package.
We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and
install(EXPORT) into dependent projects. A simple cycle of two archives
that need to be scanned three times ensures that the importing project
uses the multiplicity correctly.
This function builds a simple test project using a combination of
Fortran and C (and optionally C++) to verify that the compilers are
compatible. The idea is to help projects report very early to users
that the compilers specified cannot mix languages.
This teaches the 'testing' test to try generator expressions in
arguments to add_test(NAME). This test case mimics a common use-case of
passing executables to test driver scripts. We excercise the syntax for
per-configuration target file names.
This is a new FortranCInterface.cmake module to replace the previous
prototype. All module support files lie in a FortranCInterface
directory next to it.
This module uses a new approach to detect Fortran symbol mangling. We
build a single test project which defines symbols in a Fortran library
(one per object-file) and calls them from a Fortran executable. The
executable links to a C library which defines symbols encoding all known
manglings (one per object-file). The C library falls back to the
Fortran library for symbols it cannot provide. Therefore the executable
will always link, but prefers the C-implemented symbols when they match.
These symbols store string literals of the form INFO:symbol[<name>] so
we can parse them out of the executable.
This module also provides a simpler interface. It always detects the
mangling as soon as it is included. A single macro is provided to
generate mangling macros and optionally pre-mangled symbols.
The try_compile command builds the cmTryCompileExec executable using the
cmTryCompileExec/fast target with Makefile generators in order to save
time since dependencies are not needed. However, in project mode the
command builds an entire source tree that may have dependencies.
Therefore we can use the /fast target approach only in one-source mode.
Previously the Fortran test created a single executable containing C,
C++, and Fortran sources. This commit divides the executable into three
libraries corresponding to each language, and two executables testing
Fortran/C only and Fortran/C/C++ together. The result tests more
combinations of using the languages together, and that language
requirements propagate through linking.
When building an entire source tree with try_compile instead of just a
single source file, it is possible that the CMakeLists.txt file in the
try-compiled project invokes try_compile. This commit fixes propagation
of language-initialization results from the outer-most project into any
number of try-compile levels.
The try_compile command project mode builds an entire source tree
instead of one source file. It uses an existing CMakeLists.txt file in
the given source tree instead of generating one. This commit creates a
test for the mode in the TryCompile test.
This adds sample linker invocation lines for the Intel compiler on
Linux. In particular, this exercises the case when "ld" appears without
a full path.
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
This extends the Fortran-to-C interface test to add a C++ source file.
The executable can only link with the C++ linker and with the proper
Fortran runtime libraries. These libraries should be detected by CMake
automatically, so this tests verifies the detection functionality.
This hack was created to help the Fortran test executables link to the
implicit C libraries added by BullsEye. Now that implicit libraries
from all languages are detected and included automatically the hack is
no longer needed.
This teaches the SystemInformation test to report the CMake log files
CMakeOutput.log and CMakeError.log from the CMake build tree and from
the SystemInformation test build tree. These logs may help diagnose
dashboard problems remotely.
This extends the Fortran/C interface test to require that the executable
link to the fortran language runtime libraries. We must verify that the
proper linker is chosen.
The commit "Avoid case change in ImplicitLinkInfo test" did not change
all of the paths to mingw, so some case change still occurs. This
changes more of them.
Brad King
Zach Mullen
David Cole
Bill Hoffman
Alexander Neundorf