Provided by: cmake-mozilla-data_3.16.3-1ubuntu1~18.04_all 
NAME
cmake-policies - CMake Policies Reference
INTRODUCTION
Policies in CMake are used to preserve backward compatible behavior across multiple
releases. When a new policy is introduced, newer CMake versions will begin to warn about
the backward compatible behavior. It is possible to disable the warning by explicitly
requesting the OLD, or backward compatible behavior using the cmake_policy() command. It
is also possible to request NEW, or non-backward compatible behavior for a policy, also
avoiding the warning. Each policy can also be set to either NEW or OLD behavior
explicitly on the command line with the CMAKE_POLICY_DEFAULT_CMP<NNNN> variable.
A policy is a deprecation mechanism and not a reliable feature toggle. A policy should
almost never be set to OLD, except to silence warnings in an otherwise frozen or stable
codebase, or temporarily as part of a larger migration path. The OLD behavior of each
policy is undesirable and will be replaced with an error condition in a future release.
The cmake_minimum_required() command does more than report an error if a too-old version
of CMake is used to build a project. It also sets all policies introduced in that CMake
version or earlier to NEW behavior. To manage policies without increasing the minimum
required CMake version, the if(POLICY) command may be used:
if(POLICY CMP0990)
cmake_policy(SET CMP0990 NEW)
endif()
This has the effect of using the NEW behavior with newer CMake releases which users may be
using and not issuing a compatibility warning.
The setting of a policy is confined in some cases to not propagate to the parent scope.
For example, if the files read by the include() command or the find_package() command
contain a use of cmake_policy(), that policy setting will not affect the caller by
default. Both commands accept an optional NO_POLICY_SCOPE keyword to control this
behavior.
The CMAKE_MINIMUM_REQUIRED_VERSION variable may also be used to determine whether to
report an error on use of deprecated macros or functions.
POLICIES INTRODUCED BY CMAKE 3.16
CMP0097
ExternalProject_Add() with GIT_SUBMODULES "" initializes no submodules.
The module provides a GIT_SUBMODULES option which controls what submodules to initialize
and update. Starting with CMake 3.16, explicitly setting GIT_SUBMODULES to an empty string
means no submodules will be initialized or updated.
This policy provides compatibility for projects that have not been updated to expect the
new behavior.
The OLD behavior for this policy is for GIT_SUBMODULES when set to an empty string to
initialize and update all git submodules. The NEW behavior for this policy is for
GIT_SUBMODULES when set to an empty string to initialize and update no git submodules.
This policy was introduced in CMake version 3.16. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
CMP0096
The project() command preserves leading zeros in version components.
When a VERSION <major>[.<minor>[.<patch>[.<tweak>]]]] argument is given to the project()
command, it stores the version string in the PROJECT_VERSION variable and stores
individual integer version components in PROJECT_VERSION_{MAJOR,MINOR,PATCH,TWEAK}
variables (see policy CMP0048). CMake 3.15 and below dropped leading zeros from each
component. CMake 3.16 and higher prefer to preserve leading zeros. This policy provides
compatibility for projects that have not been updated to expect the new behavior.
The OLD behavior of this policy drops leading zeros in all components, e.g. such that
version 1.07.06 becomes 1.7.6. The NEW behavior of this policy preserves the leading
zeros in all components, such that version 1.07.06 remains unchanged.
This policy was introduced in CMake version 3.16. Unlike many policies, CMake version
3.16.3 does not warn when this policy is not set and simply uses the OLD behavior. Use
the cmake_policy() command to set it to OLD or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0095
RPATH entries are properly escaped in the intermediary CMake install script.
In CMake 3.15 and earlier, RPATH entries set via CMAKE_INSTALL_RPATH or via INSTALL_RPATH
have not been escaped before being inserted into the cmake_install.cmake script. Dynamic
linkers on ELF-based systems (e.g. Linux and FreeBSD) allow certain keywords in RPATH
entries, such as ${ORIGIN} (More details are available in the ld.so man pages on those
systems). The syntax of these keywords can match CMake's variable syntax. In order to not
be substituted (usually to an empty string) already by the intermediary
cmake_install.cmake script, the user had to double-escape such RPATH keywords, e.g.
set(CMAKE_INSTALL_RPATH "\\\${ORIGIN}/../lib"). Since the intermediary cmake_install.cmake
script is an implementation detail of CMake, CMake 3.16 and later will make sure RPATH
entries are inserted literally by escaping any coincidental CMake syntax.
The OLD behavior of this policy is to not escape RPATH entries in the intermediary
cmake_install.cmake script. The NEW behavior is to properly escape coincidental CMake
syntax in RPATH entries when generating the intermediary cmake_install.cmake script.
This policy was introduced in CMake version 3.16. CMake version 3.16.3 warns when the
policy is not set and detected usage of CMake-like syntax and uses OLD behavior. Use the
cmake_policy() command to set it to OLD or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.15
CMP0094
Modules FindPython3, FindPython2 and FindPython use LOCATION for lookup strategy.
Starting with CMake 3.15, Modules FindPython3, FindPython2 and FindPython set value
LOCATION for, respectively, variables Python3_FIND_STRATEGY, Python2_FIND_STRATEGY and
Python_FIND_STRATEGY. This policy provides compatibility with projects that expect the
legacy behavior.
The OLD behavior for this policy set value VERSION for variables Python3_FIND_STRATEGY,
Python2_FIND_STRATEGY and Python_FIND_STRATEGY.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike many policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses the OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0093
FindBoost reports Boost_VERSION in x.y.z format.
In CMake 3.14 and below the module would report the Boost version number as specified in
the preprocessor definition BOOST_VERSION in the boost/version.hpp file. In CMake 3.15 and
later it is preferred that the reported version number matches the x.y.z format reported
by the CMake package shipped with Boost 1.70.0 and later. The macro value is still
reported in the Boost_VERSION_MACRO variable.
The OLD behavior for this policy is for FindBoost to report Boost_VERSION as specified in
the preprocessor definition BOOST_VERSION in boost/version.hpp. The NEW behavior for this
policy is for FindBoost to report Boost_VERSION in x.y.z format.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike many policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses the OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0092
MSVC warning flags are not in CMAKE_<LANG>_FLAGS by default.
When using MSVC-like compilers in CMake 3.14 and below, warning flags like /W3 are added
to CMAKE_<LANG>_FLAGS by default. This is problematic for projects that want to choose a
different warning level programmatically. In particular, it requires string editing of
the CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin defaults so they can
be replaced.
CMake 3.15 and above prefer to leave out warning flags from the value of
CMAKE_<LANG>_FLAGS by default.
This policy provides compatibility with projects that have not been updated to expect the
lack of warning flags. The policy setting takes effect as of the first project() or
enable_language() command that initializes CMAKE_<LANG>_FLAGS for a given lanuage <LANG>.
NOTE:
Once the policy has taken effect at the top of a project for a given language, that
choice must be used throughout the tree for that language. In projects that have
nested projects in subdirectories, be sure to convert everything together.
The OLD behavior for this policy is to place MSVC warning flags in the default
CMAKE_<LANG>_FLAGS cache entries. The NEW behavior for this policy is to not place MSVC
warning flags in the default cache entries.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike many policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0091
MSVC runtime library flags are selected by an abstraction.
Compilers targeting the MSVC ABI have flags to select the MSVC runtime library. Runtime
library selection typically varies with build configuration because there is a separate
runtime library for Debug builds.
In CMake 3.14 and below, MSVC runtime library selection flags are added to the default
CMAKE_<LANG>_FLAGS_<CONFIG> cache entries by CMake automatically. This allows users to
edit their cache entries to adjust the flags. However, the presence of such default flags
is problematic for projects that want to choose a different runtime library
programmatically. In particular, it requires string editing of the
CMAKE_<LANG>_FLAGS_<CONFIG> variables with knowledge of the CMake builtin defaults so they
can be replaced.
CMake 3.15 and above prefer to leave the MSVC runtime library selection flags out of the
default CMAKE_<LANG>_FLAGS_<CONFIG> values and instead offer a first-class abstraction.
The CMAKE_MSVC_RUNTIME_LIBRARY variable and MSVC_RUNTIME_LIBRARY target property may be
set to select the MSVC runtime library. If they are not set then CMake uses the default
value MultiThreaded$<$<CONFIG:Debug>:Debug>DLL which is equivalent to the original flags.
This policy provides compatibility with projects that have not been updated to be aware of
the abstraction. The policy setting takes effect as of the first project() or
enable_language() command that enables a language whose compiler targets the MSVC ABI.
NOTE:
Once the policy has taken effect at the top of a project, that choice must be used
throughout the tree. In projects that have nested projects in subdirectories, be sure
to convert everything together.
The OLD behavior for this policy is to place MSVC runtime library flags in the default
CMAKE_<LANG>_FLAGS_<CONFIG> cache entries and ignore the CMAKE_MSVC_RUNTIME_LIBRARY
abstraction. The NEW behavior for this policy is to not place MSVC runtime library flags
in the default cache entries and use the abstraction instead.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike many policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0090
export(PACKAGE) does not populate package registry by default.
In CMake 3.14 and below the export(PACKAGE) command populated the user package registry by
default and users needed to set the CMAKE_EXPORT_NO_PACKAGE_REGISTRY to disable it, e.g.
in automated build and packaging environments. Since the user package registry is stored
outside the build tree, this side effect should not be enabled by default. Therefore
CMake 3.15 and above prefer that export(PACKAGE) does nothing unless an explicit
CMAKE_EXPORT_PACKAGE_REGISTRY variable is set to enable it. This policy provides
compatibility with projects that have not been updated.
The OLD behavior for this policy is for export(PACKAGE) command to populate the user
package registry unless CMAKE_EXPORT_NO_PACKAGE_REGISTRY is enabled. The NEW behavior is
for export(PACKAGE) command to do nothing unless the CMAKE_EXPORT_PACKAGE_REGISTRY is
enabled.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0089
Compiler id for IBM Clang-based XL compilers is now XLClang.
CMake 3.15 and above recognize that IBM's Clang-based XL compilers that define __ibmxl__
are a new front-end distinct from xlc with a different command line and set of
capabilities. CMake now prefers to present this to projects by setting the
CMAKE_<LANG>_COMPILER_ID variable to XLClang instead of XL. However, existing projects
may assume the compiler id for Clang-based XL is just XL as it was in CMake versions prior
to 3.15. Therefore this policy determines for Clang-based XL compilers which compiler id
to report in the CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the
project() or enable_language() command. The policy must be set prior to the invocation of
either command.
The OLD behavior for this policy is to use compiler id XL. The NEW behavior for this
policy is to use compiler id XLClang.
This policy was introduced in CMake version 3.15. Use the cmake_policy() command to set
this policy to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not
warn by default when this policy is not set and simply uses OLD behavior. See
documentation of the CMAKE_POLICY_WARNING_CMP0089 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.14
CMP0088
FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR when executing.
The module provides a BISON_TARGET macro which generates BISON output. In CMake 3.13 and
below the macro would generate a custom command that runs bison in the source directory.
CMake 3.14 and later prefer to run it in the build directory and use
CMAKE_CURRENT_BINARY_DIR as the WORKING_DIRECTORY of its add_custom_command() invocation.
This ensures that any implicitly generated file is written to the build tree rather than
the source.
This policy provides compatibility for projects that have not been updated to expect the
new behavior.
The OLD behavior for this policy is for BISON_TARGET to use the current source directory
for the WORKING_DIRECTORY and where to generate implicit files. The NEW behavior of this
policy is to use the current binary directory for the WORKING_DIRECTORY and where to
generate implicit files.
This policy was introduced in CMake version 3.14. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0087
install(CODE) and install(SCRIPT) support generator expressions.
In CMake 3.13 and earlier, install(CODE) and install(SCRIPT) did not evaluate generator
expressions. CMake 3.14 and later will evaluate generator expressions for install(CODE)
and install(SCRIPT).
The OLD behavior of this policy is for install(CODE) and install(SCRIPT) to not evaluate
generator expressions. The NEW behavior is to evaluate generator expressions for
install(CODE) and install(SCRIPT).
Note that it is the value of this policy setting at the end of the directory scope that is
important, not its setting at the time of the call to install(CODE) or install(SCRIPT).
This has implications for calling these commands from places that have their own policy
scope but not their own directory scope (e.g. from files brought in via include() rather
than add_subdirectory()).
This policy was introduced in CMake version 3.14. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0086
UseSWIG honors SWIG_MODULE_NAME via -module flag.
Starting with CMake 3.14, UseSWIG passes option -module <module_name> to SWIG compiler if
the file property SWIG_MODULE_NAME is specified. This policy provides compatibility with
projects that expect the legacy behavior.
The OLD behavior for this policy is to never pass -module option. The NEW behavior is to
pass -module option to SWIG compiler if SWIG_MODULE_NAME is specified.
This policy was introduced in CMake version 3.14. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0085
$<IN_LIST:...> handles empty list items.
In CMake 3.13 and lower, the $<IN_LIST:...> generator expression always returned 0 if the
first argument was empty, even if the list contained an empty item. This behavior is
inconsistent with the IN_LIST behavior of if(), which this generator expression is meant
to emulate. CMake 3.14 and later handles this case correctly.
The OLD behavior of this policy is for $<IN_LIST:...> to always return 0 if the first
argument is empty. The NEW behavior is to return 1 if the first argument is empty and the
list contains an empty item.
This policy was introduced in CMake version 3.14. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0084
The FindQt module does not exist for find_package().
The existence of FindQt means that for Qt upstream to provide package config files that
can be found by find_package(Qt), the consuming project has to explicitly specify
find_package(Qt CONFIG). Removing this module gives Qt a path forward for exporting its
own config files which can easily be found by consuming projects.
This policy pretends that CMake's internal FindQt module does not exist for
find_package(). If a project really wants to use Qt 3 or 4, it can call
find_package(Qt[34]), include(FindQt), or add FindQt to their CMAKE_MODULE_PATH.
The OLD behavior of this policy is for FindQt to exist for find_package(). The NEW
behavior is to pretend that it doesn't exist for find_package().
This policy was introduced in CMake version 3.14. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0083
To control generation of Position Independent Executable (PIE) or not, some flags are
required at link time.
CMake 3.13 and lower did not add these link flags when POSITION_INDEPENDENT_CODE is set.
The OLD behavior for this policy is to not manage PIE link flags. The NEW behavior is to
add link flags if POSITION_INDEPENDENT_CODE is set:
• Set to TRUE: flags to produce a position independent executable are passed to the linker
step. For example -pie for GCC.
• Set to FALSE: flags not to produce a position independent executable are passed to the
linker step. For example -no-pie for GCC.
• Not set: no flags are passed to the linker step.
Since a given linker may not support PIE flags in all environments in which it is used, it
is the project's responsibility to use the CheckPIESupported module to check for support
to ensure that the POSITION_INDEPENDENT_CODE target property for executables will be
honored at link time.
This policy was introduced in CMake version 3.14. Use the cmake_policy() command to set it
to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not warn when
this policy is not set and simply uses OLD behavior.
NOTE:
Android platform has a special handling of PIE so it is not required to use the
CheckPIESupported module to ensure flags are passed to the linker.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
Examples
Behave like CMake 3.13 and do not apply any PIE flags at link stage.
cmake_minimum_required(VERSION 3.13)
project(foo)
# ...
add_executable(foo ...)
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)
Use the CheckPIESupported module to detect whether PIE is supported by the current linker
and environment. Apply PIE flags only if the linker supports them.
cmake_minimum_required(VERSION 3.14) # CMP0083 NEW
project(foo)
include(CheckPIESupported)
check_pie_supported()
# ...
add_executable(foo ...)
set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)
CMP0082
Install rules from add_subdirectory() calls are interleaved with those in caller.
CMake 3.13 and lower ran the install rules from add_subdirectory() after all other install
rules, even if add_subdirectory() was called before the other install rules. CMake 3.14
and above prefer to interleave these add_subdirectory() install rules with the others so
that they are run in the order they are declared. This policy provides compatibility for
projects that have not been updated to expect the new behavior.
The OLD behavior for this policy is to run the install rules from add_subdirectory() after
the other install rules. The NEW behavior for this policy is to run all install rules in
the order they are declared.
This policy was introduced in CMake version 3.14. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0082 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.13
CMP0081
Relative paths not allowed in LINK_DIRECTORIES target property.
CMake 3.12 and lower allowed the LINK_DIRECTORIES directory property to contain relative
paths. The base path for such relative entries is not well defined. CMake 3.13 and later
will issue a FATAL_ERROR if the LINK_DIRECTORIES target property (which is initialized by
the LINK_DIRECTORIES directory property) contains a relative path.
The OLD behavior for this policy is not to warn about relative paths in the
LINK_DIRECTORIES target property. The NEW behavior for this policy is to issue a
FATAL_ERROR if LINK_DIRECTORIES contains a relative path.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0080
BundleUtilities cannot be included at configure time.
The macros provided by BundleUtilities are intended to be invoked at install time rather
than at configure time, because they depend on the listed targets already existing at the
time they are invoked. If they are invoked at configure time, the targets haven't been
built yet, and the commands will fail.
This policy restricts the inclusion of BundleUtilities to cmake -P style scripts and
install rules. Specifically, it looks for the presence of CMAKE_GENERATOR and throws a
fatal error if it exists.
The OLD behavior of this policy is to allow BundleUtilities to be included at configure
time. The NEW behavior of this policy is to disallow such inclusion.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0079
target_link_libraries() allows use with targets in other directories.
Prior to CMake 3.13 the target_link_libraries() command did not accept targets not created
in the calling directory as its first argument for calls that update the LINK_LIBRARIES of
the target itself. It did accidentally accept targets from other directories on calls
that only update the INTERFACE_LINK_LIBRARIES, but would simply add entries to the
property as if the call were made in the original directory. Thus link interface
libraries specified this way were always looked up by generators in the scope of the
original target rather than in the scope that called target_link_libraries().
CMake 3.13 now allows the target_link_libraries() command to be called from any directory
to add link dependencies and link interface libraries to targets created in other
directories. The entries are added to LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES using a
special (internal) suffix to tell the generators to look up the names in the calling scope
rather than the scope that created the target.
This policy provides compatibility with projects that already use target_link_libraries()
with the INTERFACE keyword on a target in another directory to add
INTERFACE_LINK_LIBRARIES entries to be looked up in the target's directory. Such projects
should be updated to be aware of the new scoping rules in that case.
The OLD behavior of this policy is to disallow target_link_libraries() calls naming
targets from another directory except in the previously accidentally allowed case of using
the INTERFACE keyword only. The NEW behavior of this policy is to allow all such calls
but use the new scoping rules.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0078
UseSWIG generates standard target names.
Starting with CMake 3.13, UseSWIG generates now standard target names. This policy
provides compatibility with projects that expect the legacy behavior.
The OLD behavior for this policy relies on UseSWIG_TARGET_NAME_PREFERENCE variable that
can be used to specify an explicit preference. The value may be one of:
• LEGACY: legacy strategy is applied. Variable SWIG_MODULE_<name>_REAL_NAME must be used
to get real target name. This is the default if not specified.
• STANDARD: target name matches specified name.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0077
option() honors normal variables.
The option() command is typically used to create a cache entry to allow users to set the
option. However, there are cases in which a normal (non-cached) variable of the same name
as the option may be defined by the project prior to calling the option() command. For
example, a project that embeds another project as a subdirectory may want to hard-code
options of the subproject to build the way it needs.
For historical reasons in CMake 3.12 and below the option() command removes a normal
(non-cached) variable of the same name when:
• a cache entry of the specified name does not exist at all, or
• a cache entry of the specified name exists but has not been given a type (e.g. via
-D<name>=ON on the command line).
In both of these cases (typically on the first run in a new build tree), the option()
command gives the cache entry type BOOL and removes any normal (non-cached) variable of
the same name. In the remaining case that the cache entry of the specified name already
exists and has a type (typically on later runs in a build tree), the option() command
changes nothing and any normal variable of the same name remains set.
In CMake 3.13 and above the option() command prefers to do nothing when a normal variable
of the given name already exists. It does not create or update a cache entry or remove
the normal variable. The new behavior is consistent between the first and later runs in a
build tree. This policy provides compatibility with projects that have not been updated
to expect the new behavior.
When the option() command sees a normal variable of the given name:
• The OLD behavior for this policy is to proceed even when a normal variable of the same
name exists. If the cache entry does not already exist and have a type then it is
created and/or given a type and the normal variable is removed.
• The NEW behavior for this policy is to do nothing when a normal variable of the same
name exists. The normal variable is not removed. The cache entry is not created or
updated and is ignored if it exists.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0076
The target_sources() command converts relative paths to absolute.
In CMake 3.13 and above, the target_sources() command now converts relative source file
paths to absolute paths in the following cases:
• Source files are added to the target's INTERFACE_SOURCES property.
• The target's SOURCE_DIR property differs from CMAKE_CURRENT_SOURCE_DIR.
A path that begins with a generator expression is always left unmodified.
This policy provides compatibility with projects that have not been updated to expect this
behavior. The OLD behavior for this policy is to leave all relative source file paths
unmodified. The NEW behavior of this policy is to convert relative paths to absolute
according to above rules.
This policy was introduced in CMake version 3.13. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.12
CMP0075
Include file check macros honor CMAKE_REQUIRED_LIBRARIES.
In CMake 3.12 and above, the
• check_include_file macro in the CheckIncludeFile module, the
• check_include_file_cxx macro in the CheckIncludeFileCXX module, and the
• check_include_files macro in the CheckIncludeFiles module
now prefer to link the check executable to the libraries listed in the
CMAKE_REQUIRED_LIBRARIES variable. This policy provides compatibility with projects that
have not been updated to expect this behavior.
The OLD behavior for this policy is to ignore CMAKE_REQUIRED_LIBRARIES in the include file
check macros. The NEW behavior of this policy is to honor CMAKE_REQUIRED_LIBRARIES in the
include file check macros.
This policy was introduced in CMake version 3.12. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0074
find_package() uses <PackageName>_ROOT variables.
In CMake 3.12 and above the find_package(<PackageName>) command now searches prefixes
specified by the <PackageName>_ROOT CMake variable and the <PackageName>_ROOT environment
variable. Package roots are maintained as a stack so nested calls to all find_* commands
inside find modules and config packages also search the roots as prefixes. This policy
provides compatibility with projects that have not been updated to avoid using
<PackageName>_ROOT variables for other purposes.
The OLD behavior for this policy is to ignore <PackageName>_ROOT variables. The NEW
behavior for this policy is to use <PackageName>_ROOT variables.
This policy was introduced in CMake version 3.12. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0073
Do not produce legacy _LIB_DEPENDS cache entries.
Ancient CMake versions once used <tgt>_LIB_DEPENDS cache entries to propagate library link
dependencies. This has long been done by other means, leaving the
export_library_dependencies() command as the only user of these values. That command has
long been disallowed by policy CMP0033, but the <tgt>_LIB_DEPENDS cache entries were left
for compatibility with possible non-standard uses by projects.
CMake 3.12 and above now prefer to not produce these cache entries at all. This policy
provides compatibility with projects that have not been updated to avoid using them.
The OLD behavior for this policy is to set <tgt>_LIB_DEPENDS cache entries. The NEW
behavior for this policy is to not set them.
This policy was introduced in CMake version 3.12. Use the cmake_policy() command to set
it to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not warn
when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.11
CMP0072
FindOpenGL prefers GLVND by default when available.
The FindOpenGL module provides an OpenGL::GL target and an OPENGL_LIBRARIES variable for
projects to use for legacy GL interfaces. When both a legacy GL library (e.g. libGL.so)
and GLVND libraries for OpenGL and GLX (e.g. libOpenGL.so and libGLX.so) are available,
the module must choose between them. It documents an OpenGL_GL_PREFERENCE variable that
can be used to specify an explicit preference. When no such preference is set, the module
must choose a default preference.
CMake 3.11 and above prefer to choose GLVND libraries. This policy provides compatibility
with projects that expect the legacy GL library to be used.
The OLD behavior for this policy is to set OpenGL_GL_PREFERENCE to LEGACY. The NEW
behavior for this policy is to set OpenGL_GL_PREFERENCE to GLVND.
This policy was introduced in CMake version 3.11. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.10
CMP0071
Let AUTOMOC and AUTOUIC process GENERATED files.
Since version 3.10, CMake processes regular and GENERATED source files in AUTOMOC and
AUTOUIC. In earlier CMake versions, only regular source files were processed. GENERATED
source files were ignored silently.
This policy affects how source files that are GENERATED get treated in AUTOMOC and
AUTOUIC.
The OLD behavior for this policy is to ignore GENERATED source files in AUTOMOC and
AUTOUIC.
The NEW behavior for this policy is to process GENERATED source files in AUTOMOC and
AUTOUIC just like regular source files.
NOTE:
To silence the CMP0071 warning source files can be excluded from AUTOMOC and AUTOUIC
processing by setting the source file properties SKIP_AUTOMOC, SKIP_AUTOUIC or
SKIP_AUTOGEN.
Source skip example:
# ...
set_property(SOURCE /path/to/file1.h PROPERTY SKIP_AUTOMOC ON)
set_property(SOURCE /path/to/file2.h PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE /path/to/file3.h PROPERTY SKIP_AUTOGEN ON)
# ...
This policy was introduced in CMake version 3.10. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0070
Define file(GENERATE) behavior for relative paths.
CMake 3.10 and newer define that relative paths given to INPUT and OUTPUT arguments of
file(GENERATE) are interpreted relative to the current source and binary directories,
respectively. CMake 3.9 and lower did not define any behavior for relative paths but did
not diagnose them either and accidentally treated them relative to the process working
directory. Policy CMP0070 provides compatibility with projects that used the old
undefined behavior.
This policy affects behavior of relative paths given to file(GENERATE). The OLD behavior
for this policy is to treat the paths relative to the working directory of CMake. The NEW
behavior for this policy is to interpret relative paths with respect to the current source
or binary directory of the caller.
This policy was introduced in CMake version 3.10. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.9
CMP0069
INTERPROCEDURAL_OPTIMIZATION is enforced when enabled.
CMake 3.9 and newer prefer to add IPO flags whenever the INTERPROCEDURAL_OPTIMIZATION
target property is enabled and produce an error if flags are not known to CMake for the
current compiler. Since a given compiler may not support IPO flags in all environments in
which it is used, it is now the project's responsibility to use the CheckIPOSupported
module to check for support before enabling the INTERPROCEDURAL_OPTIMIZATION target
property. This approach allows a project to conditionally activate IPO when supported.
It also allows an end user to set the CMAKE_INTERPROCEDURAL_OPTIMIZATION variable in an
environment known to support IPO even if the project does not enable the property.
Since CMake 3.8 and lower only honored INTERPROCEDURAL_OPTIMIZATION for the Intel compiler
on Linux, some projects may unconditionally enable the target property. Policy CMP0069
provides compatibility with such projects.
This policy takes effect whenever the IPO property is enabled. The OLD behavior for this
policy is to add IPO flags only for Intel compiler on Linux. The NEW behavior for this
policy is to add IPO flags for the current compiler or produce an error if CMake does not
know the flags.
This policy was introduced in CMake version 3.9. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
Examples
Behave like CMake 3.8 and do not apply any IPO flags except for Intel compiler on Linux:
cmake_minimum_required(VERSION 3.8)
project(foo)
# ...
set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
Use the CheckIPOSupported module to detect whether IPO is supported by the current
compiler, environment, and CMake version. Produce a fatal error if support is not
available:
cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)
include(CheckIPOSupported)
check_ipo_supported()
# ...
set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
Apply IPO flags only if compiler supports it:
cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)
include(CheckIPOSupported)
# ...
check_ipo_supported(RESULT result)
if(result)
set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
endif()
Apply IPO flags without any checks. This may lead to build errors if IPO is not supported
by the compiler in the current environment. Produce an error if CMake does not know IPO
flags for the current compiler:
cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)
# ...
set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
CMP0068
RPATH settings on macOS do not affect install_name.
CMake 3.9 and newer remove any effect the following settings may have on the install_name
of a target on macOS:
• BUILD_WITH_INSTALL_RPATH target property
• SKIP_BUILD_RPATH target property
• CMAKE_SKIP_RPATH variable
• CMAKE_SKIP_INSTALL_RPATH variable
Previously, setting BUILD_WITH_INSTALL_RPATH had the effect of setting both the
install_name of a target to INSTALL_NAME_DIR and the RPATH to INSTALL_RPATH. In CMake
3.9, it only affects setting of RPATH. However, if one wants INSTALL_NAME_DIR to apply to
the target in the build tree, one may set BUILD_WITH_INSTALL_NAME_DIR.
If SKIP_BUILD_RPATH, CMAKE_SKIP_RPATH or CMAKE_SKIP_INSTALL_RPATH were used to strip the
directory portion of the install_name of a target, one may set INSTALL_NAME_DIR=""
instead.
The OLD behavior of this policy is to use the RPATH settings for install_name on macOS.
The NEW behavior of this policy is to ignore the RPATH settings for install_name on macOS.
This policy was introduced in CMake version 3.9. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.8
CMP0067
Honor language standard in try_compile() source-file signature.
The try_compile() source file signature is intended to allow callers to check whether they
will be able to compile a given source file with the current toolchain. In order to match
compiler behavior, any language standard mode should match. However, CMake 3.7 and below
did not do this. CMake 3.8 and above prefer to honor the language standard settings for
C, CXX (C++), and CUDA using the values of the variables:
• CMAKE_C_STANDARD
• CMAKE_C_STANDARD_REQUIRED
• CMAKE_C_EXTENSIONS
• CMAKE_CXX_STANDARD
• CMAKE_CXX_STANDARD_REQUIRED
• CMAKE_CXX_EXTENSIONS
• CMAKE_CUDA_STANDARD
• CMAKE_CUDA_STANDARD_REQUIRED
• CMAKE_CUDA_EXTENSIONS
This policy provides compatibility for projects that do not expect the language standard
settings to be used automatically.
The OLD behavior of this policy is to ignore language standard setting variables when
generating the try_compile test project. The NEW behavior of this policy is to honor
language standard setting variables.
This policy was introduced in CMake version 3.8. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0067 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.7
CMP0066
Honor per-config flags in try_compile() source-file signature.
The source file signature of the try_compile() command uses the value of the
CMAKE_<LANG>_FLAGS variable in the test project so that the test compilation works as it
would in the main project. However, CMake 3.6 and below do not also honor config-specific
compiler flags such as those in the CMAKE_<LANG>_FLAGS_DEBUG variable. CMake 3.7 and
above prefer to honor config-specific compiler flags too. This policy provides
compatibility for projects that do not expect config-specific compiler flags to be used.
The OLD behavior of this policy is to ignore config-specific flag variables like
CMAKE_<LANG>_FLAGS_DEBUG and only use CMake's built-in defaults for the current compiler
and platform.
The NEW behavior of this policy is to honor config-specific flag variabldes like
CMAKE_<LANG>_FLAGS_DEBUG.
This policy was introduced in CMake version 3.7. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0066 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.4
CMP0065
Do not add flags to export symbols from executables without the ENABLE_EXPORTS target
property.
CMake 3.3 and below, for historical reasons, always linked executables on some platforms
with flags like -rdynamic to export symbols from the executables for use by any plugins
they may load via dlopen. CMake 3.4 and above prefer to do this only for executables that
are explicitly marked with the ENABLE_EXPORTS target property.
The OLD behavior of this policy is to always use the additional link flags when linking
executables regardless of the value of the ENABLE_EXPORTS target property.
The NEW behavior of this policy is to only use the additional link flags when linking
executables if the ENABLE_EXPORTS target property is set to True.
This policy was introduced in CMake version 3.4. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0065 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0064
Recognize TEST as a operator for the if() command.
The TEST operator was added to the if() command to determine if a given test name was
created by the add_test() command.
The OLD behavior for this policy is to ignore the TEST operator. The NEW behavior is to
interpret the TEST operator.
This policy was introduced in CMake version 3.4. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.3
CMP0063
Honor visibility properties for all target types.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties affect
visibility of symbols during dynamic linking. When first introduced these properties
affected compilation of sources only in shared libraries, module libraries, and
executables with the ENABLE_EXPORTS property set. This was sufficient for the basic use
cases of shared libraries and executables with plugins. However, some sources may be
compiled as part of static libraries or object libraries and then linked into a shared
library later. CMake 3.3 and above prefer to honor these properties for sources compiled
in all target types. This policy preserves compatibility for projects expecting the
properties to work only for some target types.
The OLD behavior for this policy is to ignore the visibility properties for static
libraries, object libraries, and executables without exports. The NEW behavior for this
policy is to honor the visibility properties for all target types.
This policy was introduced in CMake version 3.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0062
Disallow install() of export() result.
The export() command generates a file containing Imported Targets, which is suitable for
use from the build directory. It is not suitable for installation because it contains
absolute paths to buildsystem locations, and is particular to a single build
configuration.
The install(EXPORT) generates and installs files which contain Imported Targets. These
files are generated with relative paths (unless the user specifies absolute paths), and
are designed for multi-configuration use. See Creating Packages for more.
CMake 3.3 no longer allows the use of the install(FILES) command with the result of the
export() command.
The OLD behavior for this policy is to allow installing the result of an export() command.
The NEW behavior for this policy is not to allow installing the result of an export()
command.
This policy was introduced in CMake version 3.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0061
CTest does not by default tell make to ignore errors (-i).
The ctest_build() and build_command() commands no longer generate build commands for
Makefile Generators with the -i option. Previously this was done to help build as much of
tested projects as possible. However, this behavior is not consistent with other
generators and also causes the return code of the make tool to be meaningless.
Of course users may still add this option manually by setting CTEST_BUILD_COMMAND or the
MAKECOMMAND cache entry. See the CTest Build Step MakeCommand setting documentation for
their effects.
The OLD behavior for this policy is to add -i to make calls in CTest. The NEW behavior
for this policy is to not add -i.
This policy was introduced in CMake version 3.3. Unlike most policies, CMake version
3.16.3 does not warn when this policy is not set and simply uses OLD behavior.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0060
Link libraries by full path even in implicit directories.
Policy CMP0003 was introduced with the intention of always linking library files by full
path when a full path is given to the target_link_libraries() command. However, on some
platforms (e.g. HP-UX) the compiler front-end adds alternative library search paths for
the current architecture (e.g. /usr/lib/<arch> has alternatives to libraries in /usr/lib
for the current architecture). On such platforms the find_library() may find a library
such as /usr/lib/libfoo.so that does not belong to the current architecture.
Prior to policy CMP0003 projects would still build in such cases because the incorrect
library path would be converted to -lfoo on the link line and the linker would find the
proper library in the arch-specific search path provided by the compiler front-end
implicitly. At the time we chose to remain compatible with such projects by always
converting library files found in implicit link directories to -lfoo flags to ask the
linker to search for them. This approach allowed existing projects to continue to build
while still linking to libraries outside implicit link directories via full path (such as
those in the build tree).
CMake does allow projects to override this behavior by using an IMPORTED library target
with its IMPORTED_LOCATION property set to the desired full path to a library file. In
fact, many Find Modules are learning to provide Imported Targets instead of just the
traditional Foo_LIBRARIES variable listing library files. However, this makes the link
line generated for a library found by a Find Module depend on whether it is linked through
an imported target or not, which is inconsistent. Furthermore, this behavior has been a
source of confusion because the generated link line for a library file depends on its
location. It is also problematic for projects trying to link statically because flags
like -Wl,-Bstatic -lfoo -Wl,-Bdynamic may be used to help the linker select libfoo.a
instead of libfoo.so but then leak dynamic linking to following libraries. (See the
LINK_SEARCH_END_STATIC target property for a solution typically used for that problem.)
When the special case for libraries in implicit link directories was first introduced the
list of implicit link directories was simply hard-coded (e.g. /lib, /usr/lib, and a few
others). Since that time, CMake has learned to detect the implicit link directories used
by the compiler front-end. If necessary, the find_library() command could be taught to
use this information to help find libraries of the proper architecture.
For these reasons, CMake 3.3 and above prefer to drop the special case and link libraries
by full path even when they are in implicit link directories. Policy CMP0060 provides
compatibility for existing projects.
The OLD behavior for this policy is to ask the linker to search for libraries whose full
paths are known to be in implicit link directories. The NEW behavior for this policy is
to link libraries by full path even if they are in implicit link directories.
This policy was introduced in CMake version 3.3. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0060 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0059
Do not treat DEFINITIONS as a built-in directory property.
CMake 3.3 and above no longer make a list of definitions available through the DEFINITIONS
directory property. The COMPILE_DEFINITIONS directory property may be used instead.
The OLD behavior for this policy is to provide the list of flags given so far to the
add_definitions() command. The NEW behavior is to behave as a normal user-defined
directory property.
This policy was introduced in CMake version 3.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0058
Ninja requires custom command byproducts to be explicit.
When an intermediate file generated during the build is consumed by an expensive operation
or a large tree of dependents, one may reduce the work needed for an incremental rebuild
by updating the file timestamp only when its content changes. With this approach the
generation rule must have a separate output file that is always updated with a new
timestamp that is newer than any dependencies of the rule so that the build tool re-runs
the rule only when the input changes. We refer to the separate output file as a rule's
witness and the generated file as a rule's byproduct.
Byproducts may not be listed as outputs because their timestamps are allowed to be older
than the inputs. No build tools (like make) that existed when CMake was designed have a
way to express byproducts. Therefore CMake versions prior to 3.2 had no way to specify
them. Projects typically left byproducts undeclared in the rules that generate them. For
example:
add_custom_command(
OUTPUT witness.txt
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/input.txt
byproduct.txt # timestamp may not change
COMMAND ${CMAKE_COMMAND} -E touch witness.txt
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
)
add_custom_target(Provider DEPENDS witness.txt)
add_custom_command(
OUTPUT generated.c
COMMAND expensive-task -i byproduct.txt -o generated.c
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/byproduct.txt
)
add_library(Consumer generated.c)
add_dependencies(Consumer Provider)
This works well for all generators except Ninja. The Ninja build tool sees a rule listing
byproduct.txt as a dependency and no rule listing it as an output. Ninja then complains
that there is no way to satisfy the dependency and stops building even though there are
order-only dependencies that ensure byproduct.txt will exist before its consumers need it.
See discussion of this problem in Ninja Issue 760 for further details on why Ninja works
this way.
Instead of leaving byproducts undeclared in the rules that generate them, Ninja expects
byproducts to be listed along with other outputs. Such rules may be marked with a restat
option that tells Ninja to check the timestamps of outputs after the rules run. This
prevents byproducts whose timestamps do not change from causing their dependents to
re-build unnecessarily.
Since the above approach does not tell CMake what custom command generates byproduct.txt,
the Ninja generator does not have enough information to add the byproduct as an output of
any rule. CMake 2.8.12 and above work around this problem and allow projects using the
above approach to build by generating phony build rules to tell Ninja to tolerate such
missing files. However, this workaround prevents Ninja from diagnosing a dependency that
is really missing. It also works poorly in in-source builds where every custom command
dependency, even on source files, needs to be treated this way because CMake does not have
enough information to know which files are generated as byproducts of custom commands.
CMake 3.2 introduced the BYPRODUCTS option to the add_custom_command() and
add_custom_target() commands. This option allows byproducts to be specified explicitly:
add_custom_command(
OUTPUT witness.txt
BYPRODUCTS byproduct.txt # explicit byproduct specification
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_SOURCE_DIR}/input.txt
byproduct.txt # timestamp may not change
...
The BYPRODUCTS option is used by the Ninja generator to list byproducts among the outputs
of the custom commands that generate them, and is ignored by other generators.
CMake 3.3 and above prefer to require projects to specify custom command byproducts
explicitly so that it can avoid using the phony rule workaround altogether. Policy
CMP0058 was introduced to provide compatibility with existing projects that still need the
workaround.
This policy has no effect on generators other than Ninja. The OLD behavior for this
policy is to generate Ninja phony rules for unknown dependencies in the build tree. The
NEW behavior for this policy is to not generate these and instead require projects to
specify custom command BYPRODUCTS explicitly.
This policy was introduced in CMake version 3.3. CMake version 3.16.3 warns when it sees
unknown dependencies in out-of-source build trees if the policy is not set and then uses
OLD behavior. Use the cmake_policy() command to set the policy to OLD or NEW explicitly.
The policy setting must be in scope at the end of the top-level CMakeLists.txt file of the
project and has global effect.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0057
Support new if() IN_LIST operator.
CMake 3.3 adds support for the new IN_LIST operator.
The OLD behavior for this policy is to ignore the IN_LIST operator. The NEW behavior is
to interpret the IN_LIST operator.
This policy was introduced in CMake version 3.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.2
CMP0056
Honor link flags in try_compile() source-file signature.
The try_compile() command source-file signature generates a CMakeLists.txt file to build
the source file into an executable. In order to compile the source the same way as it
might be compiled by the calling project, the generated project sets the value of the
CMAKE_<LANG>_FLAGS variable to that in the calling project. The value of the
CMAKE_EXE_LINKER_FLAGS variable may be needed in some cases too, but CMake 3.1 and lower
did not set it in the generated project. CMake 3.2 and above prefer to set it so that
linker flags are honored as well as compiler flags. This policy provides compatibility
with the pre-3.2 behavior.
The OLD behavior for this policy is to not set the value of the CMAKE_EXE_LINKER_FLAGS
variable in the generated test project. The NEW behavior for this policy is to set the
value of the CMAKE_EXE_LINKER_FLAGS variable in the test project to the same as it is in
the calling project.
If the project code does not set the policy explicitly, users may set it on the command
line by defining the CMAKE_POLICY_DEFAULT_CMP0056 variable in the cache.
This policy was introduced in CMake version 3.2. Unlike most policies, CMake version
3.16.3 does not warn by default when this policy is not set and simply uses OLD behavior.
See documentation of the CMAKE_POLICY_WARNING_CMP0056 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0055
Strict checking for the break() command.
CMake 3.1 and lower allowed calls to the break() command outside of a loop context and
also ignored any given arguments. This was undefined behavior.
The OLD behavior for this policy is to allow break() to be placed outside of loop contexts
and ignores any arguments. The NEW behavior for this policy is to issue an error if a
misplaced break or any arguments are found.
This policy was introduced in CMake version 3.2. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.1
CMP0054
Only interpret if() arguments as variables or keywords when unquoted.
CMake 3.1 and above no longer implicitly dereference variables or interpret keywords in an
if() command argument when it is a Quoted Argument or a Bracket Argument.
The OLD behavior for this policy is to dereference variables and interpret keywords even
if they are quoted or bracketed. The NEW behavior is to not dereference variables or
interpret keywords that have been quoted or bracketed.
Given the following partial example:
set(A E)
set(E "")
if("${A}" STREQUAL "")
message("Result is TRUE before CMake 3.1 or when CMP0054 is OLD")
else()
message("Result is FALSE in CMake 3.1 and above if CMP0054 is NEW")
endif()
After explicit expansion of variables this gives:
if("E" STREQUAL "")
With the policy set to OLD implicit expansion reduces this semantically to:
if("" STREQUAL "")
With the policy set to NEW the quoted arguments will not be further dereferenced:
if("E" STREQUAL "")
This policy was introduced in CMake version 3.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0053
Simplify variable reference and escape sequence evaluation.
CMake 3.1 introduced a much faster implementation of evaluation of the Variable References
and Escape Sequences documented in the cmake-language(7) manual. While the behavior is
identical to the legacy implementation in most cases, some corner cases were cleaned up to
simplify the behavior. Specifically:
• Expansion of @VAR@ reference syntax defined by the configure_file() and
string(CONFIGURE) commands is no longer performed in other contexts.
• Literal ${VAR} reference syntax may contain only alphanumeric characters (A-Z, a-z, 0-9)
and the characters _, ., /, -, and +. Note that $ is technically allowed in the NEW
behavior, but is invalid for OLD behavior. This is due to an oversight during the
implementation of CMP0053 and its use as a literal variable reference is discouraged for
this reason. Variables with other characters in their name may still be referenced
indirectly, e.g.
set(varname "otherwise & disallowed $ characters")
message("${${varname}}")
• The setting of policy CMP0010 is not considered, so improper variable reference syntax
is always an error.
• More characters are allowed to be escaped in variable names. Previously, only ()#" \@^
were valid characters to escape. Now any non-alphanumeric, non-semicolon, non-NUL
character may be escaped following the escape_identity production in the Escape
Sequences section of the cmake-language(7) manual.
The OLD behavior for this policy is to honor the legacy behavior for variable references
and escape sequences. The NEW behavior is to use the simpler variable expansion and
escape sequence evaluation rules.
This policy was introduced in CMake version 3.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0052
Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES.
CMake 3.0 and lower allowed subdirectories of the source directory or build directory to
be in the INTERFACE_INCLUDE_DIRECTORIES of installed and exported targets, if the
directory was also a subdirectory of the installation prefix. This makes the installation
depend on the existence of the source dir or binary dir, and the installation will be
broken if either are removed after installation.
See Include Directories and Usage Requirements for more on specifying include directories
for targets.
The OLD behavior for this policy is to export the content of the
INTERFACE_INCLUDE_DIRECTORIES with the source or binary directory. The NEW behavior for
this policy is to issue an error if such a directory is used.
This policy was introduced in CMake version 3.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0051
List TARGET_OBJECTS in SOURCES target property.
CMake 3.0 and lower did not include the TARGET_OBJECTS generator expression when returning
the SOURCES target property.
Configure-time CMake code is not able to handle generator expressions. If using the
SOURCES target property at configure time, it may be necessary to first remove generator
expressions using the string(GENEX_STRIP) command. Generate-time CMake code such as
file(GENERATE) can handle the content without stripping.
The OLD behavior for this policy is to omit TARGET_OBJECTS expressions from the SOURCES
target property. The NEW behavior for this policy is to include TARGET_OBJECTS
expressions in the output.
This policy was introduced in CMake version 3.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 3.0
CMP0050
Disallow add_custom_command SOURCE signatures.
CMake 2.8.12 and lower allowed a signature for add_custom_command() which specified an
input to a command. This was undocumented behavior. Modern use of CMake associates
custom commands with their output, rather than their input.
The OLD behavior for this policy is to allow the use of add_custom_command() SOURCE
signatures. The NEW behavior for this policy is to issue an error if such a signature is
used.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0049
Do not expand variables in target source entries.
CMake 2.8.12 and lower performed an extra layer of variable expansion when evaluating
source file names:
set(a_source foo.c)
add_executable(foo \${a_source})
This was undocumented behavior.
The OLD behavior for this policy is to expand such variables when processing the target
sources. The NEW behavior for this policy is to issue an error if such variables need to
be expanded.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0048
The project() command manages VERSION variables.
CMake version 3.0 introduced the VERSION option of the project() command to specify a
project version as well as the name. In order to keep PROJECT_VERSION and related
variables consistent with variable PROJECT_NAME it is necessary to set the VERSION
variables to the empty string when no VERSION is given to project(). However, this can
change behavior for existing projects that set VERSION variables themselves since
project() may now clear them. This policy controls the behavior for compatibility with
such projects.
The OLD behavior for this policy is to leave VERSION variables untouched. The NEW
behavior for this policy is to set VERSION as documented by the project() command.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0047
Use QCC compiler id for the qcc drivers on QNX.
CMake 3.0 and above recognize that the QNX qcc compiler driver is different from the GNU
compiler. CMake now prefers to present this to projects by setting the
CMAKE_<LANG>_COMPILER_ID variable to QCC instead of GNU. However, existing projects may
assume the compiler id for QNX qcc is just GNU as it was in CMake versions prior to 3.0.
Therefore this policy determines for QNX qcc which compiler id to report in the
CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the project() or
enable_language() command. The policy must be set prior to the invocation of either
command.
The OLD behavior for this policy is to use the GNU compiler id for the qcc and QCC
compiler drivers. The NEW behavior for this policy is to use the QCC compiler id for those
drivers.
This policy was introduced in CMake version 3.0. Use the cmake_policy() command to set
this policy to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not
warn by default when this policy is not set and simply uses OLD behavior. See
documentation of the CMAKE_POLICY_WARNING_CMP0047 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0046
Error on non-existent dependency in add_dependencies.
CMake 2.8.12 and lower silently ignored non-existent dependencies listed in the
add_dependencies() command.
The OLD behavior for this policy is to silently ignore non-existent dependencies. The NEW
behavior for this policy is to report an error if non-existent dependencies are listed in
the add_dependencies() command.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0045
Error on non-existent target in get_target_property.
In CMake 2.8.12 and lower, the get_target_property() command accepted a non-existent
target argument without issuing any error or warning. The result variable is set to a
-NOTFOUND value.
The OLD behavior for this policy is to issue no warning and set the result variable to a
-NOTFOUND value. The NEW behavior for this policy is to issue a FATAL_ERROR if the
command is called with a non-existent target.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0044
Case sensitive <LANG>_COMPILER_ID generator expressions
CMake 2.8.12 introduced the <LANG>_COMPILER_ID generator expressions to allow comparison
of the CMAKE_<LANG>_COMPILER_ID with a test value. The possible valid values are
lowercase, but the comparison with the test value was performed case-insensitively.
The OLD behavior for this policy is to perform a case-insensitive comparison with the
value in the <LANG>_COMPILER_ID expression. The NEW behavior for this policy is to perform
a case-sensitive comparison with the value in the <LANG>_COMPILER_ID expression.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0043
Ignore COMPILE_DEFINITIONS_<Config> properties
CMake 2.8.12 and lower allowed setting the COMPILE_DEFINITIONS_<CONFIG> target property
and COMPILE_DEFINITIONS_<CONFIG> directory property to apply configuration-specific
compile definitions.
Since CMake 2.8.10, the COMPILE_DEFINITIONS property has supported generator expressions
for setting configuration-dependent content. The continued existence of the suffixed
variables is redundant, and causes a maintenance burden. Population of the
COMPILE_DEFINITIONS_DEBUG property may be replaced with a population of
COMPILE_DEFINITIONS directly or via target_compile_definitions():
# Old Interfaces:
set_property(TARGET tgt APPEND PROPERTY
COMPILE_DEFINITIONS_DEBUG DEBUG_MODE
)
set_property(DIRECTORY APPEND PROPERTY
COMPILE_DEFINITIONS_DEBUG DIR_DEBUG_MODE
)
# New Interfaces:
set_property(TARGET tgt APPEND PROPERTY
COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DEBUG_MODE>
)
target_compile_definitions(tgt PRIVATE $<$<CONFIG:Debug>:DEBUG_MODE>)
set_property(DIRECTORY APPEND PROPERTY
COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DIR_DEBUG_MODE>
)
The OLD behavior for this policy is to consume the content of the suffixed
COMPILE_DEFINITIONS_<CONFIG> target property when generating the compilation command. The
NEW behavior for this policy is to ignore the content of the COMPILE_DEFINITIONS_<CONFIG>
target property .
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0042
MACOSX_RPATH is enabled by default.
CMake 2.8.12 and newer has support for using @rpath in a target's install name. This was
enabled by setting the target property MACOSX_RPATH. The @rpath in an install name is a
more flexible and powerful mechanism than @executable_path or @loader_path for locating
shared libraries.
CMake 3.0 and later prefer this property to be ON by default. Projects wanting @rpath in
a target's install name may remove any setting of the INSTALL_NAME_DIR and
CMAKE_INSTALL_NAME_DIR variables.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0041
Error on relative include with generator expression.
Diagnostics in CMake 2.8.12 and lower silently ignored an entry in the
INTERFACE_INCLUDE_DIRECTORIES of a target if it contained a generator expression at any
position.
The path entries in that target property should not be relative. High-level API should
ensure that by adding either a source directory or a install directory prefix, as
appropriate.
As an additional diagnostic, the INTERFACE_INCLUDE_DIRECTORIES generated on an IMPORTED
target for the install location should not contain paths in the source directory or the
build directory.
The OLD behavior for this policy is to ignore relative path entries if they contain a
generator expression. The NEW behavior for this policy is to report an error if a
generator expression appears in another location and the path is relative.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0040
The target in the TARGET signature of add_custom_command() must exist and must be defined
in the current directory.
CMake 2.8.12 and lower silently ignored a custom command created with the TARGET signature
of add_custom_command() if the target is unknown or was defined outside the current
directory.
The OLD behavior for this policy is to ignore custom commands for unknown targets. The
NEW behavior for this policy is to report an error if the target referenced in
add_custom_command() is unknown or was defined outside the current directory.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0039
Utility targets may not have link dependencies.
CMake 2.8.12 and lower allowed using utility targets in the left hand side position of the
target_link_libraries() command. This is an indicator of a bug in user code.
The OLD behavior for this policy is to ignore attempts to set the link libraries of
utility targets. The NEW behavior for this policy is to report an error if an attempt is
made to set the link libraries of a utility target.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0038
Targets may not link directly to themselves.
CMake 2.8.12 and lower allowed a build target to link to itself directly with a
target_link_libraries() call. This is an indicator of a bug in user code.
The OLD behavior for this policy is to ignore targets which list themselves in their own
link implementation. The NEW behavior for this policy is to report an error if a target
attempts to link to itself.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0037
Target names should not be reserved and should match a validity pattern.
CMake 2.8.12 and lower allowed creating targets using add_library(), add_executable() and
add_custom_target() with unrestricted choice for the target name. Newer cmake features
such as cmake-generator-expressions(7) and some diagnostics expect target names to match a
restricted pattern.
Target names may contain upper and lower case letters, numbers, the underscore character
(_), dot(.), plus(+) and minus(-). As a special case, ALIAS and IMPORTED targets may
contain two consecutive colons.
Target names reserved by one or more CMake generators are not allowed. Among others these
include all, clean, help, and install.
Target names associated with optional features, such as test and package, may also be
reserved. CMake 3.10 and below always reserve them. CMake 3.11 and above reserve them
only when the corresponding feature is enabled (e.g. by including the CTest or CPack
modules).
The OLD behavior for this policy is to allow creating targets with reserved names or which
do not match the validity pattern. The NEW behavior for this policy is to report an error
if an add_* command is used with an invalid target name.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0036
The build_name() command should not be called.
This command was added in May 2001 to compute a name for the current operating system and
compiler combination. The command has long been documented as discouraged and replaced by
the CMAKE_SYSTEM and CMAKE_<LANG>_COMPILER variables.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0035
The variable_requires() command should not be called.
This command was introduced in November 2001 to perform some conditional logic. It has
long been replaced by the if() command.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0034
The utility_source() command should not be called.
This command was introduced in March 2001 to help build executables used to generate other
files. This approach has long been replaced by add_executable() combined with
add_custom_command().
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0033
The export_library_dependencies() command should not be called.
This command was added in January 2003 to export <tgt>_LIB_DEPENDS internal CMake cache
entries to a file for installation with a project. This was used at the time to allow
transitive link dependencies to work for applications outside of the original build tree
of a project. The functionality has been superseded by the export() and install(EXPORT)
commands.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0032
The output_required_files() command should not be called.
This command was added in June 2001 to expose the then-current CMake implicit dependency
scanner. CMake's real implicit dependency scanner has evolved since then but is not
exposed through this command. The scanning capabilities of this command are very limited
and this functionality is better achieved through dedicated outside tools.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0031
The load_command() command should not be called.
This command was added in August 2002 to allow projects to add arbitrary commands
implemented in C or C++. However, it does not work when the toolchain in use does not
match the ABI of the CMake process. It has been mostly superseded by the macro() and
function() commands.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0030
The use_mangled_mesa() command should not be called.
This command was created in September 2001 to support VTK before modern CMake language and
custom command capabilities. VTK has not used it in years.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0029
The subdir_depends() command should not be called.
The implementation of this command has been empty since December 2001 but was kept in
CMake for compatibility for a long time.
CMake >= 3.0 prefer that this command never be called. The OLD behavior for this policy
is to allow the command to be called. The NEW behavior for this policy is to issue a
FATAL_ERROR when the command is called.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0028
Double colon in target name means ALIAS or IMPORTED target.
CMake 2.8.12 and lower allowed the use of targets and files with double colons in
target_link_libraries(), with some buildsystem generators.
The use of double-colons is a common pattern used to namespace IMPORTED targets and ALIAS
targets. When computing the link dependencies of a target, the name of each dependency
could either be a target, or a file on disk. Previously, if a target was not found with a
matching name, the name was considered to refer to a file on disk. This can lead to
confusing error messages if there is a typo in what should be a target name.
The OLD behavior for this policy is to search for targets, then files on disk, even if the
search term contains double-colons. The NEW behavior for this policy is to issue a
FATAL_ERROR if a link dependency contains double-colons but is not an IMPORTED target or
an ALIAS target.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0027
Conditionally linked imported targets with missing include directories.
CMake 2.8.11 introduced introduced the concept of INTERFACE_INCLUDE_DIRECTORIES, and a
check at cmake time that the entries in the INTERFACE_INCLUDE_DIRECTORIES of an IMPORTED
target actually exist. CMake 2.8.11 also introduced generator expression support in the
target_link_libraries() command. However, if an imported target is linked as a result of
a generator expression evaluation, the entries in the INTERFACE_INCLUDE_DIRECTORIES of
that target were not checked for existence as they should be.
The OLD behavior of this policy is to report a warning if an entry in the
INTERFACE_INCLUDE_DIRECTORIES of a generator-expression conditionally linked IMPORTED
target does not exist.
The NEW behavior of this policy is to report an error if an entry in the
INTERFACE_INCLUDE_DIRECTORIES of a generator-expression conditionally linked IMPORTED
target does not exist.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0026
Disallow use of the LOCATION property for build targets.
CMake 2.8.12 and lower allowed reading the LOCATION target property (and
configuration-specific variants) to determine the eventual location of build targets.
This relies on the assumption that all necessary information is available at
configure-time to determine the final location and filename of the target. However, this
property is not fully determined until later at generate-time. At generate time, the
$<TARGET_FILE> generator expression can be used to determine the eventual LOCATION of a
target output.
Code which reads the LOCATION target property can be ported to use the $<TARGET_FILE>
generator expression together with the file(GENERATE) subcommand to generate a file
containing the target location.
The OLD behavior for this policy is to allow reading the LOCATION properties from
build-targets. The NEW behavior for this policy is to not to allow reading the LOCATION
properties from build-targets.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0025
Compiler id for Apple Clang is now AppleClang.
CMake 3.0 and above recognize that Apple Clang is a different compiler than upstream Clang
and that they have different version numbers. CMake now prefers to present this to
projects by setting the CMAKE_<LANG>_COMPILER_ID variable to AppleClang instead of Clang.
However, existing projects may assume the compiler id for Apple Clang is just Clang as it
was in CMake versions prior to 3.0. Therefore this policy determines for Apple Clang
which compiler id to report in the CMAKE_<LANG>_COMPILER_ID variable after language <LANG>
is enabled by the project() or enable_language() command. The policy must be set prior to
the invocation of either command.
The OLD behavior for this policy is to use compiler id Clang. The NEW behavior for this
policy is to use compiler id AppleClang.
This policy was introduced in CMake version 3.0. Use the cmake_policy() command to set
this policy to OLD or NEW explicitly. Unlike most policies, CMake version 3.16.3 does not
warn by default when this policy is not set and simply uses OLD behavior. See
documentation of the CMAKE_POLICY_WARNING_CMP0025 variable to control the warning.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0024
Disallow include export result.
CMake 2.8.12 and lower allowed use of the include() command with the result of the
export() command. This relies on the assumption that the export() command has an
immediate effect at configure-time during a cmake run. Certain properties of targets are
not fully determined until later at generate-time, such as the link language and complete
list of link libraries. Future refactoring will change the effect of the export() command
to be executed at generate-time. Use ALIAS targets instead in cases where the goal is to
refer to targets by another name.
The OLD behavior for this policy is to allow including the result of an export() command.
The NEW behavior for this policy is not to allow including the result of an export()
command.
This policy was introduced in CMake version 3.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 2.8
CMP0023
Plain and keyword target_link_libraries() signatures cannot be mixed.
CMake 2.8.12 introduced the target_link_libraries() signature using the PUBLIC, PRIVATE,
and INTERFACE keywords to generalize the LINK_PUBLIC and LINK_PRIVATE keywords introduced
in CMake 2.8.7. Use of signatures with any of these keywords sets the link interface of a
target explicitly, even if empty. This produces confusing behavior when used in
combination with the historical behavior of the plain target_link_libraries() signature.
For example, consider the code:
target_link_libraries(mylib A)
target_link_libraries(mylib PRIVATE B)
After the first line the link interface has not been set explicitly so CMake would use the
link implementation, A, as the link interface. However, the second line sets the link
interface to empty. In order to avoid this subtle behavior CMake now prefers to disallow
mixing the plain and keyword signatures of target_link_libraries() for a single target.
The OLD behavior for this policy is to allow keyword and plain target_link_libraries()
signatures to be mixed. The NEW behavior for this policy is to not to allow mixing of the
keyword and plain signatures.
This policy was introduced in CMake version 2.8.12. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0022
INTERFACE_LINK_LIBRARIES defines the link interface.
CMake 2.8.11 constructed the 'link interface' of a target from properties matching
(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?. The modern way to specify
config-sensitive content is to use generator expressions and the IMPORTED_ prefix makes
uniform processing of the link interface with generator expressions impossible. The
INTERFACE_LINK_LIBRARIES target property was introduced as a replacement in CMake 2.8.12.
This new property is named consistently with the INTERFACE_COMPILE_DEFINITIONS,
INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_OPTIONS properties. For in-build
targets, CMake will use the INTERFACE_LINK_LIBRARIES property as the source of the link
interface only if policy CMP0022 is NEW. When exporting a target which has this policy
set to NEW, only the INTERFACE_LINK_LIBRARIES property will be processed and generated for
the IMPORTED target by default. A new option to the install(EXPORT) and export commands
allows export of the old-style properties for compatibility with downstream users of CMake
versions older than 2.8.12. The target_link_libraries() command will no longer populate
the properties matching LINK_INTERFACE_LIBRARIES(_<CONFIG>)? if this policy is NEW.
Warning-free future-compatible code which works with CMake 2.8.7 onwards can be written by
using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries().
The OLD behavior for this policy is to ignore the INTERFACE_LINK_LIBRARIES property for
in-build targets. The NEW behavior for this policy is to use the INTERFACE_LINK_LIBRARIES
property for in-build targets, and ignore the old properties matching
(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.
This policy was introduced in CMake version 2.8.12. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0021
Fatal error on relative paths in INCLUDE_DIRECTORIES target property.
CMake 2.8.10.2 and lower allowed the INCLUDE_DIRECTORIES target property to contain
relative paths. The base path for such relative entries is not well defined. CMake
2.8.12 issues a FATAL_ERROR if the INCLUDE_DIRECTORIES property contains a relative path.
The OLD behavior for this policy is not to warn about relative paths in the
INCLUDE_DIRECTORIES target property. The NEW behavior for this policy is to issue a
FATAL_ERROR if INCLUDE_DIRECTORIES contains a relative path.
This policy was introduced in CMake version 2.8.12. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0020
Automatically link Qt executables to qtmain target on Windows.
CMake 2.8.10 and lower required users of Qt to always specify a link dependency to the
qtmain.lib static library manually on Windows. CMake 2.8.11 gained the ability to
evaluate generator expressions while determining the link dependencies from IMPORTED
targets. This allows CMake itself to automatically link executables which link to Qt to
the qtmain.lib library when using IMPORTED Qt targets. For applications already linking
to qtmain.lib, this should have little impact. For applications which supply their own
alternative WinMain implementation and for applications which use the QAxServer library,
this automatic linking will need to be disabled as per the documentation.
The OLD behavior for this policy is not to link executables to qtmain.lib automatically
when they link to the QtCore IMPORTED target. The NEW behavior for this policy is to link
executables to qtmain.lib automatically when they link to QtCore IMPORTED target.
This policy was introduced in CMake version 2.8.11. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0019
Do not re-expand variables in include and link information.
CMake 2.8.10 and lower re-evaluated values given to the include_directories,
link_directories, and link_libraries commands to expand any leftover variable references
at the end of the configuration step. This was for strict compatibility with VERY early
CMake versions because all variable references are now normally evaluated during CMake
language processing. CMake 2.8.11 and higher prefer to skip the extra evaluation.
The OLD behavior for this policy is to re-evaluate the values for strict compatibility.
The NEW behavior for this policy is to leave the values untouched.
This policy was introduced in CMake version 2.8.11. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0018
Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable.
CMake 2.8.8 and lower compiled sources in SHARED and MODULE libraries using the value of
the undocumented CMAKE_SHARED_LIBRARY_<Lang>_FLAGS platform variable. The variable
contained platform-specific flags needed to compile objects for shared libraries.
Typically it included a flag such as -fPIC for position independent code but also included
other flags needed on certain platforms. CMake 2.8.9 and higher prefer instead to use the
POSITION_INDEPENDENT_CODE target property to determine what targets should be position
independent, and new undocumented platform variables to select flags while ignoring
CMAKE_SHARED_LIBRARY_<Lang>_FLAGS completely.
The default for either approach produces identical compilation flags, but if a project
modifies CMAKE_SHARED_LIBRARY_<Lang>_FLAGS from its original value this policy determines
which approach to use.
The OLD behavior for this policy is to ignore the POSITION_INDEPENDENT_CODE property for
all targets and use the modified value of CMAKE_SHARED_LIBRARY_<Lang>_FLAGS for SHARED and
MODULE libraries.
The NEW behavior for this policy is to ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS whether it
is modified or not and honor the POSITION_INDEPENDENT_CODE target property.
This policy was introduced in CMake version 2.8.9. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0017
Prefer files from the CMake module directory when including from there.
Starting with CMake 2.8.4, if a cmake-module shipped with CMake (i.e. located in the
CMake module directory) calls include() or find_package(), the files located in the CMake
module directory are preferred over the files in CMAKE_MODULE_PATH. This makes sure that
the modules belonging to CMake always get those files included which they expect, and
against which they were developed and tested. In all other cases, the files found in
CMAKE_MODULE_PATH still take precedence over the ones in the CMake module directory. The
OLD behavior is to always prefer files from CMAKE_MODULE_PATH over files from the CMake
modules directory.
This policy was introduced in CMake version 2.8.4. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0016
target_link_libraries() reports error if its only argument is not a target.
In CMake 2.8.2 and lower the target_link_libraries() command silently ignored if it was
called with only one argument, and this argument wasn't a valid target. In CMake 2.8.3
and above it reports an error in this case.
This policy was introduced in CMake version 2.8.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0015
link_directories() treats paths relative to the source dir.
In CMake 2.8.0 and lower the link_directories() command passed relative paths unchanged to
the linker. In CMake 2.8.1 and above the link_directories() command prefers to interpret
relative paths with respect to CMAKE_CURRENT_SOURCE_DIR, which is consistent with
include_directories() and other commands. The OLD behavior for this policy is to use
relative paths verbatim in the linker command. The NEW behavior for this policy is to
convert relative paths to absolute paths by appending the relative path to
CMAKE_CURRENT_SOURCE_DIR.
This policy was introduced in CMake version 2.8.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0014
Input directories must have CMakeLists.txt.
CMake versions before 2.8 silently ignored missing CMakeLists.txt files in directories
referenced by add_subdirectory() or subdirs(), treating them as if present but empty. In
CMake 2.8.0 and above this cmake_policy() determines whether or not the case is an error.
The OLD behavior for this policy is to silently ignore the problem. The NEW behavior for
this policy is to report an error.
This policy was introduced in CMake version 2.8.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0013
Duplicate binary directories are not allowed.
CMake 2.6.3 and below silently permitted add_subdirectory() calls to create the same
binary directory multiple times. During build system generation files would be written
and then overwritten in the build tree and could lead to strange behavior. CMake 2.6.4
and above explicitly detect duplicate binary directories. CMake 2.6.4 always considers
this case an error. In CMake 2.8.0 and above this policy determines whether or not the
case is an error. The OLD behavior for this policy is to allow duplicate binary
directories. The NEW behavior for this policy is to disallow duplicate binary directories
with an error.
This policy was introduced in CMake version 2.8.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0012
if() recognizes numbers and boolean constants.
In CMake versions 2.6.4 and lower the if() command implicitly dereferenced arguments
corresponding to variables, even those named like numbers or boolean constants, except for
0 and 1. Numbers and boolean constants such as true, false, yes, no, on, off, y, n,
notfound, ignore (all case insensitive) were recognized in some cases but not all. For
example, the code if(TRUE) might have evaluated as false. Numbers such as 2 were
recognized only in boolean expressions like if(NOT 2) (leading to false) but not as a
single-argument like if(2) (also leading to false). Later versions of CMake prefer to
treat numbers and boolean constants literally, so they should not be used as variable
names.
The OLD behavior for this policy is to implicitly dereference variables named like numbers
and boolean constants. The NEW behavior for this policy is to recognize numbers and
boolean constants without dereferencing variables with such names.
This policy was introduced in CMake version 2.8.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
POLICIES INTRODUCED BY CMAKE 2.6
CMP0011
Included scripts do automatic cmake_policy() PUSH and POP.
In CMake 2.6.2 and below, CMake Policy settings in scripts loaded by the include() and
find_package() commands would affect the includer. Explicit invocations of
cmake_policy(PUSH) and cmake_policy(POP) were required to isolate policy changes and
protect the includer. While some scripts intend to affect the policies of their includer,
most do not. In CMake 2.6.3 and above, include() and find_package() by default PUSH and
POP an entry on the policy stack around an included script, but provide a NO_POLICY_SCOPE
option to disable it. This policy determines whether or not to imply NO_POLICY_SCOPE for
compatibility. The OLD behavior for this policy is to imply NO_POLICY_SCOPE for include()
and find_package() commands. The NEW behavior for this policy is to allow the commands to
do their default cmake_policy PUSH and POP.
This policy was introduced in CMake version 2.6.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0010
Bad variable reference syntax is an error.
In CMake 2.6.2 and below, incorrect variable reference syntax such as a missing
close-brace (${FOO) was reported but did not stop processing of CMake code. This policy
determines whether a bad variable reference is an error. The OLD behavior for this policy
is to warn about the error, leave the string untouched, and continue. The NEW behavior
for this policy is to report an error.
If CMP0053 is set to NEW, this policy has no effect and is treated as always being NEW.
This policy was introduced in CMake version 2.6.3. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0009
FILE GLOB_RECURSE calls should not follow symlinks by default.
In CMake 2.6.1 and below, file(GLOB_RECURSE) calls would follow through symlinks,
sometimes coming up with unexpectedly large result sets because of symlinks to top level
directories that contain hundreds of thousands of files.
This policy determines whether or not to follow symlinks encountered during a
file(GLOB_RECURSE) call. The OLD behavior for this policy is to follow the symlinks. The
NEW behavior for this policy is not to follow the symlinks by default, but only if
FOLLOW_SYMLINKS is given as an additional argument to the FILE command.
This policy was introduced in CMake version 2.6.2. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0008
Libraries linked by full-path must have a valid library file name.
In CMake 2.4 and below it is possible to write code like
target_link_libraries(myexe /full/path/to/somelib)
where somelib is supposed to be a valid library file name such as libsomelib.a or
somelib.lib. For Makefile generators this produces an error at build time because the
dependency on the full path cannot be found. For Visual Studio Generators IDE and Xcode
generators this used to work by accident because CMake would always split off the library
directory and ask the linker to search for the library by name (-lsomelib or somelib.lib).
Despite the failure with Makefiles, some projects have code like this and build only with
Visual Studio and/or Xcode. This version of CMake prefers to pass the full path directly
to the native build tool, which will fail in this case because it does not name a valid
library file.
This policy determines what to do with full paths that do not appear to name a valid
library file. The OLD behavior for this policy is to split the library name from the path
and ask the linker to search for it. The NEW behavior for this policy is to trust the
given path and pass it directly to the native build tool unchanged.
This policy was introduced in CMake version 2.6.1. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0007
list command no longer ignores empty elements.
This policy determines whether the list command will ignore empty elements in the list.
CMake 2.4 and below list commands ignored all empty elements in the list. For example,
a;b;;c would have length 3 and not 4. The OLD behavior for this policy is to ignore empty
list elements. The NEW behavior for this policy is to correctly count empty elements in a
list.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0006
Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.
This policy determines whether the install(TARGETS) command must be given a BUNDLE
DESTINATION when asked to install a target with the MACOSX_BUNDLE property set. CMake 2.4
and below did not distinguish application bundles from normal executables when installing
targets. CMake 2.6 provides a BUNDLE option to the install(TARGETS) command that
specifies rules specific to application bundles on the Mac. Projects should use this
option when installing a target with the MACOSX_BUNDLE property set.
The OLD behavior for this policy is to fall back to the RUNTIME DESTINATION if a BUNDLE
DESTINATION is not given. The NEW behavior for this policy is to produce an error if a
bundle target is installed without a BUNDLE DESTINATION.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0005
Preprocessor definition values are now escaped automatically.
This policy determines whether or not CMake should generate escaped preprocessor
definition values added via add_definitions. CMake versions 2.4 and below assumed that
only trivial values would be given for macros in add_definitions calls. It did not
attempt to escape non-trivial values such as string literals in generated build rules.
CMake versions 2.6 and above support escaping of most values, but cannot assume the user
has not added escapes already in an attempt to work around limitations in earlier
versions.
The OLD behavior for this policy is to place definition values given to add_definitions
directly in the generated build rules without attempting to escape anything. The NEW
behavior for this policy is to generate correct escapes for all native build tools
automatically. See documentation of the COMPILE_DEFINITIONS target property for
limitations of the escaping implementation.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0004
Libraries linked may not have leading or trailing whitespace.
CMake versions 2.4 and below silently removed leading and trailing whitespace from
libraries linked with code like
target_link_libraries(myexe " A ")
This could lead to subtle errors in user projects.
The OLD behavior for this policy is to silently remove leading and trailing whitespace.
The NEW behavior for this policy is to diagnose the existence of such whitespace as an
error. The setting for this policy used when checking the library names is that in effect
when the target is created by an add_executable() or add_library() command.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0003
Libraries linked via full path no longer produce linker search paths.
This policy affects how libraries whose full paths are NOT known are found at link time,
but was created due to a change in how CMake deals with libraries whose full paths are
known. Consider the code
target_link_libraries(myexe /path/to/libA.so)
CMake 2.4 and below implemented linking to libraries whose full paths are known by
splitting them on the link line into separate components consisting of the linker search
path and the library name. The example code might have produced something like
... -L/path/to -lA ...
in order to link to library A. An analysis was performed to order multiple link
directories such that the linker would find library A in the desired location, but there
are cases in which this does not work. CMake versions 2.6 and above use the more reliable
approach of passing the full path to libraries directly to the linker in most cases. The
example code now produces something like
... /path/to/libA.so ....
Unfortunately this change can break code like
target_link_libraries(myexe /path/to/libA.so B)
where B is meant to find /path/to/libB.so. This code is wrong because the user is asking
the linker to find library B but has not provided a linker search path (which may be added
with the link_directories command). However, with the old linking implementation the code
would work accidentally because the linker search path added for library A allowed library
B to be found.
In order to support projects depending on linker search paths added by linking to
libraries with known full paths, the OLD behavior for this policy will add the linker
search paths even though they are not needed for their own libraries. When this policy is
set to OLD, CMake will produce a link line such as
... -L/path/to /path/to/libA.so -lB ...
which will allow library B to be found as it was previously. When this policy is set to
NEW, CMake will produce a link line such as
... /path/to/libA.so -lB ...
which more accurately matches what the project specified.
The setting for this policy used when generating the link line is that in effect when the
target is created by an add_executable or add_library command. For the example described
above, the code
cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4)
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)
will work and suppress the warning for this policy. It may also be updated to work with
the corrected linking approach:
cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6)
link_directories(/path/to) # needed to find library B
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so B)
Even better, library B may be specified with a full path:
add_executable(myexe myexe.c)
target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)
When all items on the link line have known paths CMake does not check this policy so it
has no effect.
Note that the warning for this policy will be issued for at most one target. This avoids
flooding users with messages for every target when setting the policy once will probably
fix all targets.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0002
Logical target names must be globally unique.
Targets names created with add_executable(), add_library(), or add_custom_target() are
logical build target names. Logical target names must be globally unique because:
- Unique names may be referenced unambiguously both in CMake
code and on make tool command lines.
- Logical names are used by Xcode and VS IDE generators
to produce meaningful project names for the targets.
The logical name of executable and library targets does not have to correspond to the
physical file names built. Consider using the OUTPUT_NAME target property to create two
targets with the same physical name while keeping logical names distinct. Custom targets
must simply have globally unique names (unless one uses the global property
ALLOW_DUPLICATE_CUSTOM_TARGETS with a Makefiles generator).
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0001
CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.
The behavior is to check CMAKE_BACKWARDS_COMPATIBILITY and present it to the user. The
NEW behavior is to ignore CMAKE_BACKWARDS_COMPATIBILITY completely.
In CMake 2.4 and below the variable CMAKE_BACKWARDS_COMPATIBILITY was used to request
compatibility with earlier versions of CMake. In CMake 2.6 and above all compatibility
issues are handled by policies and the cmake_policy() command. However, CMake must still
check CMAKE_BACKWARDS_COMPATIBILITY for projects written for CMake 2.4 and below.
This policy was introduced in CMake version 2.6.0. CMake version 3.16.3 warns when the
policy is not set and uses OLD behavior. Use the cmake_policy() command to set it to OLD
or NEW explicitly.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
CMP0000
A minimum required CMake version must be specified.
CMake requires that projects specify the version of CMake to which they have been written.
This policy has been put in place so users trying to build the project may be told when
they need to update their CMake. Specifying a version also helps the project build with
CMake versions newer than that specified. Use the cmake_minimum_required() command at the
top of your main CMakeLists.txt file:
cmake_minimum_required(VERSION <major>.<minor>)
where <major>.<minor> is the version of CMake you want to support (such as 3.14). The
command will ensure that at least the given version of CMake is running and help newer
versions be compatible with the project. See documentation of cmake_minimum_required()
for details.
Note that the command invocation must appear in the CMakeLists.txt file itself; a call in
an included file is not sufficient. However, the cmake_policy() command may be called to
set policy CMP0000 to OLD or NEW behavior explicitly. The OLD behavior is to silently
ignore the missing invocation. The NEW behavior is to issue an error instead of a
warning. An included file may set CMP0000 explicitly to affect how this policy is
enforced for the main CMakeLists.txt file.
This policy was introduced in CMake version 2.6.0.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be removed in a future
version of CMake.
COPYRIGHT
2000-2021 Kitware, Inc. and Contributors