CMAKE-POLICIES(7) CMake CMAKE-POLICIES(7)
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 ei-
ther 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.
POLICIES INTRODUCED BY CMAKE 3.25
CMP0142
New in version 3.25.
The Xcode generator does not append per-config suffixes to library
search paths.
In CMake 3.24 and below, the Xcode generator preceded each entry of a
library search path with a copy of itself appended with $(CONFIGURA-
TION)$(EFFECTIVE_PLATFORM_NAME). This was left from very early ver-
sions of CMake in which per-config directories were not well modeled.
Such paths often do not exist, resulting in warnings from the
toolchain. CMake 3.25 and above prefer to not add such library search
paths. This policy provides compatibility for projects that may have
been accidentally relying on the old behavior.
The OLD behavior for this policy is to append $(CONFIGURATION)$(EFFEC-
TIVE_PLATFORM_NAME) to all library search paths. The NEW behavior is
to not modify library search paths.
This policy was introduced in CMake version 3.25. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0141
New in version 3.25.
MSVC debug information format flags are selected by an abstraction.
Compilers targeting the MSVC ABI have flags to select the debug infor-
mation format. Debug information format selection typically varies with
build configuration.
In CMake 3.24 and below, debug information format flags are added to
the default CMAKE_<LANG>_FLAGS_<CONFIG> cache entries by CMake automat-
ically. 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 programmati-
cally. 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.25 and above prefer to leave the debug information format flags
out of the default CMAKE_<LANG>_FLAGS_<CONFIG> values and instead offer
a first-class abstraction. The CMAKE_MSVC_DEBUG_INFORMATION_FORMAT
variable and MSVC_DEBUG_INFORMATION_FORMAT target property may be set
to select the MSVC debug information format. If they are not set,
CMake enables debug information in debug configurations using the de-
fault value $<$<CONFIG:Debug,RelWithDebInfo>:ProgramDatabase>, if sup-
ported by the compiler, and otherwise $<$<CONFIG:Debug,RelWithDe-
bInfo>:Embedded>.
This policy provides compatibility with projects that have not been up-
dated 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 will be used throughout the tree. In projects that have
nested projects in subdirectories, be sure to confirm if everything
is working with the selected policy behavior.
The OLD behavior for this policy is to place MSVC debug information
format flags in the default CMAKE_<LANG>_FLAGS_<CONFIG> cache entries
and ignore the CMAKE_MSVC_DEBUG_INFORMATION_FORMAT abstraction. The
NEW behavior for this policy is to not place MSVC debug information
format flags in the default cache entries and use the abstraction in-
stead.
This policy was introduced in CMake version 3.25. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0140
New in version 3.25.
The return() command checks its parameters.
The OLD behavior for this policy is to ignore any parameters given to
the command. The NEW behavior is to check the validity of the parame-
ters.
This policy was introduced in CMake version 3.25. CMake version 3.25.1
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.24
CMP0139
New in version 3.24.
The if() command supports path comparisons using PATH_EQUAL operator.
The OLD behavior for this policy is to ignore the PATH_EQUAL operator.
The NEW behavior is to interpret the PATH_EQUAL operator.
This policy was introduced in CMake version 3.24. CMake version 3.25.1
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.
CMP0138
New in version 3.24.
CheckIPOSupported uses flags from calling project.
The CheckIPOSupported module check_ipo_supported() command compiles a
test project to determine whether the toolchain supports
INTERPROCEDURAL_OPTIMIZATION. CMake 3.23 and below run the check with
the default values of the CMAKE_<LANG>_FLAGS and
CMAKE_<LANG>_FLAGS_<CONFIG> variables for the current environment and
toolchain settings. However, some projects may modify these flag vari-
ables to add flags that affect availability of the toolchain's IPO fea-
tures. CMake 3.24 and above prefer to honor the calling project's val-
ues for these variables. This policy provides compatibility for
projects that have not been updated to expect this behavior.
The OLD behavior for this policy is to ignore the calling project's
values of CMAKE_<LANG>_FLAGS and CMAKE_<LANG>_FLAGS_<CONFIG>. The NEW
behavior for this policy is to use the values of those variables as
compiler flags in the test project.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0137
New in version 3.24.
try_compile() passes platform variables in project mode.
The try_compile() command source file signature propagates CMake vari-
ables containing platform settings, and those specified by the
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable, into the generated test
project. This helps the test project drive the toolchain the same way
the calling project will. In CMake 3.23 and below, the whole-project
signature does not propagate platform variables automatically. CMake
3.24 and above prefer to propagate platform variables in the
whole-project signature. This policy provides compatibility with
projects that have not been updated to expect the behavior.
The OLD behavior for this policy is to not pass any additional vari-
ables to the whole-project signature. The NEW behavior for this policy
is to pass the same variables that the source file signature does.
Regardless of the policy setting, the
CMAKE_TRY_COMPILE_NO_PLATFORM_VARIABLES variable may be set to suppress
passing the platform variables through either signature.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set this policy to OLD or NEW explicitly. Un-
like many policies, CMake version 3.25.1 does not warn by default 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.
CMP0136
New in version 3.24.
Watcom runtime library flags are selected by an abstraction.
Compilers targeting the Watcom ABI have flags to select the Watcom run-
time library.
In CMake 3.23 and below, Watcom 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 program-
matically. 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.24 and above prefer to leave the Watcom runtime library selec-
tion flags out of the default CMAKE_<LANG>_FLAGS_<CONFIG> values and
instead offer a first-class abstraction. The
CMAKE_WATCOM_RUNTIME_LIBRARY variable and WATCOM_RUNTIME_LIBRARY target
property may be set to select the Watcom runtime library. If they are
not set then CMake uses the default value MultiThreadedDLL on Windows
and SingleThreaded on other platforms, which is equivalent to the orig-
inal flags.
This policy provides compatibility with projects that have not been up-
dated 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 Watcom 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 to-
gether.
The OLD behavior for this policy is to place Watcom runtime library
flags in the default CMAKE_<LANG>_FLAGS_<CONFIG> cache entries and ig-
nore the CMAKE_WATCOM_RUNTIME_LIBRARY abstraction. The NEW behavior
for this policy is to not place Watcom runtime library flags in the de-
fault cache entries and use the abstraction instead.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0135
New in version 3.24.
When using the URL download method with the ExternalProject_Add() com-
mand, CMake 3.23 and below sets the timestamps of the extracted con-
tents to the same as the timestamps in the archive. When the URL
changes, the new archive is downloaded and extracted, but the time-
stamps of the extracted contents might not be newer than the previous
contents. Anything that depends on the extracted contents might not be
rebuilt, even though the contents may change.
CMake 3.24 and above prefers to set the timestamps of all extracted
contents to the time of the extraction. This ensures that anything that
depends on the extracted contents will be rebuilt whenever the URL
changes.
The DOWNLOAD_EXTRACT_TIMESTAMP option to the ExternalProject_Add() com-
mand can be used to explicitly specify how timestamps should be han-
dled. When DOWNLOAD_EXTRACT_TIMESTAMP is not given, this policy con-
trols the default behavior. The OLD behavior for this policy is to re-
store the timestamps from the archive. The NEW behavior sets the time-
stamps of extracted contents to the time of extraction.
This policy was introduced in CMake version 3.24. CMake version 3.25.1
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.
CMP0134
New in version 3.24.
The default registry view is TARGET for the find_file(), find_path(),
find_library(), and find_package() commands and BOTH for the
find_program() command.
The default registry views in CMake 3.23 and below are selected using
the following rules:
• if CMAKE_SIZEOF_VOID_P has value 8:
• Use view 64 for all find_* commands except find_program() command.
• Use view 64_32 for find_program() command.
• if CMAKE_SIZEOF_VOID_P has value 4 or is undefined:
• Use view 32 for all find_* commands except find_program() command.
• Use view 32_64 for find_program() command.
The OLD behavior for this policy is to use registry views 64 and 64_32
or 32_64 and 32 as default, depending of CMAKE_SIZEOF_VOID_P variable
value. The NEW behavior for this policy is to use registry views TAR-
GET and BOTH as default.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set this policy to OLD or NEW explicitly. Un-
like many policies, CMake version 3.25.1 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.
CMP0133
New in version 3.24.
The CPack module disables SLA by default in the CPack DragNDrop Genera-
tor.
The CPack DragNDrop Generator in CMake 3.22 and below attach a Software
License Agreement (SLA) to .dmg files using the file specified by
CPACK_RESOURCE_FILE_LICENSE, if set to a non-default value. macOS 12.0
deprecated the tools used to do this, so CMake 3.23 added the
CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE option to control the behavior.
CMake 3.23 enables that option by default for compatibility with older
versions. CMake 3.24 and above prefer to not enable the
CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE option by default. This policy
provides compatibility with projects that have not been updated to ac-
count for the lack of a SLA in their .dmg packages.
The OLD behavior for this policy is to enable
CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE by default. The NEW behavior
for this policy is to not enable it by default.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set this policy to OLD or NEW explicitly. Un-
like many policies, CMake version 3.25.1 does not warn by default when
this policy is not set and simply uses OLD behavior. See documentation
of the CMAKE_POLICY_WARNING_CMP0133 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.
CMP0132
New in version 3.24.
Apart from when using the Xcode generator and some Visual Studio gener-
ators, CMake 3.23 and below will set environment variables like CC,
CXX, etc. when the corresponding language is enabled. This only occurs
on the very first time CMake is run in a build directory, and the envi-
ronment variables are only defined at configure time, not build time.
On subsequent CMake runs, these environment variables are not set,
opening up the opportunity for different behavior between the first and
subsequent CMake runs. CMake 3.24 and above prefer to not set these en-
vironment variables when a language is enabled, even on the first run
in a build directory.
The OLD behavior for this policy sets the relevant environment variable
on the first run when a language is enabled. The NEW behavior for this
policy does not set any such environment variables.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0131
New in version 3.24.
LINK_LIBRARIES supports the $<LINK_ONLY:...> generator expression.
CMake 3.23 and below documented the $<LINK_ONLY:...> generator expres-
sion only for use in INTERFACE_LINK_LIBRARIES. When used in
LINK_LIBRARIES, the content guarded inside $<LINK_ONLY:...> was always
used, even when collecting non-linking usage requirements such as
INTERFACE_COMPILE_DEFINITIONS.
CMake 3.24 and above prefer to support $<LINK_ONLY:...>, when used in
LINK_LIBRARIES, by using the guarded content only for link dependencies
and not other usage requirements. This policy provides compatibility
for projects that have not been updated to account for this change.
The OLD behavior for this policy is to use LINK_LIBRARIES content
guarded by $<LINK_ONLY:...> even for non-linking usage requirements.
The NEW behavior for this policy is to use the guarded content only for
link dependencies.
This policy was introduced in CMake version 3.24. Use the
cmake_policy() command to set this policy to OLD or NEW explicitly.
Unlike many policies, CMake version 3.25.1 does not warn when this pol-
icy 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.
CMP0130
New in version 3.24.
while() diagnoses condition evaluation errors.
CMake 3.23 and below accidentally tolerated errors encountered while
evaluating the condition passed to the while() command (but not the
if() command). For example, the code
set(paren "(")
while(${paren})
endwhile()
creates an unbalanced parenthesis during condition evaluation.
CMake 3.24 and above prefer to diagnose such errors. This policy pro-
vides compatibility for projects that have not been updated to fix
their condition errors.
The OLD behavior for this policy is to ignore errors in while() condi-
tions. The NEW behavior for this policy is to diagnose errors in
while() conditions.
This policy was introduced in CMake version 3.24. CMake version 3.25.1
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.23
CMP0129
New in version 3.23.
Compiler id for MCST LCC compilers is now LCC, not GNU.
CMake 3.23 and above recognize MCST LCC compiler as a different from
GNU, with its own command line and set of capabilities. CMake now pre-
fers to present this to projects by setting the
CMAKE_<LANG>_COMPILER_ID variable to LCC instead of GNU. However, ex-
isting projects may assume the compiler id for LCC is GNU as it was in
CMake versions prior to 3.23. Therefore this policy determines for
MCST LCC compiler 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 GNU (and set
CMAKE_<LANG>_COMPILER_VERSION to the supported GNU compiler version.)
NEW behavior for this policy is to use compiler id LCC, and set
CMAKE_<LANG>_SIMULATE_ID to GNU, and CMAKE_<LANG>_SIMULATE_VERSION to
the supported GNU compiler version.
This policy was introduced in CMake version 3.23. Use the
cmake_policy() command to set this policy to OLD or NEW explicitly.
Unlike most policies, CMake version 3.25.1 does not warn by default
when this policy is not set and simply uses OLD behavior. See documen-
tation of the CMAKE_POLICY_WARNING_CMP0129 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.22
CMP0128
New in version 3.22.
When this policy is set to NEW:
• <LANG>_EXTENSIONS is initialized to CMAKE_<LANG>_EXTENSIONS if set,
otherwise falling back to CMAKE_<LANG>_EXTENSIONS_DEFAULT.
• Extensions are correctly enabled/disabled if <LANG>_STANDARD is unset
or satisfied by the default.
• Standard mode-affecting flags aren't added unless necessary to
achieve the specified mode.
The OLD behavior:
• Initializes <LANG>_EXTENSIONS to CMAKE_<LANG>_EXTENSIONS if set, oth-
erwise falling back to ON.
• Always adds a flag if <LANG>_STANDARD is set and
<LANG>_STANDARD_REQUIRED is OFF.
• If <LANG>_STANDARD is unset:
• Doesn't disable extensions even if <LANG>_EXTENSIONS is OFF.
• Fails to enable extensions if <LANG>_EXTENSIONS is ON except for
the IAR compiler.
Code may need to be updated for the NEW behavior in the following
cases:
• If a standard mode flag previously overridden by CMake's and not used
during compiler detection now takes effect due to CMake no longer
adding one as the default detected is appropriate.
Such code should be converted to either:
• Use <LANG>_STANDARD and <LANG>_EXTENSIONS instead of manually
adding flags.
• Or ensure the manually-specified flags are used during compiler de-
tection.
• If extensions were disabled without <LANG>_STANDARD being set CMake
previously wouldn't actually disable extensions.
Such code should be updated to not disable extensions if they are re-
quired.
• If extensions were enabled/disabled when <LANG>_STANDARD was satis-
fied by the compiler's default CMake previously wouldn't actually en-
able/disable extensions.
Such code should be updated to set the correct extensions mode.
If compiler flags affecting the standard mode are used during compiler
detection (for example in a toolchain file using
CMAKE_<LANG>_FLAGS_INIT) then they will affect the detected default
standard and extensions.
Unlike many policies, CMake version 3.25.1 does not warn when the pol-
icy is not set and simply uses the OLD behavior. Use the cmake_policy()
command to set it to OLD or NEW explicitly. See documentation of the
CMAKE_POLICY_WARNING_CMP0128 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.
CMP0127
New in version 3.22.
cmake_dependent_option() supports full Condition Syntax.
The <depends> parameter accepts a semicolon-separated list of condi-
tions. CMake 3.21 and lower evaluates each condition as if(${condi-
tion}), which does not properly handle conditions with nested paren
groups. CMake 3.22 and above instead prefer to evaluate each condition
as if(<condition>), where <condition> is re-parsed as if literally
written in a call to if(). This allows expressions like:
"A AND (B OR C)"
but requires expressions like:
"FOO MATCHES (UPPER|lower)"
to be re-written as:
"FOO MATCHES \"(UPPER|lower)\""
Policy CMP0127 provides compatibility for projects that have not been
updated to expect the new behavior.
This policy was introduced in CMake version 3.22. CMake version 3.25.1
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.21
CMP0126
New in version 3.21.
When this policy is set to NEW, the set(CACHE) command does not remove
any normal variable of the same name from the current scope. The OLD
behavior removes any normal variable of the same name from the current
scope in the following situations:
• No cache variable of that name existed previously.
• A cache variable of that name existed previously, but it had no type.
This can occur when the variable was set on the command line using a
form like cmake -DMYVAR=blah instead of cmake -DMYVAR:STRING=blah.
• The FORCE or INTERNAL keywords were used when setting the cache vari-
able.
Note that the NEW behavior has an important difference to the similar
NEW behavior of policy CMP0077. The set(CACHE) command always sets the
cache variable if it did not exist previously, regardless of the
CMP0126 policy setting. The option() command will not set the cache
variable if a non-cache variable of the same name already exists and
CMP0077 is set to NEW.
Policy CMP0126 was introduced in CMake version 3.21. Use the
cmake_policy() command to set it to OLD or NEW explicitly within a
project. Use the CMAKE_POLICY_DEFAULT_CMP0126 variable to set the pol-
icy for a third-party project in a subdirectory without modifying it.
Unlike many policies, CMake version 3.25.1 does not warn when the pol-
icy is not set and simply uses OLD behavior. See documentation of the
CMAKE_POLICY_WARNING_CMP0126 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.
CMP0125
New in version 3.21.
The find_file(), find_path(), find_library() and find_program() com-
mands cache their result in the variable specified by their first argu-
ment. Prior to CMake 3.21, if a cache variable of that name already
existed before the call but the cache variable had no type, any
non-cache variable of the same name would be discarded and the cache
variable was always used (see also CMP0126 for a different but similar
behavior). This contradicts the convention that a non-cache variable
should take precedence over a cache variable of the same name. Such a
situation can arise if a user sets a cache variable on the command line
without specifying a type, such as cmake -DMYVAR=blah ... instead of
cmake -DMYVAR:FILEPATH=blah.
Related to the above, if a cache variable of the specified name already
exists and it does have a type, the various find_...() commands would
return that value unchanged. In particular, if it contained a relative
path, it would not be converted to an absolute path in this situation.
When policy CMP0125 is set to OLD or is unset, the behavior is as de-
scribed above. When it is set to NEW, the behavior is as follows:
• If a non-cache variable of the specified name exists when the
find_...() command is called, its value will be used regardless of
whether a cache variable of the same name already exists or not. A
cache variable will not be created in this case if no such cache
variable existed before. If a cache variable of the specified name
did already exist, the cache will be updated to match the non-cache
variable.
• The various find...() commands will always provide an absolute path
in the result variable, except where a relative path provided by a
cache or non-cache variable cannot be resolved to an existing path.
This policy was introduced in CMake version 3.21. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 does not warn when the 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.
CMP0124
New in version 3.21.
When this policy is set to NEW, the scope of loop variables defined by
the foreach() command is restricted to the loop only. They will be un-
set at the end of the loop.
The OLD behavior for this policy still clears the loop variables at the
end of the loop, but does not unset them. This leaves them as defined,
but empty.
This policy was introduced in CMake version 3.21. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 does not warn when the 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.
CMP0123
New in version 3.21.
ARMClang cpu/arch compile and link flags must be set explicitly.
CMake 3.20 and lower automatically maps the CMAKE_SYSTEM_PROCESSOR
variable and an undocumented CMAKE_SYSTEM_ARCH to compile and link op-
tions for ARMClang. For example, the -mcpu=cortex-m33 flag is added
when CMAKE_SYSTEM_PROCESSOR equals cortex-m33. CMake requires projects
to set either variable or it raises a fatal error. However, the
project may need to additionally specify CPU features using e.g.
-mcpu=cortex-m33+nodsp, conflicting with the -mcpu=cortex-m33 added by
CMake. This results in either link errors or unusable binaries.
CMake 3.21 and above prefer instead to not add any cpu/arch compile and
link flags automatically. Instead, projects must specify them explic-
itly. This policy provides compatibility for projects that have not
been updated.
The OLD behavior of this policy requires projects that use ARMClang to
set either CMAKE_SYSTEM_PROCESSOR or CMAKE_SYSTEM_ARCH and it automati-
cally adds a compile option -mcpu= or -march= and a link option --cpu=
based on those variables. The NEW behavior does not add compile or
link options, and projects are responsible for setting correct options.
This policy was introduced in CMake version 3.21. CMake version 3.25.1
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.
CMP0122
New in version 3.21.
UseSWIG use library name conventions for CSharp language.
Starting with CMake 3.21, UseSWIG generates now a library using default
naming conventions. This policy provides compatibility with projects
that expect the legacy behavior.
This policy was introduced in CMake version 3.21. CMake version 3.25.1
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.
CMP0121
New in version 3.21.
The list() command now detects invalid indices.
Prior to CMake version 3.21, the list() command's GET, INSERT, SUBLIST,
and REMOVE_AT subcommands did not detect invalid index arguments.
The OLD behavior of this policy is for invalid indices to be treated as
their integer value (if any) at the start of the string. For example,
2good4you is a 2 and not_an_integer is a 0. The NEW behavior is for in-
valid indices to trigger an error.
This policy was introduced in CMake version 3.21. CMake version 3.25.1
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.20
CMP0120
New in version 3.20.
The WriteCompilerDetectionHeader module is removed.
CMake versions 3.1 through 3.19 provide this module to generate a C++
compatibility layer by re-using information from CMake's table of pre-
processor checks for cmake-compile-features(7). However:
• Those granular features have been superseded by meta-features for
Requiring Language Standards such as cxx_std_11. Therefore no new
granular feature checks will be added and projects will need to use
other means to conditionally use new C++ features.
• The module exposes some of CMake's implementation details directly to
C++ translation units.
• The module's approach effectively provides a header file with CMake,
thus tying the version of the header to the version of CMake. Many
projects found that the WriteCompilerDetectionHeader was best used by
manually generating its header locally with a recent version of CMake
and then bundling it with the project source so that it could be used
with older CMake versions.
For reasons including the above, CMake 3.20 and above prefer to not
provide the WriteCompilerDetectionHeader module. This policy provides
compatibility for projects that have not been ported away from it.
Projects using the module should be updated to stop using it. Alterna-
tives include:
• Bundle a copy of the generated header in the project's source.
• Use a third-party alternative, such as the CC0-licensed Hedley.
• Drop support for compilers too old to provide the features natively.
The OLD behavior of this policy is for inclusion of the deprecated
WriteCompilerDetectionHeader module to work. The NEW behavior is for
inclusion of the module to fail as if it does not exist.
This policy was introduced in CMake version 3.20. CMake version 3.25.1
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.
CMP0119
New in version 3.20.
LANGUAGE source file property explicitly compiles as specified lan-
guage.
The LANGUAGE source file property is documented to mean that the source
file is written in the specified language. In CMake 3.19 and below,
setting this property causes CMake to compile the source file using the
compiler for the specified language. However, it only passes an ex-
plicit flag to tell the compiler to treat the source as the specified
language for MSVC-like, XL, and Embarcadero compilers for the CXX lan-
guage. CMake 3.20 and above prefer to also explicitly tell the com-
piler to use the specified language using a flag such as -x c on all
compilers for which such flags are known.
This policy provides compatibility for projects that have not been up-
dated to expect this behavior. For example, some projects were setting
the LANGUAGE property to C on assembly-language .S source files in or-
der to compile them using the C compiler. Such projects should be up-
dated to use enable_language(ASM), for which CMake will often choose
the C compiler as the assembler on relevant platforms anyway.
The OLD behavior for this policy is to interpret the LANGUAGE <LANG>
property using its undocumented meaning to "use the <LANG> compiler".
The NEW behavior for this policy is to interpret the LANGUAGE <LANG>
property using its documented meaning to "compile as a <LANG> source".
This policy was introduced in CMake version 3.20. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0118
New in version 3.20.
The GENERATED source file property is now visible in all directories.
Whether or not a source file is generated is an all-or-nothing global
property of the source. Consequently, the associated GENERATED prop-
erty is now visible from any directory scope, not only from the scope
for which it was set.
Additionally, the GENERATED property may now be set only to boolean
values, and may not be turned off once turned on.
The OLD behavior of this policy is to only allow GENERATED to be visi-
ble from the directory scope for which it was set. The NEW behavior on
the other hand allows it to be visible from any scope.
This policy was introduced in CMake version 3.20. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 does not warn when this policy is not
set and simply uses OLD behavior with regard to visibility of the GEN-
ERATED property. However, CMake does warn about setting the GENERATED
property to a non-boolean value.
CMP0117
New in version 3.20.
MSVC RTTI flag /GR is not added to CMAKE_CXX_FLAGS by default.
When using MSVC-like compilers in CMake 3.19 and below, the RTTI flag
/GR is added to CMAKE_CXX_FLAGS by default. This behavior is left from
support for MSVC versions from Visual Studio 2003 and below that did
not enable RTTI by default. It is no longer necessary. Furthermore,
it is problematic for projects that want to change to /GR- programmati-
cally. In particular, it requires string editing of the
CMAKE_CXX_FLAGS variable with knowledge of the CMake builtin default so
it can be replaced.
CMake 3.20 and above prefer to leave out /GR from the value of
CMAKE_CXX_FLAGS by default.
This policy provides compatibility with projects that have not been up-
dated to expect the lack of the /GR flag. The policy setting takes ef-
fect as of the first project() or enable_language() command that ini-
tializes CMAKE_CXX_FLAGS.
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 lan-
guage. In projects that have nested projects in subdirectories, be
sure to convert everything together.
The OLD behavior for this policy is to place the MSVC /GR flag in the
default CMAKE_CXX_FLAGS cache entry. The NEW behavior for this policy
is to not place the MSVC /GR flag in the default cache entry.
This policy was introduced in CMake version 3.20. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0116
New in version 3.20.
Ninja generators transform DEPFILE s from add_custom_command().
In CMake 3.19 and below, files given to the DEPFILE argument of
add_custom_command() were passed directly to Ninja's depfile variable
without any path resolution. This meant that if add_custom_command()
was called from a subdirectory (created by add_subdirectory()), the
DEPFILE argument would have to be either an absolute path or a path
relative to CMAKE_BINARY_DIR, rather than CMAKE_CURRENT_BINARY_DIR. In
addition, no transformation was done on the file listed in DEPFILE,
which meant that the paths within the DEPFILE had the same restric-
tions.
Starting with CMake 3.20, the DEPFILE argument is relative to
CMAKE_CURRENT_BINARY_DIR (unless it is absolute), and the paths in the
DEPFILE are also relative to CMAKE_CURRENT_BINARY_DIR. CMake automati-
cally transforms the paths in the DEPFILE (unless they are absolute)
after the custom command is run. The file listed in DEPFILE is not mod-
ified in any way. Instead, CMake writes the transformation to its own
internal file, and passes this internal file to Ninja's depfile vari-
able. This transformation happens regardless of whether or not DEPFILE
is relative, and regardless of whether or not add_custom_command() is
called from a subdirectory.
The OLD behavior for this policy is to pass the DEPFILE to Ninja unal-
tered. The NEW behavior for this policy is to transform the DEPFILE af-
ter running the custom command. The status of CMP0116 is recorded at
the time of the custom command's creation, and you can have custom com-
mands in the same directory with different values for CMP0116 by set-
ting the policy before each custom command.
This policy was introduced in CMake version 3.20. Unlike most poli-
cies, CMake version 3.25.1 does not warn by default when this policy is
not set (unless DEPFILE is used in a subdirectory) and simply uses OLD
behavior. See documentation of the CMAKE_POLICY_WARNING_CMP0116 vari-
able to control the warning.
CMP0115
New in version 3.20.
Source file extensions must be explicit.
In CMake 3.19 and below, if a source file could not be found by the
name specified, it would append a list of known extensions to the name
to see if the file with the extension could be found. For example, this
would allow the user to run:
add_executable(exe main)
and put main.c in the executable without specifying the extension.
Starting in CMake 3.20, CMake prefers all source files to have their
extensions explicitly listed:
add_executable(exe main.c)
The OLD behavior for this policy is to implicitly append known exten-
sions to source files if they can't be found. The NEW behavior of this
policy is to not append known extensions and require them to be ex-
plicit.
This policy was introduced in CMake version 3.20. CMake version 3.25.1
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.19
CMP0114
New in version 3.19.
ExternalProject step targets fully adopt their steps.
The ExternalProject_Add() STEP_TARGETS option, and the
ExternalProject_Add_StepTargets() function, can be used to create build
targets for individual steps of an external project.
In CMake 3.18 and below, step targets have some limitations:
• Step targets always depend on targets named by the
ExternalProject_Add() DEPENDS option even though not all steps need
them. In order to allow step targets to be created without those de-
pendencies, the ExternalProject_Add() INDEPENDENT_STEP_TARGETS option
or the ExternalProject_Add_StepTargets() NO_DEPENDS option may be
used. However, adding such "independent" step targets makes sense
only for specific steps such as download, update, and patch because
they do not need any of the external project's build dependencies.
Furthermore, it does not make sense to create independent step tar-
gets for steps that depend on non-independent steps. Such rules are
not enforced, and projects that do not follow them can generate build
systems with confusing and generator-specific behavior.
• Step targets hold copies of the custom commands implementing their
steps that are separate from the copies in the primary target created
by ExternalProject_Add(), and the primary target does not depend on
the step targets. In parallel builds that drive the primary target
and step targets concurrently, multiple copies of the steps' commands
may run concurrently and race each other.
Also, prior to policy CMP0113, the step targets generated by Makefile
Generators also contain all the custom commands on which their step
depends. This can lead to repeated execution of those steps even in
serial builds.
In CMake 3.19 and above, the ExternalProject module prefers a revised
design to address these problems:
• Each step is classified as "independent" if it does not depend on
other targets named by the ExternalProject_Add() DEPENDS. The prede-
fined steps are automatically classified by default:
• The download, update, and patch steps are independent.
• The configure, build, test, and install steps are not.
For custom steps, the ExternalProject_Add_Step() command provides an
INDEPENDENT option to mark them as independent. It is an error to
mark a step as independent if it depends on other steps that are not.
Note that this use of the term "independent" refers only to indepen-
dence from external targets and is orthogonal to a step's dependen-
cies on other steps.
• Step targets created by the ExternalProject_Add() STEP_TARGETS option
or the ExternalProject_Add_Step() function are now independent if and
only if their steps are marked as independent. The
ExternalProject_Add() INDEPENDENT_STEP_TARGETS option and
ExternalProject_Add_StepTargets() NO_DEPENDS option are no longer al-
lowed.
• Step targets, when created, are fully responsible for holding the
custom commands implementing their steps. The primary target created
by ExternalProject_Add() depends on the step targets, and the step
targets depend on each other. The target-level dependencies match
the file-level dependencies used by the custom commands for each
step.
When the ExternalProject_Add() UPDATE_DISCONNECTED or TEST_EX-
CLUDE_FROM_MAIN option is used, or the ExternalProject_Add_Step() EX-
CLUDE_FROM_MAIN option is used for a custom step, some step targets
may be created automatically. These are needed to hold the steps
commonly depended upon by the primary target and the disconnected
step targets.
Policy CMP0114 provides compatibility for projects that have not been
updated to expect the new behavior. The OLD behavior for this policy
is to use the above-documented behavior from 3.18 and below. The NEW
behavior for this policy is to use the above-documented behavior pre-
ferred by 3.19 and above.
This policy was introduced in CMake version 3.19. CMake version 3.25.1
warns when the policy is not set and uses OLD behavior. Use the
cmake_policy() command to set it to OLD or NEW explicitly.
CMP0113
New in version 3.19.
Makefile Generators do not repeat custom commands from target dependen-
cies.
Consider a chain of custom commands split across two dependent targets:
add_custom_command(OUTPUT output-not-created
COMMAND ... DEPENDS ...)
set_property(SOURCE output-not-created PROPERTY SYMBOLIC 1)
add_custom_command(OUTPUT output-created
COMMAND ... DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/output-not-created)
add_custom_target(first DEPENDS output-not-created)
add_custom_target(second DEPENDS output-created)
add_dependencies(second first)
In CMake 3.18 and lower, the Makefile generators put a copy of both
custom commands in the Makefile for target second even though its de-
pendency on target first ensures that the first custom command runs be-
fore the second. Running make second would cause the first custom com-
mand to run once in the first target and then again in the second tar-
get.
CMake 3.19 and above prefer to not duplicate custom commands in a tar-
get that are already generated in other targets on which the target de-
pends (directly or indirectly). This policy provides compatibility for
projects that have not been updated to expect the new behavior. In
particular, projects that relied on the duplicate execution or that did
not properly set the SYMBOLIC source file property may be affected.
The OLD behavior for this policy is to duplicate custom commands in de-
pendent targets. The NEW behavior of this policy is to not duplicate
custom commands in dependent targets.
This policy was introduced in CMake version 3.19. Unlike many poli-
cies, CMake version 3.25.1 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.
CMP0112
New in version 3.19.
Target file component generator expressions do not add target dependen-
cies.
The following target-based generator expressions that query for direc-
tory or file name components no longer add a dependency on the evalu-
ated target.
• TARGET_FILE_NAME
• TARGET_FILE_DIR
• TARGET_LINKER_FILE_BASE_NAME
• TARGET_LINKER_FILE_NAME
• TARGET_LINKER_FILE_DIR
• TARGET_SONAME_FILE_NAME
• TARGET_SONAME_FILE_DIR
• TARGET_PDB_FILE_NAME
• TARGET_PDB_FILE_DIR
• TARGET_BUNDLE_DIR
• TARGET_BUNDLE_DIR_NAME
• TARGET_BUNDLE_CONTENT_DIR
In CMake 3.18 and lower a dependency on the evaluated target of the
above generator expressions would always be added. CMake 3.19 and
above prefer to not add this dependency. This policy provides compati-
bility for projects that have not been updated to expect the new behav-
ior. The policy setting is recorded on each target when it is created,
and decides whether generator expressions referencing that target imply
a dependency on it.
The OLD behavior for this policy is to add a dependency on the evalu-
ated target for the above generator expressions. The NEW behavior of
this policy is to not add a dependency on the evaluated target for the
above generator expressions.
This policy was introduced in CMake version 3.19. Unlike many poli-
cies, CMake version 3.25.1 does not warn by default when this policy is
not set and simply uses OLD behavior. See documentation of the
CMAKE_POLICY_WARNING_CMP0112 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.
CMP0111
New in version 3.19.
An imported target missing its location property fails during genera-
tion.
Imported Targets for library files and executables require that their
location on disk is specified in a target property such as
IMPORTED_LOCATION, IMPORTED_IMPLIB, or a per-configuration equivalent.
If a needed location property is not set, CMake 3.18 and below generate
the string <TARGET_NAME>-NOTFOUND in its place, which results in fail-
ures of the corresponding rules at build time. CMake 3.19 and above
prefer instead to raise an error during generation. This policy pro-
vides compatibility for projects that have not been updated to expect
the new behavior.
The OLD behavior of this policy is to generate the location of an im-
ported unknown, static or shared library target as <TARGET_NAME>-NOT-
FOUND if not set. The NEW behavior is to raise an error.
This policy was introduced in CMake version 3.19. CMake version 3.25.1
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.
CMP0110
New in version 3.19.
add_test() supports arbitrary characters in test names.
add_test() can now (officially) create tests with whitespace and other
special characters in its name. Before CMake version 3.19 that was not
allowed, however, it was possible to work around this limitation by ex-
plicitly putting escaped quotes around the test's name in the add_test
command.
Although never officially supported several projects in the wild found
and implemented this workaround. However, the new change which offi-
cially allows the add_test command to support whitespace and other spe-
cial characters in test names now breaks that workaround. In order for
these projects to work smoothly with newer CMake versions, this policy
was introduced.
The OLD behavior of this policy is to still prevent add_test from han-
dling whitespace and special characters properly (if not using the men-
tioned workaround). The NEW behavior on the other hand allows names
with whitespace and special characters for tests created by add_test.
This policy was introduced in CMake version 3.19. CMake version 3.25.1
warns when the policy is not set and uses OLD behavior. Use the
cmake_policy() command to set it to OLD or NEW explicitly.
CMP0109
New in version 3.19.
find_program() requires permission to execute but not to read.
In CMake 3.18 and below, the find_program() command on UNIX would find
files that are readable without requiring execute permission, and would
not find files that are executable without read permission. In CMake
3.19 and above, find_program now prefers to require execute permission
but not read permission. This policy provides compatibility with
projects that have not been updated to expect the new behavior.
The OLD behavior for this policy is for find_program to require read
permission but not execute permission. The NEW behavior for this pol-
icy is for find_program to require execute permission but not read per-
mission.
This policy was introduced in CMake version 3.19. CMake version 3.25.1
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.18
CMP0108
New in version 3.18.
A target is not allowed to link to itself even through an ALIAS target.
In CMake 3.17 and below, a target can link to a target aliased to it-
self.
The OLD behavior for this policy is to allow a target to link to a tar-
get aliased to itself.
The NEW behavior of this policy is to prevent a target to link to it-
self through an ALIAS target.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0107
New in version 3.18.
It is not allowed to create an ALIAS target with the same name as an
another target.
In CMake 3.17 and below, an ALIAS target can overwrite silently an ex-
isting target with the same name.
The OLD behavior for this policy is to allow target overwrite.
The NEW behavior of this policy is to prevent target overwriting.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0106
New in version 3.18.
The Documentation module is removed.
The Documentation was added as a support mechanism for the VTK project
and was tuned for that project. Instead of CMake providing this module
with (now old) VTK patterns for cache variables and required packages,
the module is now deprecated by CMake itself.
The OLD behavior of this policy is for Documentation to add cache vari-
ables and find VTK documentation dependent packages. The NEW behavior
is to act as an empty module.
This policy was introduced in CMake version 3.18. CMake version 3.25.1
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.
CMP0105
New in version 3.18.
LINK_OPTIONS and INTERFACE_LINK_OPTIONS target properties are now used
for the device link step.
In CMake 3.17 and below, link options are not used by the device link
step.
The OLD behavior for this policy is to ignore the link options.
The NEW behavior of this policy is to use the link options during the
device link step.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0104
New in version 3.18.
Initialize CMAKE_CUDA_ARCHITECTURES when CMAKE_CUDA_COMPILER_ID is
NVIDIA. Raise an error if CUDA_ARCHITECTURES is empty.
CMAKE_CUDA_ARCHITECTURES introduced in CMake 3.18 is used to initialize
CUDA_ARCHITECTURES, which passes correct code generation flags to the
CUDA compiler.
Previous to this users had to manually specify the code generation
flags. This policy is for backwards compatibility with manually speci-
fying code generation flags.
The OLD behavior for this policy is to not initialize
CMAKE_CUDA_ARCHITECTURES when CMAKE_CUDA_COMPILER_ID is NVIDIA. Empty
CUDA_ARCHITECTURES is allowed.
The NEW behavior of this policy is to initialize
CMAKE_CUDA_ARCHITECTURES when CMAKE_CUDA_COMPILER_ID is NVIDIA and
raise an error if CUDA_ARCHITECTURES is empty during generation.
If CUDA_ARCHITECTURES is set to a false value no architectures flags
are passed to the compiler. This is intended to support packagers and
the rare cases where full control over the passed flags is required.
This policy was introduced in CMake version 3.18. CMake version 3.25.1
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
set_target_properties(tgt PROPERTIES CUDA_ARCHITECTURES "35;50;72")
Generates code for real and virtual architectures 30, 50 and 72.
set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES 70-real 72-virtual)
Generates code for real architecture 70 and virtual architecture 72.
set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)
CMake will not pass any architecture flags to the compiler.
CMP0103
New in version 3.18.
Multiple calls to export() command with same FILE without APPEND is no
longer allowed.
In CMake 3.17 and below, multiple calls to export() command with the
same FILE without APPEND are accepted silently but only the last occur-
rence is taken into account during the generation.
The OLD behavior for this policy is to ignore the multiple occurrences
of
export() command except the last one.
The NEW behavior of this policy is to raise an error on second call to
export() command with same FILE without APPEND.
This policy was introduced in CMake version 3.18. CMake version 3.25.1
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.17
CMP0102
New in version 3.17.
The mark_as_advanced() command no longer creates a cache entry if one
does not already exist.
In CMake 3.16 and below, if a variable was not defined at all or just
defined locally, the mark_as_advanced() command would create a new
cache entry with an UNINITIALIZED type and no value. When a find_path()
(or other similar find_ command) would next run, it would find this un-
defined cache entry and set it up with an empty string value. This
process would end up deleting the local variable in the process (due to
the way the cache works), effectively clearing any stored find_ results
that were only available in the local scope.
The OLD behavior for this policy is to create the empty cache defini-
tion. The NEW behavior of this policy is to ignore variables which do
not already exist in the cache.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 does not warn when this policy is not
set and simply uses OLD behavior. See documentation of the
CMAKE_POLICY_WARNING_CMP0102 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.
CMP0101
New in version 3.17.
target_compile_options() now honors BEFORE keyword in all scopes.
In CMake 3.16 and below the target_compile_options() ignores the BEFORE
keyword in private scope. CMake 3.17 and later honors BEFORE keyword in
all scopes. This policy provides compatibility for projects that have
not been updated to expect the new behavior.
The OLD behavior for this policy is to not honor BEFORE keyword in pri-
vate scope. The NEW behavior of this policy is to honor BEFORE keyword
in all scopes.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0100
New in version 3.17.
Let AUTOMOC and AUTOUIC process header files that end with a .hh exten-
sion.
Since version 3.17, CMake processes header files that end with a .hh
extension in AUTOMOC and AUTOUIC. In earlier CMake versions, these
header files were ignored by AUTOMOC and AUTOUIC.
This policy affects how header files that end with a .hh extension get
treated in AUTOMOC and AUTOUIC.
The OLD behavior for this policy is to ignore .hh header files in
AUTOMOC and AUTOUIC.
The NEW behavior for this policy is to process .hh header files in
AUTOMOC and AUTOUIC just like other header files.
NOTE:
To silence the CMP0100 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.hh PROPERTY SKIP_AUTOMOC ON)
set_property(SOURCE /path/to/file2.hh PROPERTY SKIP_AUTOUIC ON)
set_property(SOURCE /path/to/file3.hh PROPERTY SKIP_AUTOGEN ON)
This policy was introduced in CMake version 3.17.0. CMake version
3.25.1 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.
CMP0099
New in version 3.17.
Target link properties INTERFACE_LINK_OPTIONS,
INTERFACE_LINK_DIRECTORIES and INTERFACE_LINK_DEPENDS are now transi-
tive over private dependencies of static libraries.
In CMake 3.16 and below the interface link properties attached to li-
braries are not propagated for private dependencies of static li-
braries. Only the libraries themselves are propagated to link the de-
pendent binary. CMake 3.17 and later prefer to propagate all interface
link properties. This policy provides compatibility for projects that
have not been updated to expect the new behavior.
The OLD behavior for this policy is to not propagate interface link
properties. The NEW behavior of this policy is to propagate interface
link properties.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.
CMP0098
New in version 3.17.
FindFLEX runs flex in directory CMAKE_CURRENT_BINARY_DIR when execut-
ing.
The module provides a FLEX_TARGET macro which generates FLEX output.
In CMake 3.16 and below the macro would generate a custom command that
runs flex in the current source directory. CMake 3.17 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 en-
sures that any implicitly generated file is written relative to the
build tree rather than the source tree, unless the generated file is
provided as absolute path.
This policy provides compatibility for projects that have not been up-
dated to expect the new behavior.
The OLD behavior for this policy is for FLEX_TARGET to use the current
source directory for the WORKING_DIRECTORY and where to generate im-
plicit files. The NEW behavior of this policy is to use the current bi-
nary directory for the WORKING_DIRECTORY relative to which implicit
files are generated unless provided as absolute path.
This policy was introduced in CMake version 3.17. Use the
cmake_policy() command to set it to OLD or NEW explicitly. Unlike many
policies, CMake version 3.25.1 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.16
CMP0097
New in version 3.16.
ExternalProject_Add() with GIT_SUBMODULES "" initializes no submodules.
The policy also applies to FetchContent_Declare(), which uses the same
download and update features as ExternalProject_Add().
The commands provide a GIT_SUBMODULES option which controls what sub-
modules 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 up-
dated 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 be-
havior 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.25.1 does not warn when this policy is not
set and simply uses OLD behavior.
CMP0096
New in version 3.16.
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 compo-
nents in PROJECT_VERSION_{MAJOR,MINOR,PATCH,TWEAK} variables (see pol-
icy 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 up-
dated 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 poli-
cies, CMake version 3.25.1 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
New in version 3.16.
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 syn-
tax. In order to not be substituted (usually to an empty string) al-
ready 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 coinci-
dental 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 prop-
erly 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.25.1
warns when the policy is not set and detected usage of CMake-like syn-
tax 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
New in version 3.15.
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.25.1 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
New in version 3.15.
FindBoost reports Boost_VERSION in x.y.z format.
In CMake 3.14 and below the module would report the Boost version num-
ber 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_VER-
SION 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.25.1 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
New in version 3.15.
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 problem-
atic for projects that want to choose a different warning level pro-
grammatically. In particular, it requires string editing of the
CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin de-
faults 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 up-
dated to expect the lack of warning flags. The policy setting takes
effect as of the first project() or enable_language() command that ini-
tializes CMAKE_<LANG>_FLAGS for a given language <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 lan-
guage. 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.25.1 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
New in version 3.15.
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 config-
uration 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 auto-
matically. 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 programmati-
cally. 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 vari-
able 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 up-
dated 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 to-
gether.
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 pol-
icy is to not place MSVC runtime library flags in the default cache en-
tries 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.25.1 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
New in version 3.15.
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 de-
fault. 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 pop-
ulate 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.25.1 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
New in version 3.15.
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 com-
piler 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 invoca-
tion of either command.
The OLD behavior for this policy is to use compiler id XL. The NEW be-
havior 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.25.1 does not warn by default
when this policy is not set and simply uses OLD behavior. See documen-
tation 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
New in version 3.14.
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 WORK-
ING_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 up-
dated 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 im-
plicit files. The NEW behavior of this policy is to use the current bi-
nary 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.25.1 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
New in version 3.14.
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 behav-
ior 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 di-
rectory 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.25.1
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
New in version 3.14.
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_MOD-
ULE_NAME is specified.
This policy was introduced in CMake version 3.14. CMake version 3.25.1
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
New in version 3.14.
$<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.25.1
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
New in version 3.14.
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.25.1
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
New in version 3.14.
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 hon-
ored 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.25.1 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
New in version 3.14.
Install rules from add_subdirectory() calls are interleaved with those
in caller.
CMake 3.13 and lower ran the install rules from add_subdirectory() af-
ter all other install rules, even if add_subdirectory() was called be-
fore the other install rules. CMake 3.14 and above prefer to inter-
leave these add_subdirectory() install rules with the others so that
they are run in the order they are declared. This policy provides com-
patibility 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 poli-
cies, CMake version 3.25.1 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
New in version 3.13.
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.25.1
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
New in version 3.13.
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 pres-
ence of CMAKE_GENERATOR and throws a fatal error if it exists.
The OLD behavior of this policy is to allow BundleUtilities to be in-
cluded at configure time. The NEW behavior of this policy is to disal-
low such inclusion.
This policy was introduced in CMake version 3.13. CMake version 3.25.1
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
New in version 3.13.
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 ac-
cidentally accept targets from other directories on calls that only up-
date 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 genera-
tors 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 li-
braries to targets created in other directories. The entries are added
to LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES using a special (inter-
nal) 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 an-
other 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.25.1
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
New in version 3.13.
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_PREFER-
ENCE variable that can be used to specify an explicit preference. The
value may be one of:
• LEGACY: legacy strategy is applied. Variable SWIG_MOD-
ULE_<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.25.1
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
New in version 3.13.
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 re-
moves 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 behav-
ior is consistent between the first and later runs in a build tree.
This policy provides compatibility with projects that have not been up-
dated 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 al-
ready 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 vari-
able of the same name exists. The normal variable is not removed.
The cache entry is not created or updated and is ignored if it ex-
ists.
See CMP0126 for a similar policy for the set(CACHE) command, but note
that there are some differences in NEW behavior between the two poli-
cies.
This policy was introduced in CMake version 3.13. CMake version 3.25.1
warns when the policy is not set and uses OLD behavior. Use the
cmake_policy() command to set it to OLD or NEW explicitly within a
project. Use the CMAKE_POLICY_DEFAULT_CMP0077 variable to set the pol-
icy for a third-party project in a subdirectory without modifying it.
NOTE:
The OLD behavior of a policy is deprecated by definition and may be
removed in a future version of CMake.
CMP0076
New in version 3.13.
The target_sources() command converts relative paths to absolute.
In CMake 3.13 and above, the target_sources() command now converts rel-
ative 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 unmodi-
fied.
This policy provides compatibility with projects that have not been up-
dated 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.25.1
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
New in version 3.12.
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.25.1
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
New in version 3.12.
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 up-
dated to avoid using <PackageName>_ROOT variables for other purposes.
The OLD behavior for this policy is to ignore <PackageName>_ROOT vari-
ables. The NEW behavior for this policy is to use <PackageName>_ROOT
variables.
This policy was introduced in CMake version 3.12. CMake version 3.25.1
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
New in version 3.12.
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 compati-
bility 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 en-
tries. 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.25.1 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
New in version 3.11.
FindOpenGL prefers GLVND by default when available.
The FindOpenGL module provides an OpenGL::GL target and an OPENGL_LI-
BRARIES 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 vari-
able 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_PREFER-
ENCE to GLVND.
This policy was introduced in CMake version 3.11. CMake version 3.25.1
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
New in version 3.10.
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.25.1
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
New in version 3.10.
Define file(GENERATE) behavior for relative paths.
CMake 3.10 and newer define that relative paths given to INPUT and OUT-
PUT 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 in-
terpret relative paths with respect to the current source or binary di-
rectory of the caller.
This policy was introduced in CMake version 3.10. CMake version 3.25.1
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
New in version 3.9.
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.25.1
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. Pro-
duce an error if CMake does not know IPO flags for the current com-
piler:
cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
project(foo)
# ...
set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
CMP0068
New in version 3.9.
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. How-
ever, 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 in-
stall_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.25.1
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
New in version 3.8.
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 set-
tings 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 behav-
ior 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.25.1 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
New in version 3.7.
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 pro-
vides 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 vari-
ables like CMAKE_<LANG>_FLAGS_DEBUG and only use CMake's built-in de-
faults for the current compiler and platform.
The NEW behavior of this policy is to honor config-specific flag vari-
abldes like CMAKE_<LANG>_FLAGS_DEBUG.
This policy was introduced in CMake version 3.7. Unlike most policies,
CMake version 3.25.1 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
New in version 3.4.
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.25.1 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
New in version 3.4.
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.25.1
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
New in version 3.3.
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 ex-
ports. 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.25.1
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
New in version 3.3.
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 lo-
cations, 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.25.1
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
New in version 3.3.
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.25.1 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.
CMP0060
New in version 3.3.
Link libraries by full path even in implicit directories.
Policy CMP0003 was introduced with the intention of always linking li-
brary 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 li-
braries 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 be-
cause 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 ex-
isting 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 be-
cause 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 ar-
chitecture.
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 di-
rectories. Policy CMP0060 provides compatibility for existing
projects.
The OLD behavior for this policy is to ask the linker to search for li-
braries 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.25.1 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
New in version 3.3.
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.25.1
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
New in version 3.3.
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 de-
pendencies 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 ap-
proach to build by generating phony build rules to tell Ninja to toler-
ate 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.
Introducing Byproducts
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 ig-
nored 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 be-
havior for this policy is to generate Ninja phony rules for unknown de-
pendencies 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.25.1
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 CMake-
Lists.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
New in version 3.3.
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.25.1
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
New in version 3.2.
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.25.1 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
New in version 3.2.
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.25.1
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
New in version 3.1.
Only interpret if() arguments as variables or keywords when unquoted.
CMake 3.1 and above no longer implicitly dereference variables or in-
terpret keywords in an if() command argument when it is a Quoted Argu-
ment 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.25.1
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
New in version 3.1.
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 con-
texts.
• Literal ${VAR} reference syntax may contain only alphanumeric charac-
ters (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. Previ-
ously, only ()#" \@^ were valid characters to escape. Now any non-al-
phanumeric, 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.25.1
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
New in version 3.1.
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 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
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.25.1
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
New in version 3.1.
List TARGET_OBJECTS in SOURCES target property.
CMake 3.0 and lower did not include the TARGET_OBJECTS generator ex-
pression 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.25.1
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 pol-
icy is to issue an error if such a signature is used.
This policy was introduced in CMake version 3.0. CMake version 3.25.1
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 pro-
cessing the target sources. The NEW behavior for this policy is to is-
sue an error if such variables need to be expanded.
This policy was introduced in CMake version 3.0. CMake version 3.25.1
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() 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 un-
touched. 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.25.1
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 in-
stead 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 re-
port 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.25.1 does not warn by default
when this policy is not set and simply uses OLD behavior. See documen-
tation 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 de-
pendencies. 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.25.1
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 re-
sult 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.25.1
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.25.1
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 di-
rectly 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.25.1
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 in-
stall 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.25.1
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 lo-
cation and the path is relative.
This policy was introduced in CMake version 3.0. CMake version 3.25.1
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 un-
known targets. The NEW behavior for this policy is to report an error
if the target referenced in add_custom_command() is unknown or was de-
fined outside the current directory.
This policy was introduced in CMake version 3.0. CMake version 3.25.1
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.25.1
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 di-
rectly 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.25.1
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-expressions(7) and some diagnostics expect target names
to match a restricted pattern.
Target names may contain upper and lower case letters, numbers, the un-
derscore 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 pack-
age, 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 re-
served names or which do not match the validity pattern. The NEW be-
havior 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.25.1
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 be-
havior 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.25.1
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 be-
havior 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.25.1
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 be-
havior 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.25.1
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 in-
ternal 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 be-
havior 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.25.1
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 be-
havior 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.25.1
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 be-
havior 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.25.1
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 be-
havior 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.25.1
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 be-
havior 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.25.1
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.
See also the LINK_LIBRARIES_ONLY_TARGETS target property.
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 be-
havior 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.25.1
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 en-
tries in the INTERFACE_INCLUDE_DIRECTORIES of an IMPORTED target actu-
ally 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 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.25.1
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 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.25.1
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_policy() command to set this policy to OLD or NEW explicitly.
Unlike most policies, CMake version 3.25.1 does not warn by default
when this policy is not set and simply uses OLD behavior. See documen-
tation 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 un-
til 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 in-
cluding the result of an export() command.
This policy was introduced in CMake version 3.0. CMake version 3.25.1
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 explic-
itly, 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 signa-
tures.
This policy was introduced in CMake version 2.8.12. CMake version
3.25.1 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 ex-
pressions 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 replace-
ment in CMake 2.8.12. This new property is named consistently with the
INTERFACE_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_LI-
BRARIES(_<CONFIG>)? if this policy is NEW.
Warning-free future-compatible code which works with CMake 2.8.7 on-
wards 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 behav-
ior for this policy is to use the INTERFACE_LINK_LIBRARIES property for
in-build targets, and ignore the old properties matching (IM-
PORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.
This policy was introduced in CMake version 2.8.12. CMake version
3.25.1 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 en-
tries 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.25.1 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 de-
termining 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 ap-
plications 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 qt-
main.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.25.1 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 be-
cause 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.25.1 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_LI-
BRARY_<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 li-
braries.
The NEW behavior for this policy is to ignore CMAKE_SHARED_LI-
BRARY_<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.25.1 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.25.1 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.25.1 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 re-
spect 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.25.1 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.25.1 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.25.1 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) (lead-
ing 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.25.1 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 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.25.1 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.25.1 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 be-
cause 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.25.1 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 lib-
somelib.a or somelib.lib. For Makefile generators this produces an er-
ror 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.25.1 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.25.1 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.25.1 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.25.1 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.25.1 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_directories com-
mand). 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_li-
brary 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 up-
dated 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.25.1 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 physi-
cal 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.25.1 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_COMPATIBIL-
ITY 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.25.1 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-2022 Kitware, Inc. and Contributors
3.25.1 November 30, 2022 CMAKE-POLICIES(7)
Generated by dwww version 1.15 on Sun Jun 16 16:02:07 CEST 2024.