The new 'testing' test behavior of actually running the tests generated
by the project still fails when the test script guesses the Debug
configuration but the CMake build tree was only built Release. The
inner ctest needs to find the ctest executable but is given the wrong
configuration.
The recent change of the 'testing' test to actually drive the tests
within it does not work on Windows with released CMakes 2.6.2 and lower
if no configuration is given to ctest with a -C option. This works
around the problem by detecting the case and changing the empty
configuration to Debug.
On Windows the KWSys System package generates escapes for command-line
arguments. This fix enables quoting of the empty string as an argument.
This also adds a test to pass an empty argument to a custom command.
The 'testing' CMake test builds a project that uses add_test. This
strengthens the test to actually run CTest on the project build tree
after building it.
We now search in
<prefix>/<name>*/
<prefix>/<name>*/(cmake|CMake)
when looking for package configuration files. This is useful on Windows
since the Program Files folder is in CMAKE_SYSTEM_PREFIX_PATH. These
paths are the Windows equivalent to the Apple convention application and
framework paths we already search. See issue #8264.
The $ENV{VAR} syntax permits access to environment variables. This
teaches CMake to recognize most characters in the VAR name since some
environments may have variables with non-C-identifier characters.
The previous change to test finding in lib/cmake/<name>* weakened the
versioned find tests. Since the lib/cmake paths are searched before
lib/<name>* paths the previous change skipped requiring the command to
ignore zot-3.0 when finding zot-3.1. This change restores that and adds
zot-4.0 to test the lib/cmake path.
This teaches find_package to search
<prefix>/(share|lib)/cmake/<name>*/
for package configuration files. Packages that do not already have
files in a <prefix>/lib/<name>* directory can use this location to avoid
cluttering the lib directory.
When CMake is built by CMake 2.4 or lower the FindCVS module is not
available. In that case we activiate CTest.UpdateCVS by searching for
the cvs command directly.
This creates new tests "CTest.UpdateSVN" and "CTest.UpdateCVS". They
test that the Update.xml produced by CTest for a version-controlled
project contains entries for files added, changed, and removed.
This adds a SOURCES option to ADD_CUSTOM_TARGET, enabling users to
specify extra sources for inclusion in the target. Such sources may not
build, but will show up in the IDE project files for convenient editing.
See issue #5848.
Recently we taught find_package that the NO_MODULE option is implied
when it is recursively invoked in a find-module. This behavior may be
confusing because two identical calls may enter different modes
depending on context. It also disallows the possibility that one
find-module defers to another find-module by changing CMAKE_MODULE_PATH
and recursively invoking find_package. This change reverts the feature.
Package version test files may now declare that they are unsuitable for
use with the project testing them. This is important when the version
being tested does not provide a compatible ABI with the project target
environment.
These changes teach find_package to behave nicely when invoked
recursively inside a find-module for the same package. The module will
never be recursively loaded again. Version arguments are automatically
forwarded.
Provide VERSION_LESS, VERSION_EQUAL, and VERSION_GREATER operators in
the if() command. This simplifies component-wise comparison of version
numbers in the form "major[.minor[.patch[.tweak]]]".
Make the number of version components specified explicitly available.
Set variables for unspecified version components to "0" instead of
leaving them unset. This simplifies version number handling for find-
and config-modules. Also support a fourth "tweak" version component
since some packages use them.
This introduces the unset() command to make it easy to unset CMake
variables, environment variables, and CMake cache variables. Previously
it was not even possible to unset ENV or CACHE variables (as in
completely remove them). Changes based on patch from Philip Lowman.
See issue #7507.
Some native build tools, particularly those for cross compiling, may
have a limit on the length of the full path to an object file name that
is lower than the platform otherwise supports. This change allows the
limit to be set by the project toolchain file through the variable
CMAKE_OBJECT_PATH_MAX.
It is useful to be able to test if a target has been created. Often
targets are created only inside conditions. Rather than storing the
result of the condition manually for testing by other parts of the
project, it is much easier for the other parts to just test for the
target's existence. This will also be useful when find-modules start
reporting results with IMPORTED targets and projects want to test if a
certain target is available.
We frequently need to wipe out all the CMake test build directories in
order to run tests from scratch. This change adds a test_clean custom
target to remove all these directories for out-of-source builds.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
It is likely that projects or CMake modules in the future will need to
check the value of a policy setting. For example, if we add a policy
that affects the results of FindXYZ.cmake modules, the module code will
need to be able to check the policy.
A recent change fixed a case in which CMake incorrectly diagnosed a
circular dependency involving a non-linkable executable target. This
adds a test for that case.
As of CMake 2.6 a custom command output specified by relative path is
placed in the build tree. This adds a test to make sure other
references to the output are hooked up correctly, fixing a bug in CMake
2.6.1.
- Previously the find_* commands did not normalize the search paths
- The recent refactoring enabled such normalization
- The FindBase test must also normalize before comparing paths
Brad King
Bill Hoffman
David Cole
Alexander Neundorf
Ken Martin