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
- Option was recently added but never released.
- Custom commands no longer depend on build.make so we do
not need the option.
- Rule hashes now take care of rebuilding when rules change
so the dependency is not needed.
- Tests IMPLICIT_DEPENDS_INCLUDE_TRANSFORM properties.
- See issue #6648.
- Works without help in VS IDEs due to native dependency handling.
- Xcode needs help to rebuild correctly.
- Allows make rules to be created with no dependencies.
- Such rules will not re-run even if the commands themselves change.
- Useful to create rules that run only if the output is missing.
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- This will help projects support multiple CMake versions.
- In order to set a policy when using a newer CMake but still
working with an older CMake one may write
if(POLICY CMP1234)
cmake_policy(SET CMP1234 NEW)
endif(POLICY CMP1234)
- Note that since CMake 2.4 does not have if(POLICY) supporting
it will also require using "if(COMMAND cmake_policy)"
- Remove CMP_0001 (no slash in target name) and restore
old CMAKE_BACKWARDS_COMPATIBILITY check for it
- Replace all checks of CMAKE_BACKWARDS_COMPATIBILITY
with cmLocalGenerator::NeedBackwardsCompatibility calls
- Create new CMP_0001 to determine whether or not
CMAKE_BACKWARDS_COMPATIBILITY is used.
(old = use, new = ignore)
- Show CMAKE_BACKWARDS_COMPATIBILITY in cache only when
CMP_0001 is set to OLD or WARN
- Update documentation of cmake_policy and cmake_minimum_required
to indicate their relationship and the 2.4 version boundary
- When no cmake policy version is set in top level makefile
implicitly call cmake_policy(VERSION 2.4) which restores
CMAKE_BACKWARDS_COMPATIBILITY and other 2.4 compatibility
- Fix tests MakeClean and Preprocess to call
cmake_policy(VERSION 2.6) because they depend on new policies
- Motivation:
- It depended on the order of installation
- It supported only a single destination for each target
- It created directory portions of an install name without user request
- Updated ExportImport test to install targets in an order that expoed
this bug
- Split IMPORTED_LINK_LIBRARIES into two parts:
IMPORTED_LINK_INTERFACE_LIBRARIES
IMPORTED_LINK_DEPENDENT_LIBRARIES
- Add CMAKE_DEPENDENT_SHARED_LIBRARY_MODE to select behavior
- Set mode to LINK for Darwin (fixes universal binary problem)
- Update ExportImport test to account for changes
- Added EXACT option to request an exact version.
- Enforce version using check provided by package.
- Updated FindPackageTest to test versioning in config mode.
- Imported bundles have the MACOSX_BUNDLE property set
- Added cmTarget::IsAppBundleOnApple method to simplify checks
- Document BUNDLE keyword in INSTALL command
- Updated IMPORTED_LOCATION property documentation for bundles
- Updated ExportImport test to test bundles
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
major issues:
-access() doesn't return false for an empty string (#ifdefed in cmake)
-dlopen() doesn't return 0 on failure (#ifdefed in cmake and fixed now in Syllable)
-the kwsys and Bootstrap tests fail with timeout due to the fact that I'm doing all that in qemu, which is quite slow
-RPATH is now supported, so without modifying the test adapting DLL_PATH in Syllable is required for the tests to succeed
-the Plugin test fails with an undefined reference to example_exe_function() in example_mod_1, it seems this isn't supported under Syllable
Alex
CMAKE_FIND_PREFIX_PATH is both an environment variable and a cmake variable,
which is a list of base directories where FIND_PATH, FIND_FILE, FIND_PROGRAM
and FIND_LIBRARY will search in the respective subdirectories
Alex
and which is more useful, because then you can also access the item behind
the one you were looking, useful for writing macros with optional keywords
with parameters
Alex
check_c_source_compiles() and check_cxx_source_compiles()
-TRY_RUN in crosscompiling mode: copy the created executables to
CMAKE_BINARY_DIR so the user can run them manually on the target
Alex
working, for both the result was always empty, since
cmMakefile::GetProperty() recognized it as a special property, constructed a
correct return value and called cmMakefile::SetProperty() with this list of
directories, which then didn't actually set the property, but applied it to
the internal vector of include/link directories. The following
getPropertyValue in cmMakefile::GetProperty() then still didn't find it and
returned nothing. Now for all special property the static string output is
used and its content is returned. I'm not sure it is the right way to fix
this problem but at least it seems to work and it fixes the Paraview3 build
Alex
CMAKE_SYSTEM_AND_C_COMPILER_INFO_FILE, CMAKE_SYSTEM_AND_CXX_COMPILER_INFO_FILE,
CMAKE_SYSTEM_AND_C_COMPILER_AND_PROCESSOR_INFO_FILE and CMAKE_SYSTEM_AND_CXX_COMPILER_AND_PROCESSOR_INFO_FILE
Instead of presetting these variables to arbitrary filenames, users should
set up CMAKE_SYSTEM_NAME and the compilers correctly and also create a
Platform/ directory so these files will all follow the official cmake style,
which should make it easier to understand and debug project which have their
own platform/toolchain support files.
-remove support for a suffix to MS crosscompilers, since this is not (yet)
supported by cmake and might confuse users
Alex
creates two cache variables, one for the RUN_RESULT, one for the RUN_OUTPUT
(if required), which can be set or preset by the user. It has now also two
new arguments: RUN_OUTPUT_VARIABLE and COMPILE_OUTPUT_VARIABLE (the old
OUTPUT_VARIABLE merges both), so if only COMPILE_OUTPUT_VARIABLE is used the
run time output of the TRY_RUN is unused and the user doesn't have to care
about the output when crosscompiling. This is now used in FindThreads.cmake,
CheckC/CXXSourceRuns.cmake and TestBigEndian.cmake, which used the output
only for the logfile (compile output is still there). Test/TryCompile/ now
also tests the behaviour of OUTPUT_VARIABLE, RUN_OUTPUT_VARIABLE and
COMPILE_OUTPUT_VARIABLE.
Alex
STYLE: create a new base class cmCoreTryCompile, from which
cmTryCompileCommand and cmTryRunCommand are derived, so there are no public
static functions with lots of arguments anymore
Alex
-add a RESULT_VARIABLE to INCLUDE()
-add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain
-have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system)
-use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to
run the executables if they have a different suffix because they are
probably crosscompiled, but nevertheless it should be able to find them
-make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE
-support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.)
-move ranlib on OSX from the file command to a command in executed in cmake_install.cmake
-add support for stripping during install in cmake_install.cmake
-split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools
-remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms
-create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these
-add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a
list of directories which will be prepended to all search directories, right
now as a cmake variable, turning it into a global cmake property may need
some more work
-remove cmTestTestHandler::TryExecutable(), it's unused
-split cmFileCommand::HandleInstall() into slightly smaller functions
Alex
Brad King
David Cole
Bill Hoffman
Alexander Neundorf
Ken Martin
Sebastien Barre
Andy Cedilnik