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.
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.
David Cole
Brad King
Zach Mullen
Bill Hoffman
Alexander Neundorf