CMAKE-POLICIES(7) CMake CMAKE-POLICIES(7)NAMEcmake-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 behav‐
ior. 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() com‐
mand or the find_package() command contain a use of cmake_policy(),
that policy setting will not affect the caller by default. Both com‐
mands accept an optional NO_POLICY_SCOPE keyword to control this behav‐
ior.
The CMAKE_MINIMUM_REQUIRED_VERSION variable may also be used to deter‐
mine whether to report an error on use of deprecated macros or func‐
tions.
ALL POLICIES
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 "2.6"). The command will ensure that at least the given ver‐
sion 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 miss‐
ing 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.
CMP0001
CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.
The OLD behavior is to check CMAKE_BACKWARDS_COMPATIBILITY and present
it to the user. The NEW behavior is to ignore CMAKE_BACKWARDS_COMPATI‐
BILITY 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_BACK‐
WARDS_COMPATIBILITY for projects written for CMake 2.4 and below.
This policy was introduced in CMake version 2.6.0. CMake version 3.4.2
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_cus‐
tom_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 OUT‐
PUT_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.4.2
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 mul‐
tiple 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_direc‐
tories 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.4.2
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.4.2
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 ver‐
sions 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 can‐
not 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 attempt‐
ing to escape anything. The NEW behavior for this policy is to gener‐
ate correct escapes for all native build tools automatically. See doc‐
umentation 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.4.2
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 DESTI‐
NATION 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.4.2
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 ele‐
ments 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.4.2
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 VS IDE and Xcode generators this used to work by acci‐
dent 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 VS 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.4.2
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.4.2
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.4.2
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.
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 deter‐
mines 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.4.2
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 derefer‐
enced arguments corresponding to variables, even those named like num‐
bers 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 derefer‐
encing variables with such names.
This policy was introduced in CMake version 2.8.0. CMake version 3.4.2
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 explic‐
itly 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.4.2
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 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.4.2
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.4.2
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.4.2
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_pack‐
age(), 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 pre‐
fer 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.4.2
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 deter‐
mine 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_INDEPEN‐
DENT_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.4.2
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_direc‐
tories, 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.4.2 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.4.2 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 prop‐
erty 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 rel‐
ative path.
This policy was introduced in CMake version 2.8.12. CMake version
3.4.2 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 proper‐
ties 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 INTER‐
FACE_LINK_LIBRARIES target property was introduced as a replacement in
CMake 2.8.12. This new property is named consistently with the INTER‐
FACE_COMPILE_DEFINITIONS, INTERFACE_INCLUDE_DIRECTORIES and INTER‐
FACE_COMPILE_OPTIONS properties. For in-build targets, CMake will use
the INTERFACE_LINK_LIBRARIES property as the source of the link inter‐
face 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(_<CON‐
FIG>)? 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 key‐
words of target_link_libraries().
The OLD behavior for this policy is to ignore the INTER‐
FACE_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.4.2 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.
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 explic‐
itly, even if empty. This produces confusing behavior when used in
combination with the historical behavior of the plain tar‐
get_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 tar‐
get.
The OLD behavior for this policy is to allow keyword and plain tar‐
get_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.4.2 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.
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 tar‐
gets 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.4.2
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. How‐
ever, 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_pol‐
icy() command to set this policy to OLD or NEW explicitly. Unlike most
policies, CMake version 3.4.2 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.
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 loca‐
tion of build targets. This relies on the assumption that all neces‐
sary 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 even‐
tual 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 prop‐
erties 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.4.2
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 INTER‐
FACE_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 tar‐
get_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 exis‐
tence 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 condition‐
ally 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 condition‐
ally linked IMPORTED target does not exist.
This policy was introduced in CMake version 3.0. CMake version 3.4.2
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 tar‐
get.
This policy was introduced in CMake version 3.0. CMake version 3.4.2
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 behav‐
ior 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.4.2
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 behav‐
ior 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.4.2
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 arbi‐
trary 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 behav‐
ior 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.4.2
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 func‐
tionality is better achieved through dedicated outside tools.
CMake >= 3.0 prefer that this command never be called. The OLD behav‐
ior 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.4.2
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 behav‐
ior 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.4.2
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 behav‐
ior 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.4.2
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 condi‐
tional logic. It has long been replaced by the if() command.
CMake >= 3.0 prefer that this command never be called. The OLD behav‐
ior 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.4.2
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 behav‐
ior 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.4.2
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 pat‐
tern.
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-expres‐
sions(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 targets and IMPORTED targets may contain two consequtive
colons.
Target names reserved by one or more CMake generators are not allowed.
Among others these include "all", "help" and "test".
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.4.2
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 them‐
selves 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.4.2
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 indi‐
cator 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.4.2
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.
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.
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.
This policy was introduced in CMake version 3.0. CMake version 3.4.2
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 gener‐
ated 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.4.2
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.4.2
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 gen‐
erator 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 suf‐
fixed 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.4.2
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 com‐
parison 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.4.2
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.4.2
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.
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.4.2
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 dif‐
ferent 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_pol‐
icy() command to set this policy to OLD or NEW explicitly. Unlike most
policies, CMake version 3.4.2 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.
CMP0048
The project() command manages VERSION variables.
CMake version 3.0 introduced the VERSION option of the project() com‐
mand 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 docu‐
mented by the project() command.
This policy was introduced in CMake version 3.0. CMake version 3.4.2
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 and 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 pro‐
cessing 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.4.2
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.
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_com‐
mand() 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.4.2
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 nec‐
essary 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.4.2
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_DIRECTO‐
RIES.
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 exis‐
tence 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 INTER‐
FACE_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.4.2
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-lan‐
guage(7) manual. While the behavior is identical to the legacy imple‐
mentation 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 con‐
texts.
· Literal ${VAR} reference syntax may contain only alphanumeric charac‐
ters (A-Z, a-z, 0-9) and the characters _, ., /, -, and +. Variables
with other characters in their name may still be referenced indi‐
rectly, 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. Previ‐
ously, 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 sec‐
tion 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.4.2
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.
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 inter‐
pret 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.4.2
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.
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 out‐
side 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.4.2
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.
CMP0056
Honor link flags in try_compile() source-file signature.
The try_compile() command source-file signature generates a CMake‐
Lists.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 call‐
ing 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.4.2 does not warn by default when this policy is not
set and simply uses OLD behavior. See documentation of the CMAKE_POL‐
ICY_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.
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.4.2
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 gener‐
ate 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 byprod‐
ucts whose timestamps do not change from causing their dependents to
re-build unnecessarily.
Since the above approach does not tell CMake what custom command gener‐
ates byproduct.txt, the Ninja generator does not have enough informa‐
tion 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 tol‐
erate 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 com‐
mand byproducts explicitly so that it can avoid using the phony rule
workaround altogether. Policy CMP0058 was introduced to provide com‐
patibility 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 com‐
mand BYPRODUCTS explicitly.
This policy was introduced in CMake version 3.3. CMake version 3.4.2
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_pol‐
icy() 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.
CMP0059
Don't 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.4.2
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.
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 tar‐
get_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-spe‐
cific 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 incon‐
sistent. Furthermore, this behavior has been a source of confusion
because the generated link line for a library file depends on its loca‐
tion. 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 directo‐
ries. 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.4.2 does not warn by default when this policy is not
set and simply uses OLD behavior. See documentation of the CMAKE_POL‐
ICY_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.
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. How‐
ever, 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.4.2 does not warn when this policy is not set and sim‐
ply uses OLD behavior.
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-configura‐
tion 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.4.2
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.
CMP0063
Honor visibility properties for all target types.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target prop‐
erties 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 pre‐
fer to honor these properties for sources compiled in all target types.
This policy preserves compatibility for projects expecting the proper‐
ties 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.4.2
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.
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.4.2
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.
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.4.2 does not warn by default when this policy is not
set and simply uses OLD behavior. See documentation of the CMAKE_POL‐
ICY_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.
COPYRIGHT
2000-2015 Kitware, Inc.
3.4.2 February 17, 2016 CMAKE-POLICIES(7)
