code:
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
:variable:`CMAKE_<LANG>_COMPILER_ID` variable to ``AppleClang`` instead
of ``Clang``.  However, existing projects may assume the compiler id for
Apple Clang is just ``Clang`` as it was in CMake versions prior to 3.0.
Therefore this policy determines for Apple Clang which compiler id to
report in the :variable:`CMAKE_<LANG>_COMPILER_ID` variable after
language ``<LANG>`` is enabled by the :command:`project` or
:command:`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``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0025 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0026
-------

Disallow use of the LOCATION property for build targets.

CMake 2.8.12 and lower allowed reading the :prop_tgt:`LOCATION` target
property (and configuration-specific variants) to
determine the eventual location of build targets.  This relies on the
assumption that all necessary information is available at
configure-time to determine the final location and filename of the
target.  However, this property is not fully determined until later at
generate-time.  At generate time, the :genex:`$<TARGET_FILE>` generator
expression can be used to determine the eventual :prop_tgt:`LOCATION` of a target
output.

Code which reads the :prop_tgt:`LOCATION` target property can be ported to
use the :genex:`$<TARGET_FILE>` generator expression together with the
:command:`file(GENERATE)` subcommand to generate a file containing
the target location.

The ``OLD`` behavior for this policy is to allow reading the :prop_tgt:`LOCATION`
properties from build-targets.  The ``NEW`` behavior for this policy is to
not to allow reading the :prop_tgt:`LOCATION` properties from build-targets.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
CMP0027
-------

Conditionally linked imported targets with missing include directories.

CMake 2.8.11 introduced introduced the concept of
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`, and a check at cmake time that the
entries in the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of an ``IMPORTED``
target actually exist.  CMake 2.8.11 also introduced generator expression
support in the :command:`target_link_libraries` command.  However, if an
imported target is linked as a result of a generator expression evaluation, the
entries in the :prop_tgt:`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 :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of a generator-expression
conditionally linked ``IMPORTED`` target does not exist.

The ``NEW`` behavior of this policy is to report an error if an entry in
the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of a generator-expression
conditionally linked ``IMPORTED`` target does not exist.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
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 :command:`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 :prop_tgt:`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`` behavior
for this policy is to issue a ``FATAL_ERROR`` if a link dependency contains
double-colons but is not an ``IMPORTED`` target or an ``ALIAS`` target.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0029
-------

The :command:`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.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0030
-------

The :command:`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.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0031
-------

The :command:`load_command` command should not be called.

This command was added in August 2002 to allow projects to add
arbitrary commands implemented in C or C++.  However, it does
not work when the toolchain in use does not match the ABI of
the CMake process.  It has been mostly superseded by the
:command:`macro` and :command:`function` commands.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0032
-------

The :command:`output_required_files` command should not be called.

This command was added in June 2001 to expose the then-current CMake
implicit dependency scanner.  CMake's real implicit dependency scanner
has evolved since then but is not exposed through this command.  The
scanning capabilities of this command are very limited and this
functionality is better achieved through dedicated outside tools.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0033
-------

The :command:`export_library_dependencies` command should not be called.

This command was added in January 2003 to export ``<tgt>_LIB_DEPENDS``
internal CMake cache entries to a file for installation with a project.
This was used at the time to allow transitive link dependencies to
work for applications outside of the original build tree of a project.
The functionality has been superseded by the :command:`export` and
:command:`install(EXPORT)` commands.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0034
-------

The :command:`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
:command:`add_executable` combined with :command:`add_custom_command`.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0035
-------

The :command:`variable_requires` command should not be called.

This command was introduced in November 2001 to perform some conditional
logic.  It has long been replaced by the :command:`if` command.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0036
-------

The :command:`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 :variable:`CMAKE_SYSTEM`
and :variable:`CMAKE_<LANG>_COMPILER` variables.

.. |disallowed_version| replace:: 3.0
.. include:: DISALLOWED_COMMAND.txt

.. include:: DEPRECATED.txt


code:
CMP0037
-------

Target names should not be reserved and should match a validity pattern.

CMake 2.8.12 and lower allowed creating targets using :command:`add_library`,
:command:`add_executable` and :command:`add_custom_target` with unrestricted
choice for the target name.  Newer cmake features such
as :manual:`cmake-generator-expressions(7)` and some
diagnostics expect target names to match a restricted pattern.

Target names may contain upper and lower case letters, numbers, the underscore
character (``_``), dot(``.``), plus(``+``) and minus(``-``).
As a special case, ``ALIAS`` and ``IMPORTED`` targets may contain
two consecutive colons.

Target names reserved by one or more CMake generators are not allowed.
Among others these include ``all``, ``clean``, ``help``, and ``install``.

Target names associated with optional features, such as ``test`` and
``package``, may also be reserved.  CMake 3.10 and below always reserve them.
CMake 3.11 and above reserve them only when the corresponding feature is
enabled (e.g. by including the :module:`CTest` or :module:`CPack` modules).

The ``OLD`` behavior for this policy is to allow creating targets with
reserved names or which do not match the validity pattern.
The ``NEW`` behavior for this policy is to report an error
if an add_* command is used with an invalid target name.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0038
-------

Targets may not link directly to themselves.

CMake 2.8.12 and lower allowed a build target to link to itself directly with
a :command:`target_link_libraries` call. This is an indicator of a bug in
user code.

The ``OLD`` behavior for this policy is to ignore targets which list themselves
in their own link implementation.  The ``NEW`` behavior for this policy is to
report an error if a target attempts to link to itself.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
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 :command:`target_link_libraries` command. This is an indicator
of a bug in user code.

The ``OLD`` behavior for this policy is to ignore attempts to set the link
libraries of utility targets.  The ``NEW`` behavior for this policy is to
report an error if an attempt is made to set the link libraries of a
utility target.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0040
-------

The target in the ``TARGET`` signature of :command:`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 :command:`add_custom_command`
if the target is unknown or was defined outside the current directory.

The ``OLD`` behavior for this policy is to ignore custom commands
for unknown targets.  The ``NEW`` behavior for this policy is to report
an error if the target referenced in :command:`add_custom_command` is
unknown or was defined outside the current directory.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0041
-------

Error on relative include with generator expression.

Diagnostics in CMake 2.8.12 and lower silently ignored an entry in the
:prop_tgt:`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 :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` generated
on an :prop_tgt:`IMPORTED` target for the install location should not contain
paths in the source directory or the build directory.

The ``OLD`` behavior for this policy is to ignore relative path entries if they
contain a generator expression. The ``NEW`` behavior for this policy is to report
an error if a generator expression appears in another location and the path is
relative.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0042
-------

:prop_tgt:`MACOSX_RPATH` is enabled by default.

CMake 2.8.12 and newer has support for using ``@rpath`` in a target's install
name.  This was enabled by setting the target property
:prop_tgt:`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 :prop_tgt:`INSTALL_NAME_DIR` and :variable:`CMAKE_INSTALL_NAME_DIR`
variables.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0043
-------

Ignore COMPILE_DEFINITIONS_<Config> properties

CMake 2.8.12 and lower allowed setting the
:prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` target property and
:prop_dir:`COMPILE_DEFINITIONS_<CONFIG>` directory property to apply
configuration-specific compile definitions.

Since CMake 2.8.10, the :prop_tgt:`COMPILE_DEFINITIONS` property has supported
:manual:`generator expressions <cmake-generator-expressions(7)>` for setting
configuration-dependent content.  The continued existence of the suffixed
variables is redundant, and causes a maintenance burden.  Population of the
:prop_tgt:`COMPILE_DEFINITIONS_DEBUG <COMPILE_DEFINITIONS_<CONFIG>>` property
may be replaced with a population of :prop_tgt:`COMPILE_DEFINITIONS` directly
or via :command:`target_compile_definitions`:

