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.
Since "get_filename_component(... ABSOLUTE)" retrieves the actual case
for existing paths on windows, we need to use an obscure path for mingw.
Otherwise the test can fail just because the case of the paths changes.
This tests the internal CMakeParseImplicitLinkInfo.cmake module to
ensure that implicit link information is extracted correctly. The test
contains many manually verified examples from a variety of systems.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
The command "set(... PARENT_SCOPE)" should never affect the calling
scope. This improves the Function test to check that such calls in a
subdirectory scope affect the parent but not the child.
When this test was renamed from DumpInformation to SystemInformation the
configured header that points the dump executable to the directory
containing information files was broken. No information has been dumped
by this test for 2 years! This fixes it.
The ExportImport test drives its Export and Import projects using the
same compiler and flags. This converts the ctest --build-and-test
command lines to use an initial cache file instead of passing all
settings on the command line.
We need a shorter command line to pass through VS 6 on Win98.
This approach reduces duplicate code anyway.
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 extends the ExportImport test. The Export project creates a C++
static library and exports it. Then the Import project links the
library into a C executable. On most platforms the executable will link
only if the C++ linker is chosen correctly.
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 creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
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.
Brad King
David Cole
Zach Mullen
Alexander Neundorf
Bill Hoffman
Ken Martin