| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
it. So it fails on some platforms. This fixes that.
|
|
|
|
| |
GetLocation on a utility target - caused by custom command output file with same name as custom target. The fix is to avoid calling GetLocation unless the target is of a type that is expected to have a location...
|
| |
|
| |
|
|
|
|
| |
generator to build cmake is different than the one used for tests (watcom) is used.
|
| |
|
|
|
|
| |
will work in parallel now.
|
| |
|
| |
|
|
|
|
| |
not. Changed parallel test to be portable.
|
| |
|
|
|
|
|
| |
We set the variable 'XCODE_VERSION' in the CMake language to the Xcode
version string (e.g. "3.1.2"). Platform config files may use it later.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This teaches the TryCompile test to check that the compiler flag check
macros correctly reject a bad flag. See issue #9516.
|
|
|
|
|
| |
This test checks that configure_file() handles input and output file
arguments as documented.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We create test 'CTest.NoNewline' to print output with no newline.
This tests CTest's ability to handle a missing newline.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ExternalProject.cmake module. Follow the cmake function naming convention, using a ModuleFileName_ prefix. Locate stamp files under a CMAKE_CFG_INTDIR subdir of the stamp dir so that debug and release builds have separate stamp files for Visual Studio builds. If no CMAKE_GENERATOR argument is given to ExternalProject_Add, default to using the parent project's cmake generator.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Alex
|
|
|
|
| |
since it is a more accurate name.
|
|
|
|
| |
option to set_tests_properties (implementation to come).
|
|
|
|
|
|
|
| |
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 tests the LINK_INTERFACE_MULTIPLICITY property for a cycle of three
static libraries that must be scanned three times to link properly.
|
|
|
|
| |
coming soon...
|
|
|
|
|
| |
This removes the QUIET option from FortranCInterface_VERIFY in the
Fortran test to really test the detected interface everywhere.
|
|
|
|
|
|
|
| |
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 QtDialog is our supported cross-platform GUI, so the WXDialog source
is no longer needed.
|
|
|
|
|
|
|
|
| |
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 PGI compiler on Linux.
|
|
|
|
|
|
| |
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 STRINGS property tells cmake-gui to create a drop-down selection
list. This teaches the Properties test to set and verify its value.
|