.. code-block:: cmake

  # Old Interfaces:
  set_property(TARGET tgt APPEND PROPERTY
    COMPILE_DEFINITIONS_DEBUG DEBUG_MODE
  )
  set_property(DIRECTORY APPEND PROPERTY
    COMPILE_DEFINITIONS_DEBUG DIR_DEBUG_MODE
  )

  # New Interfaces:
  set_property(TARGET tgt APPEND PROPERTY
    COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DEBUG_MODE>
  )
  target_compile_definitions(tgt PRIVATE $<$<CONFIG:Debug>:DEBUG_MODE>)
  set_property(DIRECTORY APPEND PROPERTY
    COMPILE_DEFINITIONS $<$<CONFIG:Debug>:DIR_DEBUG_MODE>
  )

The ``OLD`` behavior for this policy is to consume the content of the suffixed
:prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` target property when generating the
compilation command. The ``NEW`` behavior for this policy is to ignore the content
of the :prop_tgt:`COMPILE_DEFINITIONS_<CONFIG>` target property .

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0044
-------

Case sensitive ``<LANG>_COMPILER_ID`` generator expressions

CMake 2.8.12 introduced the ``<LANG>_COMPILER_ID``
:manual:`generator expressions <cmake-generator-expressions(7)>` to allow
comparison of the :variable:`CMAKE_<LANG>_COMPILER_ID` with a test value.  The
possible valid values are lowercase, but the comparison with the test value
was performed case-insensitively.

The ``OLD`` behavior for this policy is to perform a case-insensitive comparison
with the value in the ``<LANG>_COMPILER_ID`` expression. The ``NEW`` behavior
for this policy is to perform a case-sensitive comparison with the value in
the ``<LANG>_COMPILER_ID`` expression.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0045
-------

Error on non-existent target in get_target_property.

In CMake 2.8.12 and lower, the :command:`get_target_property` command accepted
a non-existent target argument without issuing any error or warning.  The
result variable is set to a ``-NOTFOUND`` value.

The ``OLD`` behavior for this policy is to issue no warning and set the result
variable to a ``-NOTFOUND`` value.  The ``NEW`` behavior
for this policy is to issue a ``FATAL_ERROR`` if the command is called with a
non-existent target.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0046
-------

Error on non-existent dependency in add_dependencies.

CMake 2.8.12 and lower silently ignored non-existent dependencies
listed in the :command:`add_dependencies` command.

The ``OLD`` behavior for this policy is to silently ignore non-existent
dependencies. The ``NEW`` behavior for this policy is to report an error
if non-existent dependencies are listed in the :command:`add_dependencies`
command.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0047
-------

Use ``QCC`` compiler id for the qcc drivers on QNX.

CMake 3.0 and above recognize that the QNX qcc compiler driver is
different from the GNU compiler.
CMake now prefers to present this to projects by setting the
:variable:`CMAKE_<LANG>_COMPILER_ID` variable to ``QCC`` instead
of ``GNU``.  However, existing projects may assume the compiler id for
QNX qcc is just ``GNU`` as it was in CMake versions prior to 3.0.
Therefore this policy determines for QNX qcc which compiler id to
report in the :variable:`CMAKE_<LANG>_COMPILER_ID` variable after
language ``<LANG>`` is enabled by the :command:`project` or
:command:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0047 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0048
-------

The :command:`project` command manages ``VERSION`` variables.

CMake version 3.0 introduced the ``VERSION`` option of the :command:`project`
command to specify a project version as well as the name.  In order to keep
:variable:`PROJECT_VERSION` and related variables consistent with variable
:variable:`PROJECT_NAME` it is necessary to set the ``VERSION`` variables
to the empty string when no ``VERSION`` is given to :command:`project`.
However, this can change behavior for existing projects that set ``VERSION``
variables themselves since :command:`project` may now clear them.
This policy controls the behavior for compatibility with such projects.

The ``OLD`` behavior for this policy is to leave ``VERSION`` variables untouched.
The ``NEW`` behavior for this policy is to set ``VERSION`` as documented by the
:command:`project` command.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
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})

.. note: no cmake highlighting since this syntax is deprecated

This was undocumented behavior.

The ``OLD`` behavior for this policy is to expand such variables when processing
the target sources.  The ``NEW`` behavior for this policy is to issue an error
if such variables need to be expanded.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0050
-------

Disallow add_custom_command SOURCE signatures.

CMake 2.8.12 and lower allowed a signature for :command:`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
:command:`add_custom_command` SOURCE signatures.  The ``NEW`` behavior for this
policy is to issue an error if such a signature is used.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0051
-------

.. versionadded:: 3.1

List :genex:`TARGET_OBJECTS` in SOURCES target property.

CMake 3.0 and lower did not include the ``TARGET_OBJECTS``
:manual:`generator expression <cmake-generator-expressions(7)>` when
returning the :prop_tgt:`SOURCES` target property.

Configure-time CMake code is not able to handle generator expressions.  If
using the :prop_tgt:`SOURCES` target property at configure time, it may be
necessary to first remove generator expressions using the
:command:`string(GENEX_STRIP)` command.  Generate-time CMake code such as
:command:`file(GENERATE)` can handle the content without stripping.

The ``OLD`` behavior for this policy is to omit ``TARGET_OBJECTS``
expressions from the :prop_tgt:`SOURCES` target property.  The ``NEW``
behavior for this policy is to include ``TARGET_OBJECTS`` expressions
in the output.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.1
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0052
-------

.. versionadded:: 3.1

Reject source and build dirs in installed
:prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`.

CMake 3.0 and lower allowed subdirectories of the source directory or build
directory to be in the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` of
installed and exported targets, if the directory was also a subdirectory of
the installation prefix.  This makes the installation depend on the
existence of the source dir or binary dir, and the installation will be
broken if either are removed after installation.

See :ref:`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
:prop_tgt:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.1
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0053
-------

.. versionadded:: 3.1

Simplify variable reference and escape sequence evaluation.

CMake 3.1 introduced a much faster implementation of evaluation of the
:ref:`Variable References` and :ref:`Escape Sequences` documented in the
:manual:`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
  :command:`configure_file` and :command:`string(CONFIGURE)`
  commands is no longer performed in other contexts.

* Literal ``${VAR}`` reference syntax may contain only
  alphanumeric characters (``A-Z``, ``a-z``, ``0-9``) and
  the characters ``_``, ``.``, ``/``, ``-``, and ``+``.
  Note that ``$`` is technically allowed in the ``NEW`` behavior, but is
  invalid for ``OLD`` behavior.  This is due to an oversight during the
  implementation of ``CMP0053`` and its use as a literal variable
  reference is discouraged for this reason.
  Variables with other characters in their name may still
  be referenced indirectly, e.g.

  .. code-block:: cmake

    set(varname "otherwise & disallowed $ characters")
    message("${${varname}}")

* The setting of policy :policy:`CMP0010` is not considered,
  so improper variable reference syntax is always an error.

* More characters are allowed to be escaped in variable names.
  Previously, only ``()#" \@^`` were valid characters to
  escape. Now any non-alphanumeric, non-semicolon, non-NUL
  character may be escaped following the ``escape_identity``
  production in the :ref:`Escape Sequences` section of the
  :manual:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.1
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0054
-------

.. versionadded:: 3.1

Only interpret :command:`if` arguments as variables or keywords when unquoted.

