kolan
/
CMake
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
CMake/Tests/RunCMake/CMakeLists.txt

120 lines
4.1 KiB
CMake
Raw Normal View History

Add stronger infrastructure for CMake-only tests The CMakeOnly directory added by commit 9a20abf0 (Add infrastructure for CMake-only tests, 2012-01-11) was sufficient only for tests that always run CMake to successfully configure a project. Later commit eeaaffcb (find_package: Test error and warning messages in failure cases, 2012-02-28) added a sample test that covers failure cases. Generalize the above to create new "RunCMake" test infrastructure that can run CMake multiple times for a single project with different variations and check for expected result/stdout/stderr. Allow for both successful and failing CMake project configuration cases. This will be useful to test error messages and failure behavior.
2012-03-10 01:24:43 +04:00
# This directory contains tests that run CMake to configure a project
# but do not actually build anything. To add a test:
#
# 1.) Add a subdirectory named for the test.
#
# 2.) Call add_RunCMake_test and pass the test directory name.
#
# 3.) Create a RunCMakeTest.cmake script in the directory containing
# include(RunCMake)
# run_cmake(SubTest1)
# ...
# run_cmake(SubTestN)
# where SubTest1..SubTestN are sub-test names each corresponding to
# an independent CMake run and project configuration.
#
# 3.) Create a CMakeLists.txt file in the directory containing
# cmake_minimum_required(...)
# project(${RunCMake_TEST} NONE) # or languages needed
# include(${RunCMake_TEST}.cmake)
# where "${RunCMake_TEST}" is literal. A value for RunCMake_TEST
# will be passed to CMake by the run_cmake macro when running each
# sub-test.
#
# 4.) Create a <SubTest>.cmake file for each sub-test named above
# containing the actual test code. Optionally create files
# containing expected test results:
Teach RunCMake tests to allow custom checks Look for a <SubTest>-check.cmake script and load it to check side effects of the sub test. Provide it with the test source and build tree paths in variables. Check for a failure message in a result variable.
2012-04-18 19:09:18 +04:00
# <SubTest>-result.txt = Process result expected if not "0"
# <SubTest>-stdout.txt = Regex matching expected stdout content
# <SubTest>-stderr.txt = Regex matching expected stderr content
# <SubTest>-check.cmake = Custom result check
Tests/RunCMake: Document stripping of expected output Document that trailing newlines are stripped from the -stdout.txt and -stderr.txt content before using as a regular expression.
2013-07-24 22:01:21 +04:00
# Note that trailing newlines will be stripped from actual and expected test
Add stronger infrastructure for CMake-only tests The CMakeOnly directory added by commit 9a20abf0 (Add infrastructure for CMake-only tests, 2012-01-11) was sufficient only for tests that always run CMake to successfully configure a project. Later commit eeaaffcb (find_package: Test error and warning messages in failure cases, 2012-02-28) added a sample test that covers failure cases. Generalize the above to create new "RunCMake" test infrastructure that can run CMake multiple times for a single project with different variations and check for expected result/stdout/stderr. Allow for both successful and failing CMake project configuration cases. This will be useful to test error messages and failure behavior.
2012-03-10 01:24:43 +04:00
# output before matching against the stdout and stderr expressions.
Teach RunCMake tests to allow custom checks Look for a <SubTest>-check.cmake script and load it to check side effects of the sub test. Provide it with the test source and build tree paths in variables. Check for a failure message in a result variable.
2012-04-18 19:09:18 +04:00
# The code in <SubTest>-check.cmake may use variables
# RunCMake_TEST_SOURCE_DIR = Top of test source tree
# RunCMake_TEST_BINARY_DIR = Top of test binary tree
# and an failure must store a message in RunCMake_TEST_FAILED.
Add stronger infrastructure for CMake-only tests The CMakeOnly directory added by commit 9a20abf0 (Add infrastructure for CMake-only tests, 2012-01-11) was sufficient only for tests that always run CMake to successfully configure a project. Later commit eeaaffcb (find_package: Test error and warning messages in failure cases, 2012-02-28) added a sample test that covers failure cases. Generalize the above to create new "RunCMake" test infrastructure that can run CMake multiple times for a single project with different variations and check for expected result/stdout/stderr. Allow for both successful and failing CMake project configuration cases. This will be useful to test error messages and failure behavior.
2012-03-10 01:24:43 +04:00
macro(add_RunCMake_test test)
add_test(RunCMake.${test} ${CMAKE_CMAKE_COMMAND}
-DCMAKE_MODULE_PATH=${CMAKE_CURRENT_SOURCE_DIR}
-DRunCMake_GENERATOR=${CMAKE_TEST_GENERATOR}
Tests: Add generator toolset support Propagate CMAKE_GENERATOR_TOOLSET through the test hierarchy so that all tests can build with the selected generator toolset, if any.
2013-02-06 01:10:36 +04:00
-DRunCMake_GENERATOR_TOOLSET=${CMAKE_TEST_GENERATOR_TOOLSET}
Add stronger infrastructure for CMake-only tests The CMakeOnly directory added by commit 9a20abf0 (Add infrastructure for CMake-only tests, 2012-01-11) was sufficient only for tests that always run CMake to successfully configure a project. Later commit eeaaffcb (find_package: Test error and warning messages in failure cases, 2012-02-28) added a sample test that covers failure cases. Generalize the above to create new "RunCMake" test infrastructure that can run CMake multiple times for a single project with different variations and check for expected result/stdout/stderr. Allow for both successful and failing CMake project configuration cases. This will be useful to test error messages and failure behavior.
2012-03-10 01:24:43 +04:00
-DRunCMake_SOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}/${test}
-DRunCMake_BINARY_DIR=${CMAKE_CURRENT_BINARY_DIR}/${test}
Xcode: Implement generator toolset selection (#9831, #13802) Implement generator toolset selection (cmake -T) for Xcode > 2.0 by adding the GCC_VERSION build setting to project files.
2012-12-20 19:16:57 +04:00
${${test}_ARGS}
Add stronger infrastructure for CMake-only tests The CMakeOnly directory added by commit 9a20abf0 (Add infrastructure for CMake-only tests, 2012-01-11) was sufficient only for tests that always run CMake to successfully configure a project. Later commit eeaaffcb (find_package: Test error and warning messages in failure cases, 2012-02-28) added a sample test that covers failure cases. Generalize the above to create new "RunCMake" test infrastructure that can run CMake multiple times for a single project with different variations and check for expected result/stdout/stderr. Allow for both successful and failing CMake project configuration cases. This will be useful to test error messages and failure behavior.
2012-03-10 01:24:43 +04:00
-P "${CMAKE_CURRENT_SOURCE_DIR}/${test}/RunCMakeTest.cmake"
)
endmacro()
Use generalized RunCMake test infrastrucure for find_package test
2012-03-10 01:34:09 +04:00
Xcode: Implement generator toolset selection (#9831, #13802) Implement generator toolset selection (cmake -T) for Xcode > 2.0 by adding the GCC_VERSION build setting to project files.
2012-12-20 19:16:57 +04:00
if(XCODE_VERSION AND "${XCODE_VERSION}" VERSION_LESS 3)
set(GeneratorToolset_ARGS -DXCODE_BELOW_3=1)
endif()
Add policy CMP0019 to skip include/link variable re-expansion Historically CMake has always expanded ${} variable references in the values given to include_directories(), link_directories(), and link_libraries(). This has been unnecessary since general ${} evaluation syntax was added to the language a LONG time ago, but has remained for compatibility with VERY early CMake versions. For a long time the re-expansion was a lightweight operation because it was only processed once at the directory level and the fast-path of cmMakefile::ExpandVariablesInString was usually taken because values did not have any '$' in them. Then commit d899eb71 (Call ExpandVariablesInString for each target's INCLUDE_DIRECTORIES, 2012-02-22) made the operation a bit heavier because the expansion is now needed on a per-target basis. In the future we will support generator expressions in INCLUDE_DIRECTORIES with $<> syntax, so the fast-path in cmMakefile::ExpandVariablesInString will no longer be taken and re-expansion will be very expensive. Add policy CMP0019 to skip the re-expansion altogether in NEW behavior. In OLD behavior perform the expansion but improve the fast-path heuristic to match ${} but not $<>. If the policy is not set then warn if expansion actually does anything. We expect this to be encountered very rarely in practice.
2012-12-06 18:59:18 +04:00
add_RunCMake_test(CMP0019)
Introduce the INTERFACE_LINK_LIBRARIES property. This property replaces the properties which match (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?, and is enabled for IMPORTED targets, and for non-IMPORTED targets only with a policy. For static libraries, the INTERFACE_LINK_LIBRARIES property is also used as the source of transitive usage requirements content. Static libraries still require users to link to all entries in their LINK_LIBRARIES, but usage requirements such as INCLUDE_DIRECTORIES COMPILE_DEFINITIONS and COMPILE_OPTIONS can be restricted to only certain interface libraries. Because the INTERFACE_LINK_LIBRARIES property is populated unconditionally, we need to compare the evaluated result of it with the link implementation to determine whether to issue the policy warning for static libraries. For shared libraries, the policy warning is issued if the contents of the INTERFACE_LINK_LIBRARIES property differs from the contents of the relevant config-specific old LINK_INTERFACE_LIBRARIES property.
2013-06-04 18:25:47 +04:00
add_RunCMake_test(CMP0022)
CTest: Fail early without PROJECT_BINARY_DIR (#14005) Do not use PROJECT_BINARY_DIR before it is defined. If it is not defined when needed, fail with an error message suggesting that the project() command be invoked first.
2013-03-13 02:20:01 +04:00
add_RunCMake_test(CTest)
Test Unix Makefiles generator support for changing compilers Add RunCMake.CompilerChange test to cover use of -DCMAKE_C_COMPILER=cc to change the compiler of an existing build tree. Also test for proper failure with -DCMAKE_C_COMPILER="" and no CC in the environment.
2013-02-18 19:35:53 +04:00
if(UNIX AND "${CMAKE_TEST_GENERATOR}" MATCHES "Unix Makefiles")
add_RunCMake_test(CompilerChange)
endif()
cmake: On configure error suggest looking at CMake*.log files When CMake reports failure to configure a project, especially when the toolchain does not initialize properly, the true reason may be clear from reading the CMakeFiles/CMake(Output|Error).log files. Advise users to look at these files if they exist when configuration fails. Add RunCMake.Configure test to check that the log files are mentioned when configuration fails.
2013-07-09 22:35:49 +04:00
add_RunCMake_test(Configure)
ExternalData: Add tests covering interfaces and errors Add a Module.ExternalData test to verify data retrieval and test argument DATA{} references. Add a RunCMake.ExternalData test to verify error handling and automatic transformation of a raw data to a content link and staged object.
2013-01-26 01:39:57 +04:00
add_RunCMake_test(ExternalData)
FPHSA: Convert FOUND_VAR failure test to RunCMake Move the Tests/FPHSA_InvalidFOUND_VAR test case over to a new RunCMake.FPHSA test with a BadFoundVar case. The RunCMake tests are built to cover failure cases easily and robustly.
2013-02-22 17:44:13 +04:00
add_RunCMake_test(FPHSA)
Add boolean generator expressions Add generator expressions that combine and use boolean test results: $<0:...> = empty string (ignores "...") $<1:...> = content of "..." $<AND:?[,?]...> = '1' if all '?' are '1', else '0' $<OR:?[,?]...> = '0' if all '?' are '0', else '1' $<NOT:?> = '0' if '?' is '1', else '1' These will be useful to evaluate (future) boolean query expressions and condition content on the results. Include tests and documentation.
2012-08-13 17:49:53 +04:00
add_RunCMake_test(GeneratorExpression)
CMake: Add -T option to choose a generator toolset Reject the option by default. It will be implemented on a per-generator basis. Pass the setting into try_compile project generation. Add cache entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to hold the value persistently. Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases. Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is rejected when the generator doesn't support it, and that two -T options are always rejected.
2012-12-10 19:42:33 +04:00
add_RunCMake_test(GeneratorToolset)
Process generator expressions in the INCLUDE_DIRECTORIES property. This use of generator expressions, like all others to come which operate on target properties, must initalize the dag checker.
2012-09-18 15:57:07 +04:00
add_RunCMake_test(TargetPropertyGeneratorExpressions)
Do not crash on SHARED library without language (#13324) Since commit e1409ac5 (Support building shared libraries or modules without soname, 2012-04-22) CMake crashes on the code add_library(foo SHARED foo.nolang) because the logic to lookup the language's soname flag was moved from cmTarget::GetLibraryNames to cmMakefile::GetSONameFlag without its check for a NULL language. Restore the check for NULL. Add RunCMake.Languages test to cover language error cases like this one.
2012-06-20 19:04:35 +04:00
add_RunCMake_test(Languages)
Test OBJECT library failure cases Add "RunCMake.ObjectLibrary" test to verify that unsupported use cases are rejected with errors: * An OBJECT library may not reference another object library * An OBJECT library may not be referenced in target_link_libraries * An OBJECT library may not contain non-compiling sources * An OBJECT library may not have pre/post build/link commands * An OBJECT library may not be installed, exported, or imported Also verify that invalid $<TARGET_OBJECTS:...> expressions are diagnosed.
2012-03-12 22:51:30 +04:00
add_RunCMake_test(ObjectLibrary)
Process the INTERFACE_PIC property from linked dependencies This allows a dependee to inform a target that it should have its POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of the POSITION_INDEPENDENT_CODE property, if set, must be consistent with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees. Add a test covering the consistency checks on platforms where they run.
2012-11-05 15:46:26 +04:00
if(NOT WIN32)
add_RunCMake_test(PositionIndependentCode)
Introduce target property <LANG>_VISIBILITY_PRESET This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target property is used as the operand to the -fvisibility= compile option with GNU compilers and clang.
2013-05-18 14:12:18 +04:00
set(SKIP_VISIBILITY 0)
if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU" AND "${CMAKE_CXX_COMPILER_VERSION}" VERSION_LESS 4.2)
set(SKIP_VISIBILITY 1)
endif()
if (CMAKE_CXX_COMPILER_ID MATCHES Watcom
OR CMAKE_SYSTEM_NAME MATCHES IRIX64
OR CMAKE_CXX_COMPILER_ID MATCHES HP
OR CMAKE_CXX_COMPILER_ID MATCHES XL
OR CMAKE_CXX_COMPILER_ID MATCHES SunPro)
set(SKIP_VISIBILITY 1)
endif()
if (NOT SKIP_VISIBILITY)
add_RunCMake_test(VisibilityPreset)
endif()
Process the INTERFACE_PIC property from linked dependencies This allows a dependee to inform a target that it should have its POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of the POSITION_INDEPENDENT_CODE property, if set, must be consistent with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees. Add a test covering the consistency checks on platforms where they run.
2012-11-05 15:46:26 +04:00
endif()
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
add_RunCMake_test(CompatibleInterface)
Test OBJECT library failure cases Add "RunCMake.ObjectLibrary" test to verify that unsupported use cases are rejected with errors: * An OBJECT library may not reference another object library * An OBJECT library may not be referenced in target_link_libraries * An OBJECT library may not contain non-compiling sources * An OBJECT library may not have pre/post build/link commands * An OBJECT library may not be installed, exported, or imported Also verify that invalid $<TARGET_OBJECTS:...> expressions are diagnosed.
2012-03-12 22:51:30 +04:00
add_dependencies: Distinguish target v. file dependencies in error (#14050) When called with a non-existent LHS target name the user may be trying to add file-level dependencies. Clarify the error message to explain the difference between target-level and file-level dependencies. Point the reader at the commands and options needed for the latter.
2013-03-29 22:53:36 +04:00
add_RunCMake_test(add_dependencies)
Use generalized RunCMake test infrastrucure for build_command test The CMakeCommands.build_command test performs output/error checking so move it over to RunCMake to re-use the generalized infrastrucure. This is the only test left using Tests/CMakeCommands/CMakeLists.txt so remove it.
2012-03-10 01:47:19 +04:00
add_RunCMake_test(build_command)
Use generalized RunCMake test infrastrucure for find_package test
2012-03-10 01:34:09 +04:00
add_RunCMake_test(find_package)
get_filename_component: Add explicit unit tests Add test RunCMake.get_filename_component to cover cases of the command. Remove redundant coverage of these cases from the "complex" tests.
2013-04-16 17:27:51 +04:00
add_RunCMake_test(get_filename_component)
if: Add test for IS_DIRECTORY Add a RunCMake.if test to cover if() command behavior. Start with a test for IS_DIRECTORY cases with an existing directory and a long path, both with a trailing slash.
2013-05-28 19:13:24 +04:00
add_RunCMake_test(if)
include: Ignore empty string as file name (#13388) Previously CMake silently accepted the empty string and added a bogus dependency on the current directory. Instead warn about the empty file name and ignore it. We cannot make this an error because there may be existing projects that accidentally depend on the old behavior. Add a RunCMake.include test to cover this case.
2012-07-10 18:55:02 +04:00
add_RunCMake_test(include)
GenEx: Fix reporting about not-found include directories and libraries. This fixes a regression introduced in commit 290e92ad (Move GetIncludeDirectories to cmGeneratorTarget, 2012-09-16) which loops over cmGeneratorTargets before they get created, so the container is empty.
2012-10-15 12:27:42 +04:00
add_RunCMake_test(include_directories)
list: Handle errors on empty lists more gracefully (#13138) Since commit ed1ea24c (Fix INSERT to allow inserting to empty list, 2006-05-15) the list command allows insertion into an empty list at index 0. Fix rejection of insertion at non-zero (negative) indices to present an error message instead of crashing. While at it, fix the error message of the GET and REMOVE_AT operations when the list is empty to not present a bogus allowed range. Add a "RunCMake.list" test to cover failure cases on empty lists.
2012-04-17 18:32:46 +04:00
add_RunCMake_test(list)
try_compile: Add test for bad call error cases Add a RunCMake.try_compile test to cover cases of bad invocation of the try_compile command.
2013-05-15 23:19:20 +04:00
add_RunCMake_test(try_compile)
variable_watch: Add test for MODIFIED_ACCESS report Add a RunCMake.variable_watch watch test to cover the basic use case.
2013-06-03 17:23:25 +04:00
add_RunCMake_test(variable_watch)
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
add_RunCMake_test(CMP0004)
Genex: Make CMP0021 and CMP0022 usable with TARGET_POLICY Use preprocessor loops and add a unit test for the appropriate policies. All policies whose value is recorded at target creation time should be part of this list.
2013-06-28 13:25:40 +04:00
add_RunCMake_test(TargetPolicies)
include_external_msproject: Test TYPE, GUID, PLATFORM options (#13120) Add "RunCMake.include_external_msproject" test to use the TYPE, GUID, and PLATFORM options to include_external_msproject. Since projects with custom types and platforms cannot be loaded without special VS plugins validate the results by directly parsing the generated solution (.sln). Co-Author: Leonid Yurchenko <nocturne@qarea.com>
2012-04-19 16:35:10 +04:00
FindQt4: Set the INTERFACE_QT_MAJOR_VERSION for Qt4::QtCore With a similar commit in Qt 5, this will error at CMake time if an attempt is made to use target_link_libraries(foo Qt4::QtCore Qt5::Core)
2013-03-16 21:25:59 +04:00
find_package(Qt4 QUIET)
find_package(Qt5Core QUIET)
Fix the Qt 5 version required to run the IncompatibleQt test. The commit to add the INTERFACE_QT_MAJOR_VERSION in qtbase.git is 14054d45 (Set the INTERFACE_QT_MAJOR_VERSION to 5., 2013-03-16) which will be part of Qt 5.1.0. If there is a Qt 5.0.3 release, there is no guarantee it will contain that commit. Make sure such a Qt version does not fail with this test if not.
2013-03-27 03:15:08 +04:00
if (QT4_FOUND AND Qt5Core_FOUND AND NOT Qt5Core_VERSION VERSION_LESS 5.1.0)
FindQt4: Set the INTERFACE_QT_MAJOR_VERSION for Qt4::QtCore With a similar commit in Qt 5, this will error at CMake time if an attempt is made to use target_link_libraries(foo Qt4::QtCore Qt5::Core)
2013-03-16 21:25:59 +04:00
add_RunCMake_test(IncompatibleQt)
endif()
Mark qt4_use_modules and qt4_automoc as obsolete. The QT_QMAKE_EXECUTABLE has to be passed through the cmake calls because the executable may not be in the PATH.
2013-07-04 12:00:27 +04:00
if (QT4_FOUND)
set(ObsoleteQtMacros_ARGS -DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE})
add_RunCMake_test(ObsoleteQtMacros)
endif()
FindQt4: Set the INTERFACE_QT_MAJOR_VERSION for Qt4::QtCore With a similar commit in Qt 5, this will error at CMake time if an attempt is made to use target_link_libraries(foo Qt4::QtCore Qt5::Core)
2013-03-16 21:25:59 +04:00
include_external_msproject: Test TYPE, GUID, PLATFORM options (#13120) Add "RunCMake.include_external_msproject" test to use the TYPE, GUID, and PLATFORM options to include_external_msproject. Since projects with custom types and platforms cannot be loaded without special VS plugins validate the results by directly parsing the generated solution (.sln). Co-Author: Leonid Yurchenko <nocturne@qarea.com>
2012-04-19 16:35:10 +04:00
if("${CMAKE_TEST_GENERATOR}" MATCHES "Visual Studio [^6]")
add_RunCMake_test(include_external_msproject)
Add tests for VS_SOLUTION_GLOBAL_SECTIONS Add tests for correct appliation of directory properties VS_SOLUTION_GLOBAL_SECTIONS_*
2012-10-14 15:15:33 +04:00
add_RunCMake_test(SolutionGlobalSections)
include_external_msproject: Test TYPE, GUID, PLATFORM options (#13120) Add "RunCMake.include_external_msproject" test to use the TYPE, GUID, and PLATFORM options to include_external_msproject. Since projects with custom types and platforms cannot be loaded without special VS plugins validate the results by directly parsing the generated solution (.sln). Co-Author: Leonid Yurchenko <nocturne@qarea.com>
2012-04-19 16:35:10 +04:00
endif()
file: Add GENERATE command to produce files at generate time The idea is to write to a temp file which contains generator expressions, and at generate time, evaluate the generator expressions, and write the result to a file. Because executables on Windows are limited in the length of command line it is possible to use, it is common to write command line arguments to a file instead and specify the file as a source of arguments. This new FILE(GENERATE) subcommand allows the use of generator expressions to create such files so that they can be used with add_custom_command for example.
2013-01-02 20:10:04 +04:00
add_RunCMake_test(File_Generate)
export: Error when exporting a target without a language First, it prevents a NULL dereference and second it reiterates that targets without languages are not supported by CMake. Add a RunCMake.ExportWithoutLanguage test exporting a library without a languages.
2013-07-23 01:25:21 +04:00
add_RunCMake_test(ExportWithoutLanguage)
target_link_libraries: Add PUBLIC/PRIVATE/INTERFACE keyword signature Add a new signature to help populate INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES cleanly in a single call. Add policy CMP0023 to control whether the keyword signatures can be mixed with uses of the plain signatures on the same target.
2013-06-04 18:21:33 +04:00
add_RunCMake_test(target_link_libraries)