CMake 3.1 and above no longer implicitly dereference variables or
interpret keywords in an :command:`if` command argument when
it is a :ref:`Quoted Argument` or a :ref:`Bracket Argument`.

The ``OLD`` behavior for this policy is to dereference variables and
interpret keywords even if they are quoted or bracketed.
The ``NEW`` behavior is to not dereference variables or interpret keywords
that have been quoted or bracketed.

Given the following partial example:

::

  set(A E)
  set(E "")

  if("${A}" STREQUAL "")
    message("Result is TRUE before CMake 3.1 or when CMP0054 is OLD")
  else()
    message("Result is FALSE in CMake 3.1 and above if CMP0054 is NEW")
  endif()

After explicit expansion of variables this gives:

::

  if("E" STREQUAL "")

With the policy set to ``OLD`` implicit expansion reduces this semantically to:

::

  if("" STREQUAL "")

With the policy set to ``NEW`` the quoted arguments will not be
further dereferenced:

::

  if("E" STREQUAL "")

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.1
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0055
-------

.. versionadded:: 3.2

Strict checking for the :command:`break` command.

CMake 3.1 and lower allowed calls to the :command:`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 :command:`break` to be placed
outside of loop contexts and ignores any arguments.  The ``NEW`` behavior for this
policy is to issue an error if a misplaced break or any arguments are found.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.2
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0056
-------

.. versionadded:: 3.2

Honor link flags in :command:`try_compile` source-file signature.

The :command:`try_compile` command source-file signature generates a
``CMakeLists.txt`` file to build the source file into an executable.
In order to compile the source the same way as it might be compiled
by the calling project, the generated project sets the value of the
:variable:`CMAKE_<LANG>_FLAGS` variable to that in the calling project.
The value of the :variable:`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
:variable:`CMAKE_EXE_LINKER_FLAGS` variable in the generated test
project.  The ``NEW`` behavior for this policy is to set the value of
the :variable:`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
:variable:`CMAKE_POLICY_DEFAULT_CMP0056 <CMAKE_POLICY_DEFAULT_CMP<NNNN>>`
variable in the cache.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.2
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0056 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0057
-------

.. versionadded:: 3.3

Support new :command:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0058
-------

.. versionadded:: 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
generate them.  For example:

.. code-block:: cmake

  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 :generator:`Ninja`.
The Ninja build tool sees a rule listing ``byproduct.txt``
as a dependency and no rule listing it as an output.  Ninja then
complains that there is no way to satisfy the dependency and
stops building even though there are order-only dependencies
that ensure ``byproduct.txt`` will exist before its consumers
need it.  See discussion of this problem in `Ninja Issue 760`_
for further details on why Ninja works this way.

.. _Ninja Issue 760: https://github.com/ninja-build/ninja/issues/760

Instead of leaving byproducts undeclared in the rules that generate
them, Ninja expects byproducts to be listed along with other outputs.
Such rules may be marked with a ``restat`` option that tells Ninja
to check the timestamps of outputs after the rules run.  This
prevents byproducts whose timestamps do not change from causing
their dependents to re-build unnecessarily.

Since the above approach does not tell CMake what custom command
generates ``byproduct.txt``, the Ninja generator does not have
enough information to add the byproduct as an output of any rule.
CMake 2.8.12 and above work around this problem and allow projects
using the above approach to build by generating ``phony`` build
rules to tell Ninja to tolerate such missing files.  However, this
workaround prevents Ninja from diagnosing a dependency that is
really missing.  It also works poorly in in-source builds where
every custom command dependency, even on source files, needs to
be treated this way because CMake does not have enough information
to know which files are generated as byproducts of custom commands.

Introducing Byproducts
^^^^^^^^^^^^^^^^^^^^^^

CMake 3.2 introduced the ``BYPRODUCTS`` option to the
:command:`add_custom_command` and :command:`add_custom_target`
commands.  This option allows byproducts to be specified explicitly:

.. code-block:: cmake

  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 :generator:`Ninja` generator
to list byproducts among the outputs of the custom commands that
generate them, and is ignored by other generators.

CMake 3.3 and above prefer to require projects to specify custom
command byproducts explicitly so that it can avoid using the
``phony`` rule workaround altogether.  Policy ``CMP0058`` was
introduced to provide compatibility with existing projects that
still need the workaround.

This policy has no effect on generators other than :generator:`Ninja`.
The ``OLD`` behavior for this policy is to generate Ninja ``phony``
rules for unknown dependencies in the build tree.  The ``NEW``
behavior for this policy is to not generate these and instead
require projects to specify custom command ``BYPRODUCTS`` explicitly.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace::
   warns when it sees unknown dependencies in out-of-source build trees
.. include:: STANDARD_ADVICE.txt

The policy setting must be in scope at the end of the top-level
``CMakeLists.txt`` file of the project and has global effect.

.. include:: DEPRECATED.txt


code:
CMP0059
-------

.. versionadded:: 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 :prop_dir:`DEFINITIONS` directory property.  The
:prop_dir:`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 :command:`add_definitions` command.  The ``NEW`` behavior is
to behave as a normal user-defined directory property.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0060
-------

.. versionadded:: 3.3

Link libraries by full path even in implicit directories.

Policy :policy:`CMP0003` was introduced with the intention of always
linking library files by full path when a full path is given to the
:command:`target_link_libraries` command.  However, on some platforms
(e.g. HP-UX) the compiler front-end adds alternative library search paths
for the current architecture (e.g. ``/usr/lib/<arch>`` has alternatives
to libraries in ``/usr/lib`` for the current architecture).
On such platforms the :command:`find_library` may find a library such as
``/usr/lib/libfoo.so`` that does not belong to the current architecture.

Prior to policy :policy:`CMP0003` projects would still build in such
cases because the incorrect library path would be converted to ``-lfoo``
on the link line and the linker would find the proper library in the
arch-specific search path provided by the compiler front-end implicitly.
At the time we chose to remain compatible with such projects by always
converting library files found in implicit link directories to ``-lfoo``
flags to ask the linker to search for them.  This approach allowed existing
projects to continue to build while still linking to libraries outside
implicit link directories via full path (such as those in the build tree).

CMake does allow projects to override this behavior by using an
:ref:`IMPORTED library target <Imported Targets>` with its
:prop_tgt:`IMPORTED_LOCATION` property set to the desired full path to
a library file.  In fact, many :ref:`Find Modules` are learning to provide
:ref:`Imported Targets` instead of just the traditional ``Foo_LIBRARIES``
variable listing library files.  However, this makes the link line
generated for a library found by a Find Module depend on whether it
is linked through an imported target or not, which is inconsistent.
Furthermore, this behavior has been a source of confusion because the
generated link line for a library file depends on its location.  It is
also problematic for projects trying to link statically because flags
like ``-Wl,-Bstatic -lfoo -Wl,-Bdynamic`` may be used to help the linker
select ``libfoo.a`` instead of ``libfoo.so`` but then leak dynamic linking
to following libraries.  (See the :prop_tgt:`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 :command:`find_library` command could be
taught to use this information to help find libraries of the proper
architecture.

For these reasons, CMake 3.3 and above prefer to drop the special case
and link libraries by full path even when they are in implicit link
directories.  Policy ``CMP0060`` provides compatibility for existing
projects.

The ``OLD`` behavior for this policy is to ask the linker to search for
libraries whose full paths are known to be in implicit link directories.
The ``NEW`` behavior for this policy is to link libraries by full path even
if they are in implicit link directories.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0060 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0061
-------

.. versionadded:: 3.3

CTest does not by default tell ``make`` to ignore errors (``-i``).

The :command:`ctest_build` and :command:`build_command` commands no
longer generate build commands for :ref:`Makefile Generators` with
the ``-i`` option.  Previously this was done to help build as much
of tested projects as possible.  However, this behavior is not
consistent with other generators and also causes the return code
of the ``make`` tool to be meaningless.

Of course users may still add this option manually by setting
:variable:`CTEST_BUILD_COMMAND` or the ``MAKECOMMAND`` cache entry.
See the :ref:`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``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0062
-------

.. versionadded:: 3.3

Disallow :command:`install` of :command:`export` result.

The :command:`export()` command generates a file containing
:ref:`Imported Targets`, which is suitable for use from the build
directory.  It is not suitable for installation because it contains absolute
paths to buildsystem locations, and is particular to a single build
configuration.

The :command:`install(EXPORT)` generates and installs files which contain
:ref:`Imported Targets`.  These files are generated with relative paths
(unless the user specifies absolute paths), and are designed for
multi-configuration use.  See :ref:`Creating Packages` for more.

CMake 3.3 no longer allows the use of the :command:`install(FILES)` command
with the result of the :command:`export()` command.

The ``OLD`` behavior for this policy is to allow installing the result of
an :command:`export()` command.  The ``NEW`` behavior for this policy is
not to allow installing the result of an :command:`export()` command.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0063
-------

.. versionadded:: 3.3

Honor visibility properties for all target types.

The :prop_tgt:`<LANG>_VISIBILITY_PRESET` and
:prop_tgt:`VISIBILITY_INLINES_HIDDEN` target properties affect visibility
of symbols during dynamic linking.  When first introduced these properties
affected compilation of sources only in shared libraries, module libraries,
and executables with the :prop_tgt:`ENABLE_EXPORTS` property set.  This
was sufficient for the basic use cases of shared libraries and executables
with plugins.  However, some sources may be compiled as part of static
libraries or object libraries and then linked into a shared library later.
CMake 3.3 and above prefer to honor these properties for sources compiled
in all target types.  This policy preserves compatibility for projects
expecting the properties to work only for some target types.

The ``OLD`` behavior for this policy is to ignore the visibility properties
for static libraries, object libraries, and executables without exports.
The ``NEW`` behavior for this policy is to honor the visibility properties
for all target types.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.3
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0064
-------

.. versionadded:: 3.4

Recognize ``TEST`` as a operator for the :command:`if` command.

The ``TEST`` operator was added to the :command:`if` command to determine if a
given test name was created by the :command:`add_test` command.

The ``OLD`` behavior for this policy is to ignore the ``TEST`` operator.
The ``NEW`` behavior is to interpret the ``TEST`` operator.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.4
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0065
-------

.. versionadded:: 3.4

Do not add flags to export symbols from executables without
the :prop_tgt:`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 :prop_tgt:`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
:prop_tgt:`ENABLE_EXPORTS` target property.

The ``NEW`` behavior of this policy is to only use the additional link
flags when linking executables if the :prop_tgt:`ENABLE_EXPORTS` target
property is set to ``True``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.4
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0065 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0066
-------

.. versionadded:: 3.7

Honor per-config flags in :command:`try_compile` source-file signature.

The source file signature of the :command:`try_compile` command uses the value
of the :variable:`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
:variable:`CMAKE_<LANG>_FLAGS_DEBUG` variable.  CMake 3.7 and above prefer to
honor config-specific compiler flags too.  This policy provides compatibility
for projects that do not expect config-specific compiler flags to be used.

The ``OLD`` behavior of this policy is to ignore config-specific flag
variables like :variable:`CMAKE_<LANG>_FLAGS_DEBUG` and only use CMake's
built-in defaults for the current compiler and platform.

The ``NEW`` behavior of this policy is to honor config-specific flag
variabldes like :variable:`CMAKE_<LANG>_FLAGS_DEBUG`.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.7
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0066 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0067
-------

.. versionadded:: 3.8

Honor language standard in :command:`try_compile` source-file signature.

The :command:`try_compile` source file signature is intended to allow
callers to check whether they will be able to compile a given source file
with the current toolchain.  In order to match compiler behavior, any
language standard mode should match.  However, CMake 3.7 and below did not
do this.  CMake 3.8 and above prefer to honor the language standard settings
for ``C``, ``CXX`` (C++), and ``CUDA`` using the values of the variables:

* :variable:`CMAKE_C_STANDARD`
* :variable:`CMAKE_C_STANDARD_REQUIRED`
* :variable:`CMAKE_C_EXTENSIONS`
* :variable:`CMAKE_CXX_STANDARD`
* :variable:`CMAKE_CXX_STANDARD_REQUIRED`
* :variable:`CMAKE_CXX_EXTENSIONS`
* :variable:`CMAKE_CUDA_STANDARD`
* :variable:`CMAKE_CUDA_STANDARD_REQUIRED`
* :variable:`CMAKE_CUDA_EXTENSIONS`

This policy provides compatibility for projects that do not expect
the language standard settings to be used automatically.

The ``OLD`` behavior of this policy is to ignore language standard
setting variables when generating the ``try_compile`` test project.
The ``NEW`` behavior of this policy is to honor language standard
setting variables.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.8
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0067 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0068
-------

.. versionadded:: 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:

* :prop_tgt:`BUILD_WITH_INSTALL_RPATH` target property
* :prop_tgt:`SKIP_BUILD_RPATH` target property
* :variable:`CMAKE_SKIP_RPATH` variable
* :variable:`CMAKE_SKIP_INSTALL_RPATH` variable

Previously, setting :prop_tgt:`BUILD_WITH_INSTALL_RPATH` had the effect of
setting both the ``install_name`` of a target to :prop_tgt:`INSTALL_NAME_DIR`
and the ``RPATH`` to :prop_tgt:`INSTALL_RPATH`.  In CMake 3.9, it only affects
setting of ``RPATH``.  However, if one wants :prop_tgt:`INSTALL_NAME_DIR` to
apply to the target in the build tree, one may set
:prop_tgt:`BUILD_WITH_INSTALL_NAME_DIR`.

If :prop_tgt:`SKIP_BUILD_RPATH`, :variable:`CMAKE_SKIP_RPATH` or
:variable:`CMAKE_SKIP_INSTALL_RPATH` were used to strip the directory portion
of the ``install_name`` of a target, one may set ``INSTALL_NAME_DIR=""``
instead.

The ``OLD`` behavior of this policy is to use the ``RPATH`` settings for
``install_name`` on macOS.  The ``NEW`` behavior of this policy is to ignore
the ``RPATH`` settings for ``install_name`` on macOS.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.9
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0069
-------

.. versionadded:: 3.9

:prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` is enforced when enabled.

CMake 3.9 and newer prefer to add IPO flags whenever the
:prop_tgt:`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
:module:`CheckIPOSupported` module to check for support before enabling the
:prop_tgt:`INTERPROCEDURAL_OPTIMIZATION` target property.  This approach
allows a project to conditionally activate IPO when supported.  It also
allows an end user to set the :variable:`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 :prop_tgt:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.9
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt

Examples
^^^^^^^^

Behave like CMake 3.8 and do not apply any IPO flags except for Intel compiler
on Linux:

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.8)
  project(foo)

  # ...

  set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

Use the :module:`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:

.. code-block:: cmake

  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:

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
  project(foo)

  include(CheckIPOSupported)

  # ...

  check_ipo_supported(RESULT result)
  if(result)
    set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
  endif()

Apply IPO flags without any checks.  This may lead to build errors if IPO
is not supported by the compiler in the current environment.  Produce an
error if CMake does not know IPO flags for the current compiler:

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.9) # CMP0069 NEW
  project(foo)

  # ...

  set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)


code:
CMP0070
-------

.. versionadded:: 3.10

Define :command:`file(GENERATE)` behavior for relative paths.

CMake 3.10 and newer define that relative paths given to ``INPUT`` and
``OUTPUT`` arguments of ``file(GENERATE)`` are interpreted relative to the
current source and binary directories, respectively.  CMake 3.9 and lower did
not define any behavior for relative paths but did not diagnose them either
and accidentally treated them relative to the process working directory.
Policy ``CMP0070`` provides compatibility with projects that used the old
undefined behavior.

This policy affects behavior of relative paths given to ``file(GENERATE)``.
The ``OLD`` behavior for this policy is to treat the paths relative to the
working directory of CMake.  The ``NEW`` behavior for this policy is to
interpret relative paths with respect to the current source or binary
directory of the caller.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.10
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0071
-------

.. versionadded:: 3.10

Let :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` process
:prop_sf:`GENERATED` files.

Since version 3.10, CMake processes **regular** and :prop_sf:`GENERATED`
source files in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.
In earlier CMake versions, only **regular** source files were processed.
:prop_sf:`GENERATED` source files were ignored silently.

This policy affects how source files that are :prop_sf:`GENERATED`
get treated in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

The ``OLD`` behavior for this policy is to ignore :prop_sf:`GENERATED`
source files in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

The ``NEW`` behavior for this policy is to process :prop_sf:`GENERATED`
source files in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` just like regular
source files.

.. note::

  To silence the ``CMP0071`` warning source files can be excluded from
  :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` processing by setting the
  source file properties :prop_sf:`SKIP_AUTOMOC`, :prop_sf:`SKIP_AUTOUIC` or
  :prop_sf:`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)
  # ...

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.10
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0072
-------

.. versionadded:: 3.11

:module:`FindOpenGL` prefers GLVND by default when available.

The :module:`FindOpenGL` module provides an ``OpenGL::GL`` target and an
``OPENGL_LIBRARIES`` variable for projects to use for legacy GL interfaces.
When both a legacy GL library (e.g. ``libGL.so``) and GLVND libraries
for OpenGL and GLX (e.g. ``libOpenGL.so`` and ``libGLX.so``) are available,
the module must choose between them.  It documents an ``OpenGL_GL_PREFERENCE``
variable that can be used to specify an explicit preference.  When no such
preference is set, the module must choose a default preference.

CMake 3.11 and above prefer to choose GLVND libraries.  This policy provides
compatibility with projects that expect the legacy GL library to be used.

The ``OLD`` behavior for this policy is to set ``OpenGL_GL_PREFERENCE`` to
``LEGACY``.  The ``NEW`` behavior for this policy is to set
``OpenGL_GL_PREFERENCE`` to ``GLVND``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.11
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0073
-------

.. versionadded:: 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 :command:`export_library_dependencies` command as the
only user of these values.  That command has long been disallowed by
policy :policy:`CMP0033`, but the ``<tgt>_LIB_DEPENDS`` cache entries
were left for compatibility with possible non-standard uses by projects.

CMake 3.12 and above now prefer to not produce these cache entries
at all.  This policy provides compatibility with projects that have
not been updated to avoid using them.

The ``OLD`` behavior for this policy is to set ``<tgt>_LIB_DEPENDS`` cache
entries.  The ``NEW`` behavior for this policy is to not set them.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.12
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0074
-------

.. versionadded:: 3.12

:command:`find_package` uses ``<PackageName>_ROOT`` variables.

In CMake 3.12 and above the :command:`find_package(<PackageName>)` command now
searches prefixes specified by the :variable:`<PackageName>_ROOT` CMake
variable and the :envvar:`<PackageName>_ROOT` environment variable.
Package roots are maintained as a stack so nested calls to all ``find_*``
commands inside find modules and config packages also search the roots as
prefixes.  This policy provides compatibility with projects that have not been
updated to avoid using ``<PackageName>_ROOT`` variables for other purposes.

The ``OLD`` behavior for this policy is to ignore ``<PackageName>_ROOT``
variables.  The ``NEW`` behavior for this policy is to use
``<PackageName>_ROOT`` variables.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.12
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0075
-------

.. versionadded:: 3.12

Include file check macros honor ``CMAKE_REQUIRED_LIBRARIES``.

In CMake 3.12 and above, the

* ``check_include_file`` macro in the :module:`CheckIncludeFile` module, the
* ``check_include_file_cxx`` macro in the
  :module:`CheckIncludeFileCXX` module, and the
* ``check_include_files`` macro in the :module:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.12
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0076
-------

.. versionadded:: 3.13

The :command:`target_sources` command converts relative paths to absolute.

In CMake 3.13 and above, the :command:`target_sources` command now converts
relative source file paths to absolute paths in the following cases:

* Source files are added to the target's :prop_tgt:`INTERFACE_SOURCES`
  property.
* The target's :prop_tgt:`SOURCE_DIR` property differs from
  :variable:`CMAKE_CURRENT_SOURCE_DIR`.

A path that begins with a generator expression is always left unmodified.

This policy provides compatibility with projects that have not been updated
to expect this behavior.  The ``OLD`` behavior for this policy is to leave
all relative source file paths unmodified.  The ``NEW`` behavior of this
policy is to convert relative paths to absolute according to above rules.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0077
-------

.. versionadded:: 3.13

:command:`option` honors normal variables.

The :command:`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 :command:`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 :command:`option`
command *removes* a normal (non-cached) variable of the same name when:

* a cache entry of the specified name does not exist at all, or
* a cache entry of the specified name exists but has not been given
  a type (e.g. via ``-D<name>=ON`` on the command line).

In both of these cases (typically on the first run in a new build tree),
the :command:`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
:command:`option` command changes nothing and any normal variable of
the same name remains set.

In CMake 3.13 and above the :command:`option` command prefers to
do nothing when a normal variable of the given name already exists.
It does not create or update a cache entry or remove the normal variable.
The new behavior is consistent between the first and later runs in a
build tree.  This policy provides compatibility with projects that have
not been updated to expect the new behavior.

When the :command:`option` command sees a normal variable of the given
name:

* The ``OLD`` behavior for this policy is to proceed even when a normal
  variable of the same name exists.  If the cache entry does not already
  exist and have a type then it is created and/or given a type and the
  normal variable is removed.

* The ``NEW`` behavior for this policy is to do nothing when a normal
  variable of the same name exists.  The normal variable is not removed.
  The cache entry is not created or updated and is ignored if it exists.

See :policy:`CMP0126` for a similar policy for the :command:`set(CACHE)`
command, but note that there are some differences in ``NEW`` behavior
between the two policies.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

Use the :variable:`CMAKE_POLICY_DEFAULT_CMP0077
<CMAKE_POLICY_DEFAULT_CMP\<NNNN\>>` variable to set the policy for
a third-party project in a subdirectory without modifying it.

.. include:: DEPRECATED.txt


code:
CMP0078
-------

.. versionadded:: 3.13

:module:`UseSWIG` generates standard target names.

Starting with CMake 3.13, :module:`UseSWIG` generates now standard target
names. This policy provides compatibility with projects that expect the legacy
behavior.

The ``OLD`` behavior for this policy relies on
``UseSWIG_TARGET_NAME_PREFERENCE`` variable that can be used to specify an
explicit preference.  The value may be one of:

* ``LEGACY``: legacy strategy is applied. Variable
  ``SWIG_MODULE_<name>_REAL_NAME`` must be used to get real target name.
  This is the default if not specified.
* ``STANDARD``: target name matches specified name.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0079
-------

.. versionadded:: 3.13

:command:`target_link_libraries` allows use with targets in other directories.

Prior to CMake 3.13 the :command:`target_link_libraries` command did not
accept targets not created in the calling directory as its first argument
for calls that update the :prop_tgt:`LINK_LIBRARIES` of the target itself.
It did accidentally accept targets from other directories on calls that
only update the :prop_tgt:`INTERFACE_LINK_LIBRARIES`, but would simply
add entries to the property as if the call were made in the original
directory.  Thus link interface libraries specified this way were always
looked up by generators in the scope of the original target rather than
in the scope that called :command:`target_link_libraries`.

CMake 3.13 now allows the :command:`target_link_libraries` command to
be called from any directory to add link dependencies and link interface
libraries to targets created in other directories.  The entries are added
to :prop_tgt:`LINK_LIBRARIES` and :prop_tgt:`INTERFACE_LINK_LIBRARIES`
using a special (internal) suffix to tell the generators to look up the
names in the calling scope rather than the scope that created the target.

This policy provides compatibility with projects that already use
:command:`target_link_libraries` with the ``INTERFACE`` keyword
on a target in another directory to add :prop_tgt:`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
:command:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0080
-------

.. versionadded:: 3.13

:module:`BundleUtilities` cannot be included at configure time.

The macros provided by :module:`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 :module:`BundleUtilities` to
``cmake -P`` style scripts and install rules. Specifically, it looks for the
presence of :variable:`CMAKE_GENERATOR` and throws a fatal error if it exists.

The ``OLD`` behavior of this policy is to allow :module:`BundleUtilities` to
be included at configure time. The ``NEW`` behavior of this policy is to
disallow such inclusion.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0081
-------

.. versionadded:: 3.13

Relative paths not allowed in :prop_tgt:`LINK_DIRECTORIES` target property.

CMake 3.12 and lower allowed the :prop_dir:`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 :prop_tgt:`LINK_DIRECTORIES` target property
(which is initialized by the :prop_dir:`LINK_DIRECTORIES` directory property)
contains a relative path.

The ``OLD`` behavior for this policy is not to warn about relative paths
in the :prop_tgt:`LINK_DIRECTORIES` target property.  The ``NEW`` behavior for
this policy is to issue a ``FATAL_ERROR`` if :prop_tgt:`LINK_DIRECTORIES`
contains a relative path.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.13
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0082
-------

.. versionadded:: 3.14

Install rules from :command:`add_subdirectory` calls are interleaved with
those in caller.

CMake 3.13 and lower ran the install rules from :command:`add_subdirectory`
after all other install rules, even if :command:`add_subdirectory` was called
before the other install rules.  CMake 3.14 and above prefer to interleave
these :command:`add_subdirectory` install rules with the others so that
they are run in the order they are declared.  This policy provides
compatibility for projects that have not been updated to expect the
new behavior.

The ``OLD`` behavior for this policy is to run the install rules from
:command:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0082 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0083
-------

.. versionadded:: 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
:prop_tgt:`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 :prop_tgt:`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
:module:`CheckPIESupported` module to check for support to ensure that the
:prop_tgt:`POSITION_INDEPENDENT_CODE` target property for executables will be
honored at link time.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. Note::

   Android platform has a special handling of ``PIE`` so it is not required
   to use the :module:`CheckPIESupported` module to ensure flags are passed to
   the linker.

.. include:: DEPRECATED.txt

Examples
^^^^^^^^

Behave like CMake 3.13 and do not apply any ``PIE`` flags at link stage.

.. code-block:: cmake

  cmake_minimum_required(VERSION 3.13)
  project(foo)

  # ...

  add_executable(foo ...)
  set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)

Use the :module:`CheckPIESupported` module to detect whether ``PIE`` is
supported by the current linker and environment.  Apply ``PIE`` flags only
if the linker supports them.

.. code-block:: cmake

  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)


code:
CMP0084
-------

.. versionadded:: 3.14

The :module:`FindQt` module does not exist for :command:`find_package`.

The existence of :module:`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 :module:`FindQt` module does not
exist for :command:`find_package`. If a project really wants to use Qt 3 or 4,
it can call ``find_package(Qt[34])``, ``include(FindQt)``, or add
:module:`FindQt` to their :variable:`CMAKE_MODULE_PATH`.

The ``OLD`` behavior of this policy is for :module:`FindQt` to exist for
:command:`find_package`. The ``NEW`` behavior is to pretend that it doesn't
exist for :command:`find_package`.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0085
-------

.. versionadded:: 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
:command:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0086
-------

.. versionadded:: 3.14

:module:`UseSWIG` honors ``SWIG_MODULE_NAME`` via ``-module`` flag.

Starting with CMake 3.14, :module:`UseSWIG` passes option
``-module <module_name>`` to ``SWIG`` compiler if the file property
``SWIG_MODULE_NAME`` is specified. This policy provides compatibility with
projects that expect the legacy behavior.

The ``OLD`` behavior for this policy is to never pass ``-module`` option.
The ``NEW`` behavior is to pass ``-module`` option to ``SWIG`` compiler if
``SWIG_MODULE_NAME`` is specified.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0087
-------

.. versionadded:: 3.14

:command:`install(CODE)` and :command:`install(SCRIPT)` support generator
expressions.

In CMake 3.13 and earlier, :command:`install(CODE)` and
:command:`install(SCRIPT)` did not evaluate generator expressions.  CMake 3.14
and later will evaluate generator expressions for :command:`install(CODE)` and
:command:`install(SCRIPT)`.

The ``OLD`` behavior of this policy is for :command:`install(CODE)` and
:command:`install(SCRIPT)` to not evaluate generator expressions.  The ``NEW``
behavior is to evaluate generator expressions for :command:`install(CODE)` and
:command:`install(SCRIPT)`.

Note that it is the value of this policy setting at the end of the directory
scope that is important, not its setting at the time of the call to
:command:`install(CODE)` or :command:`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 :command:`include()`
rather than :command:`add_subdirectory()`).

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0088
-------

.. versionadded:: 3.14

:module:`FindBISON` runs bison in :variable:`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 :variable:`CMAKE_CURRENT_BINARY_DIR` as the
``WORKING_DIRECTORY`` of its :command:`add_custom_command` invocation.
This ensures that any implicitly generated file is written to the build
tree rather than the source.

This policy provides compatibility for projects that have not been updated
to expect the new behavior.

The ``OLD`` behavior for this policy is for ``BISON_TARGET`` to use
the current source directory for the ``WORKING_DIRECTORY`` and where
to generate implicit files. The ``NEW`` behavior of this policy is to
use the current binary directory for the ``WORKING_DIRECTORY`` and where
to generate implicit files.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.14
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0089
-------

.. versionadded:: 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
:variable:`CMAKE_<LANG>_COMPILER_ID` variable to ``XLClang`` instead
of ``XL``.  However, existing projects may assume the compiler id for
Clang-based XL is just ``XL`` as it was in CMake versions prior to 3.15.
Therefore this policy determines for Clang-based XL compilers which
compiler id to report in the :variable:`CMAKE_<LANG>_COMPILER_ID`
variable after language ``<LANG>`` is enabled by the :command:`project`
or :command:`enable_language` command.  The policy must be set prior
to the invocation of either command.

The ``OLD`` behavior for this policy is to use compiler id ``XL``.  The
``NEW`` behavior for this policy is to use compiler id ``XLClang``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the
:variable:`CMAKE_POLICY_WARNING_CMP0089 <CMAKE_POLICY_WARNING_CMP<NNNN>>`
variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0090
-------

.. versionadded:: 3.15

:command:`export(PACKAGE)` does not populate package registry by default.

In CMake 3.14 and below the :command:`export(PACKAGE)` command populated the
user package registry by default and users needed to set the
:variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` to disable it, e.g. in automated
build and packaging environments.  Since the user package registry is stored
outside the build tree, this side effect should not be enabled by default.
Therefore CMake 3.15 and above prefer that :command:`export(PACKAGE)` does
nothing unless an explicit :variable:`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 :command:`export(PACKAGE)` command
to populate the user package registry unless
:variable:`CMAKE_EXPORT_NO_PACKAGE_REGISTRY` is enabled.
The ``NEW`` behavior is for :command:`export(PACKAGE)` command to do nothing
unless the :variable:`CMAKE_EXPORT_PACKAGE_REGISTRY` is enabled.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0091
-------

.. versionadded:: 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 configuration because
there is a separate runtime library for Debug builds.

In CMake 3.14 and below, MSVC runtime library selection flags are added to
the default :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` cache entries by CMake
automatically.  This allows users to edit their cache entries to adjust the
flags.  However, the presence of such default flags is problematic for
projects that want to choose a different runtime library programmatically.
In particular, it requires string editing of the
:variable:`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 :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` values and instead
offer a first-class abstraction.  The :variable:`CMAKE_MSVC_RUNTIME_LIBRARY`
variable and :prop_tgt:`MSVC_RUNTIME_LIBRARY` target property may be set to
select the MSVC runtime library.  If they are not set then CMake uses the
default value ``MultiThreaded$<$<CONFIG:Debug>:Debug>DLL`` which is
equivalent to the original flags.

This policy provides compatibility with projects that have not been updated
to be aware of the abstraction.  The policy setting takes effect as of the
first :command:`project` or :command:`enable_language` command that enables
a language whose compiler targets the MSVC ABI.

.. note::

  Once the policy has taken effect at the top of a project, that choice
  must be used throughout the tree.  In projects that have nested projects
  in subdirectories, be sure to convert everything together.

The ``OLD`` behavior for this policy is to place MSVC runtime library
flags in the default :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>` cache
entries and ignore the :variable:`CMAKE_MSVC_RUNTIME_LIBRARY` abstraction.
The ``NEW`` behavior for this policy is to *not* place MSVC runtime
library flags in the default cache entries and use the abstraction instead.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0092
-------

.. versionadded:: 3.15

MSVC warning flags are not in :variable:`CMAKE_<LANG>_FLAGS` by default.

When using MSVC-like compilers in CMake 3.14 and below, warning flags
like ``/W3`` are added to :variable:`CMAKE_<LANG>_FLAGS` by default.
This is problematic for projects that want to choose a different warning
level programmatically.  In particular, it requires string editing of the
:variable:`CMAKE_<LANG>_FLAGS` variables with knowledge of the
CMake builtin defaults so they can be replaced.

CMake 3.15 and above prefer to leave out warning flags from the value of
:variable:`CMAKE_<LANG>_FLAGS` by default.

This policy provides compatibility with projects that have not been updated
to expect the lack of warning flags.  The policy setting takes effect as of
the first :command:`project` or :command:`enable_language` command that
initializes :variable:`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 language.
  In projects that have nested projects in subdirectories, be sure to
  convert everything together.

The ``OLD`` behavior for this policy is to place MSVC warning flags in the
default :variable:`CMAKE_<LANG>_FLAGS` cache entries.  The ``NEW`` behavior
for this policy is to *not* place MSVC warning flags in the default cache
entries.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0093
-------

.. versionadded:: 3.15

:module:`FindBoost` reports ``Boost_VERSION`` in ``x.y.z`` format.

In CMake 3.14 and below the module would report the Boost version
number as specified in the preprocessor definition ``BOOST_VERSION`` in
the ``boost/version.hpp`` file. In CMake 3.15 and later it is preferred
that the reported version number matches the ``x.y.z`` format reported
by the CMake package shipped with Boost ``1.70.0`` and later. The macro
value is still reported in the ``Boost_VERSION_MACRO`` variable.

The ``OLD`` behavior for this policy is for :module:`FindBoost` to report
``Boost_VERSION`` as specified in the preprocessor definition
``BOOST_VERSION`` in ``boost/version.hpp``. The ``NEW`` behavior for this
policy is for :module:`FindBoost` to report ``Boost_VERSION`` in
``x.y.z`` format.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0094
-------

.. versionadded:: 3.15

Modules :module:`FindPython3`, :module:`FindPython2` and :module:`FindPython`
use ``LOCATION`` for lookup strategy.

Starting with CMake 3.15, Modules :module:`FindPython3`, :module:`FindPython2`
and :module:`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``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.15
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0095
-------

.. versionadded:: 3.16

``RPATH`` entries are properly escaped in the intermediary CMake install script.

In CMake 3.15 and earlier, ``RPATH`` entries set via
:variable:`CMAKE_INSTALL_RPATH` or via :prop_tgt:`INSTALL_RPATH` have not been
escaped before being inserted into the ``cmake_install.cmake`` script. Dynamic
linkers on ELF-based systems (e.g. Linux and FreeBSD) allow certain keywords in
``RPATH`` entries, such as ``${ORIGIN}`` (More details are available in the
``ld.so`` man pages on those systems). The syntax of these keywords can match
CMake's variable syntax. In order to not be substituted (usually to an empty
string) already by the intermediary ``cmake_install.cmake`` script, the user had
to double-escape such ``RPATH`` keywords, e.g.
``set(CMAKE_INSTALL_RPATH "\\\${ORIGIN}/../lib")``. Since the intermediary
``cmake_install.cmake`` script is an implementation detail of CMake, CMake 3.16
and later will make sure ``RPATH`` entries are inserted literally by escaping
any coincidental CMake syntax.

The ``OLD`` behavior of this policy is to not escape ``RPATH`` entries in the
intermediary ``cmake_install.cmake`` script. The ``NEW`` behavior is to properly
escape coincidental CMake syntax in ``RPATH`` entries when generating the
intermediary ``cmake_install.cmake`` script.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.16
.. |WARNS_OR_DOES_NOT_WARN| replace::
   warns when it detects use of CMake-like syntax
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0096
-------

.. versionadded:: 3.16

The :command:`project` command preserves leading zeros in version components.

When a ``VERSION <major>[.<minor>[.<patch>[.<tweak>]]]]`` argument is given
to the :command:`project` command, it stores the version string in the
``PROJECT_VERSION`` variable and stores individual integer version components
in ``PROJECT_VERSION_{MAJOR,MINOR,PATCH,TWEAK}`` variables (see policy
:policy:`CMP0048`).  CMake 3.15 and below dropped leading zeros from each
component.  CMake 3.16 and higher prefer to preserve leading zeros.  This
policy provides compatibility for projects that have not been updated to
expect the new behavior.

The ``OLD`` behavior of this policy drops leading zeros in all components,
e.g.  such that version ``1.07.06`` becomes ``1.7.6``.  The ``NEW`` behavior
of this policy preserves the leading zeros in all components, such that
version ``1.07.06`` remains unchanged.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.16
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0097
-------

.. versionadded:: 3.16

:command:`ExternalProject_Add` with ``GIT_SUBMODULES ""`` initializes no
submodules.  The policy also applies to :command:`FetchContent_Declare`,
which uses the same download and update features as
:command:`ExternalProject_Add`.

The commands provide a ``GIT_SUBMODULES`` option which controls what submodules
to initialize and update. Starting with CMake 3.16, explicitly setting
``GIT_SUBMODULES`` to an empty string means no submodules will be initialized
or updated.

This policy provides compatibility for projects that have not been updated
to expect the new behavior.

The ``OLD`` behavior for this policy is for ``GIT_SUBMODULES`` when set to
an empty string to initialize and update all git submodules.
The ``NEW`` behavior for this policy is for ``GIT_SUBMODULES`` when set to
an empty string to initialize and update no git submodules.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.16
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0098
-------

.. versionadded:: 3.17

:module:`FindFLEX` runs ``flex`` in directory
:variable:`CMAKE_CURRENT_BINARY_DIR` when executing.

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 :variable:`CMAKE_CURRENT_BINARY_DIR`
as the ``WORKING_DIRECTORY`` of its :command:`add_custom_command` invocation.
This ensures 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 updated
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 implicit files. The ``NEW`` behavior of this policy is to
use the current binary directory for the ``WORKING_DIRECTORY`` relative to
which implicit files are generated unless provided as absolute path.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0099
-------

.. versionadded:: 3.17

Target link properties :prop_tgt:`INTERFACE_LINK_OPTIONS`,
:prop_tgt:`INTERFACE_LINK_DIRECTORIES` and :prop_tgt:`INTERFACE_LINK_DEPENDS`
are now transitive over private dependencies of static libraries.

In CMake 3.16 and below the interface link properties attached to libraries
are not propagated for private dependencies of static libraries.
Only the libraries themselves are propagated to link the dependent 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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0100
-------

.. versionadded:: 3.17

Let :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` process
header files that end with a ``.hh`` extension.

Since version 3.17, CMake processes header files that end with a
``.hh`` extension in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.
In earlier CMake versions, these header files were ignored by
:prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

This policy affects how header files that end with a ``.hh`` extension
get treated in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

The ``OLD`` behavior for this policy is to ignore ``.hh`` header files
in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC`.

The ``NEW`` behavior for this policy is to process ``.hh`` header files
in :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` just like other header files.

.. note::

  To silence the ``CMP0100`` warning source files can be excluded from
  :prop_tgt:`AUTOMOC` and :prop_tgt:`AUTOUIC` processing by setting the
  source file properties :prop_sf:`SKIP_AUTOMOC`, :prop_sf:`SKIP_AUTOUIC` or
  :prop_sf:`SKIP_AUTOGEN`.

  .. code-block:: cmake

    # 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)

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17.0
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0101
-------

.. versionadded:: 3.17

:command:`target_compile_options` now always honors the ``BEFORE`` keyword.

In CMake 3.16 and below, the :command:`target_compile_options` command
ignores the ``BEFORE`` keyword when inserting items into the
:prop_tgt:`COMPILE_OPTIONS` target property (``PRIVATE`` and ``PUBLIC``
items).  CMake 3.17 and later honors the ``BEFORE`` keyword in all cases.
This policy provides compatibility for projects that have not been updated
to expect the new behavior.

The behavior of inserting items into the :prop_tgt:`INTERFACE_COMPILE_OPTIONS`
target property (``PUBLIC`` and ``INTERFACE`` items) is not affected by this
policy.  The ``BEFORE`` keyword has always been honored when adding items to
:prop_tgt:`INTERFACE_COMPILE_OPTIONS`.

The ``OLD`` behavior for this policy is to not honor the ``BEFORE`` keyword
when inserting into the :prop_tgt:`COMPILE_OPTIONS` property.
The ``NEW`` behavior for this policy is to honor the ``BEFORE`` keyword in
all cases.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0102
-------

.. versionadded:: 3.17

The :command:`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 :command:`mark_as_advanced` command would create a new cache
entry with an ``UNINITIALIZED`` type and no value. When a :command:`find_path`
(or other similar ``find_`` command) would next run, it would find this
undefined 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 definition.
The ``NEW`` behavior of this policy is to ignore variables which do not
already exist in the cache.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn by default
.. include:: STANDARD_ADVICE.txt

See documentation of the :variable:`CMAKE_POLICY_WARNING_CMP0102
<CMAKE_POLICY_WARNING_CMP<NNNN>>` variable to control the warning.

.. include:: DEPRECATED.txt


code:
CMP0103
-------

.. versionadded:: 3.18

Multiple calls to :command:`export` command with same ``FILE`` without
``APPEND`` is no longer allowed.

In CMake 3.17 and below, multiple calls to :command:`export` command with the
same ``FILE`` without ``APPEND`` are accepted silently but only the last
occurrence is taken into account during the generation.

The ``OLD`` behavior for this policy is to ignore the multiple occurrences of
 :command:`export` command except the last one.

The ``NEW`` behavior of this policy is to raise an error on second call to
:command:`export` command with same ``FILE`` without ``APPEND``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.18
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0104
-------

.. versionadded:: 3.18

Initialize :variable:`CMAKE_CUDA_ARCHITECTURES` when
:variable:`CMAKE_CUDA_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` is ``NVIDIA``.
Raise an error if :prop_tgt:`CUDA_ARCHITECTURES` is empty.

:variable:`CMAKE_CUDA_ARCHITECTURES` introduced in CMake 3.18 is used to
initialize :prop_tgt:`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 specifying code generation
flags.

The ``OLD`` behavior for this policy is to not initialize
:variable:`CMAKE_CUDA_ARCHITECTURES` when
:variable:`CMAKE_CUDA_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` is ``NVIDIA``.
Empty :prop_tgt:`CUDA_ARCHITECTURES` is allowed.

The ``NEW`` behavior of this policy is to initialize
:variable:`CMAKE_CUDA_ARCHITECTURES` when
:variable:`CMAKE_CUDA_COMPILER_ID <CMAKE_<LANG>_COMPILER_ID>` is ``NVIDIA``
and raise an error if :prop_tgt:`CUDA_ARCHITECTURES` is empty during generation.

If :prop_tgt:`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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.18
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt

Examples
^^^^^^^^

.. code-block:: cmake

  set_target_properties(tgt PROPERTIES CUDA_ARCHITECTURES "35;50;72")

Generates code for real and virtual architectures ``30``, ``50`` and ``72``.

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES 70-real 72-virtual)

Generates code for real architecture ``70`` and virtual architecture ``72``.

.. code-block:: cmake

  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)

CMake will not pass any architecture flags to the compiler.


code:
CMP0105
-------

.. versionadded:: 3.18

:prop_tgt:`LINK_OPTIONS` and :prop_tgt:`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 during the
device link step.

The ``NEW`` behavior of this policy is to use the link options during the
device link step.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.18
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0106
-------

.. versionadded:: 3.18

The :module:`Documentation` module is removed.

The :module:`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 :module:`Documentation` to add
cache variables and find VTK documentation dependent packages. The ``NEW``
behavior is to act as an empty module.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.18
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0107
-------

.. versionadded:: 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 existing
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.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0108
-------

.. versionadded:: 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 itself.

The ``OLD`` behavior for this policy is to allow a target to link to a target
aliased to itself.

The ``NEW`` behavior of this policy is to prevent a target to link to itself
through an ``ALIAS`` target.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.17
.. |WARNS_OR_DOES_NOT_WARN| replace:: does *not* warn
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0109
-------

.. versionadded:: 3.19

:command:`find_program` requires permission to execute but not to read.

In CMake 3.18 and below, the :command:`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 policy is for ``find_program`` to require
execute permission but not read permission.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.19
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt


code:
CMP0110
-------

.. versionadded:: 3.19

:command:`add_test` supports arbitrary characters in test names.

:command:`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 explicitly
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 officially allows
the ``add_test`` command to support whitespace and other special 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
handling whitespace and special characters properly (if not using the
mentioned workaround).  The ``NEW`` behavior on the other hand allows names
with whitespace and special characters for tests created by ``add_test``.

.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.19
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt

.. include:: DEPRECATED.txt