Provided by: cmake-data_3.16.3-1ubuntu1.20.04.1_all bug

NAME

       cmake-policies - CMake Policies Reference

INTRODUCTION

       Policies in CMake are used to preserve backward compatible behavior across multiple releases.  When a new
       policy is introduced, newer CMake versions will begin to warn about the backward compatible behavior.  It
       is  possible  to  disable  the  warning by explicitly requesting the OLD, or backward compatible behavior
       using the cmake_policy() command.  It is  also  possible  to  request  NEW,  or  non-backward  compatible
       behavior  for  a  policy,  also  avoiding  the warning.  Each policy can also be set to either NEW or OLD
       behavior explicitly on the command line with the CMAKE_POLICY_DEFAULT_CMP<NNNN> variable.

       A policy is a deprecation mechanism and not a reliable feature toggle.  A policy should almost  never  be
       set  to OLD, except to silence warnings in an otherwise frozen or stable codebase, or temporarily as part
       of a larger migration path. The OLD behavior of each policy is undesirable and will be replaced  with  an
       error condition in a future release.

       The cmake_minimum_required() command does more than report an error if a too-old version of CMake is used
       to  build  a  project.   It  also  sets  all  policies introduced in that CMake version or earlier to NEW
       behavior.  To manage policies without increasing the  minimum  required  CMake  version,  the  if(POLICY)
       command may be used:

          if(POLICY CMP0990)
            cmake_policy(SET CMP0990 NEW)
          endif()

       This  has the effect of using the NEW behavior with newer CMake releases which users may be using and not
       issuing a compatibility warning.

       The setting of a policy is confined in some cases to not propagate to the parent scope.  For example,  if
       the  files  read  by the include() command or the find_package() command contain a use of cmake_policy(),
       that policy  setting  will  not  affect  the  caller  by  default.   Both  commands  accept  an  optional
       NO_POLICY_SCOPE keyword to control this behavior.

       The  CMAKE_MINIMUM_REQUIRED_VERSION  variable may also be used to determine whether to report an error on
       use of deprecated macros or functions.

POLICIES INTRODUCED BY CMAKE 3.16

   CMP0097
       ExternalProject_Add() with GIT_SUBMODULES "" initializes no submodules.

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

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

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

       This policy was introduced in CMake version 3.16.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.  Unlike most policies, CMake version 3.16.3 does not warn when this policy  is  not  set  and
       simply uses OLD behavior.

   CMP0096
       The project() command preserves leading zeros in version components.

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

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

       This policy was introduced in CMake version 3.16.  Unlike many policies, CMake version  3.16.3  does  not
       warn when this policy is not set and simply uses the OLD behavior.  Use the cmake_policy() command to set
       it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

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

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

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

       This  policy  was introduced in CMake version 3.16. CMake version 3.16.3 warns when the policy is not set
       and detected usage of CMake-like syntax and uses OLD behavior. Use the cmake_policy() command to  set  it
       to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.15

   CMP0094
       Modules FindPython3, FindPython2 and FindPython use LOCATION for lookup strategy.

       Starting with CMake 3.15, Modules  FindPython3,  FindPython2  and  FindPython  set  value  LOCATION  for,
       respectively,  variables  Python3_FIND_STRATEGY,  Python2_FIND_STRATEGY  and  Python_FIND_STRATEGY.  This
       policy provides compatibility with projects that expect the legacy behavior.

       The  OLD  behavior  for  this   policy   set   value   VERSION   for   variables   Python3_FIND_STRATEGY,
       Python2_FIND_STRATEGY and Python_FIND_STRATEGY.

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  many  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses the OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0093
       FindBoost reports Boost_VERSION in x.y.z format.

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

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

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  many  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses the OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0092
       MSVC warning flags are not in CMAKE_<LANG>_FLAGS by default.

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

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

       This policy provides compatibility with projects that have not been updated to expect the lack of warning
       flags.  The policy setting takes effect as of the  first  project()  or  enable_language()  command  that
       initializes CMAKE_<LANG>_FLAGS for a given lanuage <LANG>.

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

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

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  many  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0091
       MSVC runtime library flags are selected by an abstraction.

       Compilers  targeting  the  MSVC  ABI  have  flags  to  select  the MSVC runtime library.  Runtime library
       selection typically varies with build configuration because there is a separate runtime library for Debug
       builds.

       In  CMake  3.14  and  below,  MSVC  runtime  library  selection  flags   are   added   to   the   default
       CMAKE_<LANG>_FLAGS_<CONFIG>  cache entries by CMake automatically.  This allows users to edit their cache
       entries to adjust the flags.  However, the presence of such default flags  is  problematic  for  projects
       that  want  to  choose  a  different runtime library programmatically.  In particular, it requires string
       editing of the CMAKE_<LANG>_FLAGS_<CONFIG> variables with knowledge of the CMake builtin defaults so they
       can be replaced.

       CMake 3.15 and above prefer to leave the  MSVC  runtime  library  selection  flags  out  of  the  default
       CMAKE_<LANG>_FLAGS_<CONFIG>    values    and    instead    offer    a   first-class   abstraction.    The
       CMAKE_MSVC_RUNTIME_LIBRARY variable and MSVC_RUNTIME_LIBRARY target property may be  set  to  select  the
       MSVC    runtime    library.     If   they   are   not   set   then   CMake   uses   the   default   value
       MultiThreaded$<$<CONFIG:Debug>:Debug>DLL which is equivalent to the original flags.

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

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

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

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  many  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0090
       export(PACKAGE) does not populate package registry by default.

       In  CMake  3.14  and below the export(PACKAGE) command populated the user package registry by default and
       users needed to set the CMAKE_EXPORT_NO_PACKAGE_REGISTRY to disable  it,  e.g.  in  automated  build  and
       packaging  environments.   Since  the  user  package registry is stored outside the build tree, this side
       effect should not be enabled by default.  Therefore CMake 3.15 and above prefer that export(PACKAGE) does
       nothing unless an explicit CMAKE_EXPORT_PACKAGE_REGISTRY variable is  set  to  enable  it.   This  policy
       provides compatibility with projects that have not been updated.

       The  OLD  behavior  for  this policy is for export(PACKAGE) command to populate the user package registry
       unless CMAKE_EXPORT_NO_PACKAGE_REGISTRY is enabled.  The NEW behavior is for export(PACKAGE)  command  to
       do nothing unless the CMAKE_EXPORT_PACKAGE_REGISTRY is enabled.

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  most  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0089
       Compiler id for IBM Clang-based XL compilers is now XLClang.

       CMake  3.15  and  above  recognize  that  IBM’s  Clang-based XL compilers that define __ibmxl__ are a new
       front-end distinct from xlc with a different command line and set of capabilities.  CMake now prefers  to
       present  this  to  projects  by  setting  the CMAKE_<LANG>_COMPILER_ID variable to XLClang instead of XL.
       However, existing projects may assume the compiler id for Clang-based XL is just XL as it  was  in  CMake
       versions  prior to 3.15.  Therefore this policy determines for Clang-based XL compilers which compiler id
       to report in the CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the  project()  or
       enable_language() command.  The policy must be set prior to the invocation of either command.

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

       This policy was introduced in CMake version 3.15.  Use the cmake_policy() command to set this  policy  to
       OLD  or  NEW  explicitly.   Unlike most policies, CMake version 3.16.3 does not warn by default when this
       policy is not set and simply uses OLD behavior.  See documentation  of  the  CMAKE_POLICY_WARNING_CMP0089
       variable to control the warning.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.14

   CMP0088
       FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR when executing.

       The module provides a BISON_TARGET macro which generates BISON output.  In CMake 3.13 and below the macro
       would generate a custom command that runs bison in the source directory.  CMake 3.14 and later prefer  to
       run  it  in  the  build  directory  and  use  CMAKE_CURRENT_BINARY_DIR  as  the  WORKING_DIRECTORY of its
       add_custom_command() invocation.  This ensures that any implicitly generated file is written to the build
       tree rather than the source.

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

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

       This policy was introduced in CMake version 3.14.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.  Unlike most policies, CMake version 3.16.3 does not warn when this policy  is  not  set  and
       simply uses OLD behavior.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0087
       install(CODE) and install(SCRIPT) support generator expressions.

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

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

       Note that it is the value of this policy setting at the end of the directory scope that is important, not
       its  setting  at  the  time  of  the call to install(CODE) or install(SCRIPT).  This has implications for
       calling these commands from places that have their own policy scope but not  their  own  directory  scope
       (e.g. from files brought in via include() rather than add_subdirectory()).

       This  policy was introduced in CMake version 3.14.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0086
       UseSWIG honors SWIG_MODULE_NAME via -module flag.

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

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

       This policy was introduced in CMake version 3.14.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0085
       $<IN_LIST:...> handles empty list items.

       In CMake 3.13 and lower, the $<IN_LIST:...> generator expression always returned 0 if the first  argument
       was  empty,  even  if  the  list  contained an empty item. This behavior is inconsistent with the IN_LIST
       behavior of if(), which this generator expression is meant to emulate. CMake 3.14 and later handles  this
       case correctly.

       The  OLD behavior of this policy is for $<IN_LIST:...> to always return 0 if the first argument is empty.
       The NEW behavior is to return 1 if the first argument is empty and the list contains an empty item.

       This policy was introduced in CMake version 3.14.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0084
       The FindQt module does not exist for find_package().

       The existence of FindQt means that for Qt upstream to provide package config files that can be  found  by
       find_package(Qt),  the consuming project has to explicitly specify find_package(Qt CONFIG). Removing this
       module gives Qt a path forward for exporting its own config files which can easily be found by  consuming
       projects.

       This  policy pretends that CMake’s internal FindQt module does not exist for find_package(). If a project
       really wants to use Qt 3 or 4, it can call find_package(Qt[34]), include(FindQt), or add FindQt to  their
       CMAKE_MODULE_PATH.

       The OLD behavior of this policy is for FindQt to exist for find_package(). The NEW behavior is to pretend
       that it doesn’t exist for find_package().

       This  policy was introduced in CMake version 3.14.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0083
       To  control  generation  of Position Independent Executable (PIE) or not, some flags are required at link
       time.

       CMake 3.13 and lower did not add these link flags when POSITION_INDEPENDENT_CODE is set.

       The OLD behavior for this policy is to not manage PIE link flags. The NEW behavior is to add  link  flags
       if POSITION_INDEPENDENT_CODE is set:

       • Set  to  TRUE:  flags  to  produce a position independent executable are passed to the linker step. For
         example -pie for GCC.

       • Set to FALSE: flags not to produce a position independent executable are passed to the linker step. For
         example -no-pie for GCC.

       • Not set: no flags are passed to the linker step.

       Since a given linker may not support PIE flags in all environments  in  which  it  is  used,  it  is  the
       project’s  responsibility  to  use  the  CheckPIESupported module to check for support to ensure that the
       POSITION_INDEPENDENT_CODE target property for executables will be honored at link time.

       This policy was introduced in CMake version 3.14. Use the cmake_policy() command to set it to OLD or  NEW
       explicitly.   Unlike  most  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses OLD behavior.

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

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

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

          cmake_minimum_required(VERSION 3.13)
          project(foo)

          # ...

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

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

          cmake_minimum_required(VERSION 3.14) # CMP0083 NEW
          project(foo)

          include(CheckPIESupported)
          check_pie_supported()

          # ...

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

   CMP0082
       Install rules from add_subdirectory() calls are interleaved with those in caller.

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

       The OLD behavior for this policy is to run the install rules  from  add_subdirectory()  after  the  other
       install  rules.   The  NEW  behavior  for  this  policy is to run all install rules in the order they are
       declared.

       This policy was introduced in CMake version 3.14.  Unlike most policies, CMake version  3.16.3  does  not
       warn  by  default  when  this  policy  is not set and simply uses OLD behavior.  See documentation of the
       CMAKE_POLICY_WARNING_CMP0082 variable to control the warning.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.13

   CMP0081
       Relative paths not allowed in LINK_DIRECTORIES target property.

       CMake 3.12 and lower allowed the LINK_DIRECTORIES directory property to contain relative paths.  The base
       path for such relative entries is not well defined.  CMake 3.13 and later will issue a FATAL_ERROR if the
       LINK_DIRECTORIES  target  property  (which  is  initialized  by  the LINK_DIRECTORIES directory property)
       contains a relative path.

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

       This policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0080
       BundleUtilities cannot be included at configure time.

       The macros provided by BundleUtilities are intended  to  be  invoked  at  install  time  rather  than  at
       configure  time, because they depend on the listed targets already existing at the time they are invoked.
       If they are invoked at configure time, the targets haven’t been built yet, and the commands will fail.

       This policy restricts the inclusion of BundleUtilities to cmake  -P  style  scripts  and  install  rules.
       Specifically, it looks for the presence of CMAKE_GENERATOR and throws a fatal error if it exists.

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

       This policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0079
       target_link_libraries() allows use with targets in other directories.

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

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

       This  policy  provides  compatibility  with  projects  that  already use target_link_libraries() with the
       INTERFACE keyword on a target in another directory to add INTERFACE_LINK_LIBRARIES entries to  be  looked
       up  in  the  target’s directory.  Such projects should be updated to be aware of the new scoping rules in
       that case.

       The OLD behavior of this policy is to disallow target_link_libraries() calls naming targets from  another
       directory  except  in  the previously accidentally allowed case of using the INTERFACE keyword only.  The
       NEW behavior of this policy is to allow all such calls but use the new scoping rules.

       This policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0078
       UseSWIG generates standard target names.

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

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

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

       • STANDARD: target name matches specified name.

       This policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0077
       option() honors normal variables.

       The option() command is typically used to create a  cache  entry  to  allow  users  to  set  the  option.
       However,  there  are  cases in which a normal (non-cached) variable of the same name as the option may be
       defined by the project prior to calling the option() command.  For example, a project that embeds another
       project as a subdirectory may want to hard-code options of the subproject to build the way it needs.

       For historical reasons in CMake 3.12 and  below  the  option()  command  removes  a  normal  (non-cached)
       variable of the same name when:

       • a cache entry of the specified name does not exist at all, or

       • a  cache  entry of the specified name exists but has not been given a type (e.g. via -D<name>=ON on the
         command line).

       In both of these cases (typically on the first run in a new build tree), the option() command  gives  the
       cache  entry  type  BOOL and removes any normal (non-cached) variable of the same name.  In the remaining
       case that the cache entry of the specified name already exists and has a type (typically on later runs in
       a build tree), the option() command changes nothing and any normal variable of the same name remains set.

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

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

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

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

       This  policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0076
       The target_sources() command converts relative paths to absolute.

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

       • Source files are added to the target’s INTERFACE_SOURCES property.

       • The target’s SOURCE_DIR property differs from CMAKE_CURRENT_SOURCE_DIR.

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

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

       This policy was introduced in CMake version 3.13.  CMake version 3.16.3 warns when the policy is not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.12

   CMP0075
       Include file check macros honor CMAKE_REQUIRED_LIBRARIES.

       In CMake 3.12 and above, the

       • check_include_file macro in the CheckIncludeFile module, the

       • check_include_file_cxx macro in the CheckIncludeFileCXX module, and the

       • check_include_files macro in the CheckIncludeFiles module

       now prefer to link the check executable to the libraries listed in the CMAKE_REQUIRED_LIBRARIES variable.
       This policy provides compatibility with projects that have not been updated to expect this behavior.

       The OLD behavior for this policy is to ignore CMAKE_REQUIRED_LIBRARIES in the include file check  macros.
       The NEW behavior of this policy is to honor CMAKE_REQUIRED_LIBRARIES in the include file check macros.

       This  policy was introduced in CMake version 3.12.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0074
       find_package() uses <PackageName>_ROOT variables.

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

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

       This  policy was introduced in CMake version 3.12.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0073
       Do not produce legacy _LIB_DEPENDS cache entries.

       Ancient  CMake versions once used <tgt>_LIB_DEPENDS cache entries to propagate library link dependencies.
       This has long been done by other means, leaving the export_library_dependencies()  command  as  the  only
       user of these values.  That command has long been disallowed by policy CMP0033, but the <tgt>_LIB_DEPENDS
       cache entries were left for compatibility with possible non-standard uses by projects.

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

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

       This policy was introduced in CMake version 3.12.  Use the cmake_policy() command to set it to OLD or NEW
       explicitly.   Unlike  most  policies,  CMake version 3.16.3 does not warn when this policy is not set and
       simply uses OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.11

   CMP0072
       FindOpenGL prefers GLVND by default when available.

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

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

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

       This  policy was introduced in CMake version 3.11.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.10

   CMP0071
       Let AUTOMOC and AUTOUIC process GENERATED files.

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

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

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

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

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

       Source skip example:

          # ...
          set_property(SOURCE /path/to/file1.h PROPERTY SKIP_AUTOMOC ON)
          set_property(SOURCE /path/to/file2.h PROPERTY SKIP_AUTOUIC ON)
          set_property(SOURCE /path/to/file3.h PROPERTY SKIP_AUTOGEN ON)
          # ...

       This  policy was introduced in CMake version 3.10.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0070
       Define file(GENERATE) behavior for relative paths.

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

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

       This  policy was introduced in CMake version 3.10.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.9

   CMP0069
       INTERPROCEDURAL_OPTIMIZATION is enforced when enabled.

       CMake  3.9 and newer prefer to add IPO flags whenever the INTERPROCEDURAL_OPTIMIZATION target property is
       enabled and produce an error if flags are not known to CMake for the current  compiler.   Since  a  given
       compiler  may  not  support  IPO  flags  in all environments in which it is used, it is now the project’s
       responsibility  to  use  the  CheckIPOSupported  module  to  check  for  support  before   enabling   the
       INTERPROCEDURAL_OPTIMIZATION  target  property.  This approach allows a project to conditionally activate
       IPO when supported.  It also allows an end user to set the CMAKE_INTERPROCEDURAL_OPTIMIZATION variable in
       an environment known to support IPO even if the project does not enable the property.

       Since CMake 3.8 and lower only honored INTERPROCEDURAL_OPTIMIZATION for the Intel compiler on Linux, some
       projects may unconditionally enable the target property.  Policy CMP0069 provides compatibility with such
       projects.

       This policy takes effect whenever the IPO property is enabled.  The OLD behavior for this  policy  is  to
       add IPO flags only for Intel compiler on Linux.  The NEW behavior for this policy is to add IPO flags for
       the current compiler or produce an error if CMake does not know the flags.

       This  policy  was introduced in CMake version 3.9.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

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

          cmake_minimum_required(VERSION 3.8)
          project(foo)

          # ...

          set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

       Use the CheckIPOSupported module to detect whether IPO is supported by the current compiler, environment,
       and CMake version.  Produce a fatal error if support is not available:

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

          include(CheckIPOSupported)
          check_ipo_supported()

          # ...

          set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

       Apply IPO flags only if compiler supports it:

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

          include(CheckIPOSupported)

          # ...

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

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

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

          # ...

          set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

   CMP0068
       RPATH settings on macOS do not affect install_name.

       CMake  3.9 and newer remove any effect the following settings may have on the install_name of a target on
       macOS:

       • BUILD_WITH_INSTALL_RPATH target property

       • SKIP_BUILD_RPATH target property

       • CMAKE_SKIP_RPATH variable

       • CMAKE_SKIP_INSTALL_RPATH variable

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

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

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

       This policy was introduced in CMake version 3.9.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.8

   CMP0067
       Honor language standard in try_compile() source-file signature.

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

       • CMAKE_C_STANDARDCMAKE_C_STANDARD_REQUIREDCMAKE_C_EXTENSIONSCMAKE_CXX_STANDARDCMAKE_CXX_STANDARD_REQUIREDCMAKE_CXX_EXTENSIONSCMAKE_CUDA_STANDARDCMAKE_CUDA_STANDARD_REQUIREDCMAKE_CUDA_EXTENSIONS

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

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

       This  policy  was  introduced  in CMake version 3.8.  Unlike most policies, CMake version 3.16.3 does not
       warn by default when this policy is not set and simply uses  OLD  behavior.   See  documentation  of  the
       CMAKE_POLICY_WARNING_CMP0067 variable to control the warning.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.7

   CMP0066
       Honor per-config flags in try_compile() source-file signature.

       The source file signature of the try_compile() command uses the value of the CMAKE_<LANG>_FLAGS  variable
       in  the  test project so that the test compilation works as it would in the main project.  However, CMake
       3.6  and  below  do  not  also  honor   config-specific   compiler   flags   such   as   those   in   the
       CMAKE_<LANG>_FLAGS_DEBUG  variable.   CMake  3.7 and above prefer to honor config-specific compiler flags
       too.  This policy provides compatibility for projects that do not expect config-specific  compiler  flags
       to be used.

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

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

       This policy was introduced in CMake version 3.7.  Unlike most policies, CMake  version  3.16.3  does  not
       warn  by  default  when  this  policy  is not set and simply uses OLD behavior.  See documentation of the
       CMAKE_POLICY_WARNING_CMP0066 variable to control the warning.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.4

   CMP0065
       Do not add flags to export symbols from executables without the ENABLE_EXPORTS target property.

       CMake  3.3 and below, for historical reasons, always linked executables on some platforms with flags like
       -rdynamic to export symbols from the executables for use by any plugins they may load via dlopen.   CMake
       3.4  and  above prefer to do this only for executables that are explicitly marked with the ENABLE_EXPORTS
       target property.

       The OLD behavior of this policy is to always use the  additional  link  flags  when  linking  executables
       regardless of the value of the ENABLE_EXPORTS target property.

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

       This policy was introduced in CMake version 3.4.  Unlike most policies, CMake  version  3.16.3  does  not
       warn  by  default  when  this  policy  is not set and simply uses OLD behavior.  See documentation of the
       CMAKE_POLICY_WARNING_CMP0065 variable to control the warning.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0064
       Recognize TEST as a operator for the if() command.

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

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

       This  policy  was introduced in CMake version 3.4.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.3

   CMP0063
       Honor visibility properties for all target types.

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

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

       This  policy  was introduced in CMake version 3.3.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0062
       Disallow install() of export() result.

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

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

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

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

       This policy was introduced in CMake version 3.3.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

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

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

       Of  course  users  may  still  add this option manually by setting CTEST_BUILD_COMMAND or the MAKECOMMAND
       cache entry.  See the CTest Build Step MakeCommand setting documentation for their effects.

       The OLD behavior for this policy is to add -i to make calls in CTest.  The NEW behavior for  this  policy
       is to not add -i.

       This  policy  was  introduced  in CMake version 3.3.  Unlike most policies, CMake version 3.16.3 does not
       warn when this policy is not set and simply uses OLD behavior.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0060
       Link libraries by full path even in implicit directories.

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

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

       CMake  does  allow  projects  to  override  this  behavior  by  using an IMPORTED library target with its
       IMPORTED_LOCATION property set to the desired full path to a library file.  In fact,  many  Find  Modules
       are  learning  to provide Imported Targets instead of just the traditional Foo_LIBRARIES variable listing
       library files.  However, this makes the link line generated for a library found by a Find  Module  depend
       on  whether  it  is  linked  through an imported target or not, which is inconsistent.  Furthermore, this
       behavior has been a source of confusion because the generated link line for a library file depends on its
       location.  It is also problematic for projects trying to link statically because flags like  -Wl,-Bstatic
       -lfoo  -Wl,-Bdynamic  may  be  used to help the linker select libfoo.a instead of libfoo.so but then leak
       dynamic linking to following libraries.  (See the LINK_SEARCH_END_STATIC target property for  a  solution
       typically used for that problem.)

       When  the  special  case  for  libraries  in  implicit  link directories was first introduced the list of
       implicit link directories was simply hard-coded (e.g. /lib, /usr/lib, and  a  few  others).   Since  that
       time,  CMake  has  learned  to  detect  the implicit link directories used by the compiler front-end.  If
       necessary, the find_library() command could be taught to use this information to help find  libraries  of
       the proper architecture.

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

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

       This  policy  was  introduced  in CMake version 3.3.  Unlike most policies, CMake version 3.16.3 does not
       warn by default when this policy is not set and simply uses  OLD  behavior.   See  documentation  of  the
       CMAKE_POLICY_WARNING_CMP0060 variable to control the warning.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0059
       Do not treat DEFINITIONS as a built-in directory property.

       CMake 3.3 and above no longer make a list of definitions  available  through  the  DEFINITIONS  directory
       property.  The COMPILE_DEFINITIONS directory property may be used instead.

       The  OLD  behavior  for this policy is to provide the list of flags given so far to the add_definitions()
       command.  The NEW behavior is to behave as a normal user-defined directory property.

       This policy was introduced in CMake version 3.3.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0058
       Ninja requires custom command byproducts to be explicit.

       When an intermediate file generated during the build is consumed by an expensive  operation  or  a  large
       tree  of  dependents,  one  may  reduce  the  work needed for an incremental rebuild by updating the file
       timestamp only when its content changes.  With this approach the generation rule  must  have  a  separate
       output  file  that is always updated with a new timestamp that is newer than any dependencies of the rule
       so that the build tool re-runs the rule only when the input changes.  We refer  to  the  separate  output
       file as a rule’s witness and the generated file as a rule’s byproduct.

       Byproducts may not be listed as outputs because their timestamps are allowed to be older than the inputs.
       No  build  tools  (like  make)  that  existed  when  CMake was designed have a way to express byproducts.
       Therefore CMake versions prior to 3.2 had no way to specify them.   Projects  typically  left  byproducts
       undeclared in the rules that generate them.  For example:

          add_custom_command(
            OUTPUT witness.txt
            COMMAND ${CMAKE_COMMAND} -E copy_if_different
                    ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
                    byproduct.txt # timestamp may not change
            COMMAND ${CMAKE_COMMAND} -E touch witness.txt
            DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
            )
          add_custom_target(Provider DEPENDS witness.txt)
          add_custom_command(
            OUTPUT generated.c
            COMMAND expensive-task -i byproduct.txt -o generated.c
            DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/byproduct.txt
            )
          add_library(Consumer generated.c)
          add_dependencies(Consumer Provider)

       This  works well for all generators except Ninja.  The Ninja build tool sees a rule listing byproduct.txt
       as a dependency and no rule listing it as an output.  Ninja then  complains  that  there  is  no  way  to
       satisfy  the  dependency  and  stops  building  even though there are order-only dependencies that ensure
       byproduct.txt will exist before its consumers need it.  See discussion of this problem in Ninja Issue 760
       for further details on why Ninja works this way.

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

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

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

          add_custom_command(
            OUTPUT witness.txt
            BYPRODUCTS byproduct.txt # explicit byproduct specification
            COMMAND ${CMAKE_COMMAND} -E copy_if_different
                    ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
                    byproduct.txt # timestamp may not change
          ...

       The  BYPRODUCTS  option is used by the Ninja generator to list byproducts among the outputs of the custom
       commands that generate them, and is ignored by other generators.

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

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

       This  policy  was  introduced  in  CMake  version  3.3.   CMake version 3.16.3 warns when it sees unknown
       dependencies in out-of-source build trees if the policy is not set and then uses OLD behavior.   Use  the
       cmake_policy()  command  to set the policy to OLD or NEW explicitly.  The policy setting must be in scope
       at the end of the top-level CMakeLists.txt file of the project and has global effect.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0057
       Support new if() IN_LIST operator.

       CMake 3.3 adds support for the new IN_LIST operator.

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

       This  policy  was introduced in CMake version 3.3.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.2

   CMP0056
       Honor link flags in try_compile() source-file signature.

       The  try_compile() command source-file signature generates a CMakeLists.txt file to build the source file
       into an executable.  In order to compile the source the same way as it might be compiled by  the  calling
       project,  the  generated project sets the value of the CMAKE_<LANG>_FLAGS variable to that in the calling
       project.  The value of the CMAKE_EXE_LINKER_FLAGS variable may be needed in some cases too, but CMake 3.1
       and lower did not set it in the generated project.  CMake 3.2 and above prefer to set it so  that  linker
       flags  are  honored  as  well  as  compiler  flags.   This policy provides compatibility with the pre-3.2
       behavior.

       The OLD behavior for this policy is to not set the value of the CMAKE_EXE_LINKER_FLAGS  variable  in  the
       generated   test   project.    The   NEW   behavior   for  this  policy  is  to  set  the  value  of  the
       CMAKE_EXE_LINKER_FLAGS variable in the test project to the same as it is in the calling project.

       If the project code does not set the policy explicitly, users may set it on the command line by  defining
       the CMAKE_POLICY_DEFAULT_CMP0056 variable in the cache.

       This  policy  was  introduced  in CMake version 3.2.  Unlike most policies, CMake version 3.16.3 does not
       warn by default when this policy is not set and simply uses  OLD  behavior.   See  documentation  of  the
       CMAKE_POLICY_WARNING_CMP0056 variable to control the warning.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0055
       Strict checking for the break() command.

       CMake 3.1 and lower allowed calls to the break() command outside of a loop context and also  ignored  any
       given arguments.  This was undefined behavior.

       The  OLD  behavior  for this policy is to allow break() to be placed outside of loop contexts and ignores
       any arguments.  The NEW behavior for this policy is to issue  an  error  if  a  misplaced  break  or  any
       arguments are found.

       This  policy  was introduced in CMake version 3.2.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.1

   CMP0054
       Only interpret if() arguments as variables or keywords when unquoted.

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

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

       Given the following partial example:

          set(A E)
          set(E "")

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

       After explicit expansion of variables this gives:

          if("E" STREQUAL "")

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

          if("" STREQUAL "")

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

          if("E" STREQUAL "")

       This policy was introduced in CMake version 3.1.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0053
       Simplify variable reference and escape sequence evaluation.

       CMake 3.1 introduced a much faster implementation of evaluation of the  Variable  References  and  Escape
       Sequences  documented  in  the  cmake-language(7)  manual.  While the behavior is identical to the legacy
       implementation in most cases, some corner cases were cleaned up to simplify the behavior.  Specifically:

       • Expansion of @VAR@ reference syntax defined by the configure_file() and string(CONFIGURE)  commands  is
         no longer performed in other contexts.

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

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

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

       • More characters are allowed to be escaped in variable names.  Previously,  only  ()#"  \@^  were  valid
         characters  to  escape.  Now  any  non-alphanumeric,  non-semicolon,  non-NUL  character may be escaped
         following the escape_identity production in the  Escape  Sequences  section  of  the  cmake-language(7)
         manual.

       The  OLD  behavior  for  this  policy  is to honor the legacy behavior for variable references and escape
       sequences.  The NEW behavior is to use the simpler variable  expansion  and  escape  sequence  evaluation
       rules.

       This  policy  was introduced in CMake version 3.1.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0052
       Reject source and build dirs in installed INTERFACE_INCLUDE_DIRECTORIES.

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

       See Include Directories and Usage Requirements for more on specifying include directories for targets.

       The  OLD  behavior for this policy is to export the content of the INTERFACE_INCLUDE_DIRECTORIES with the
       source or binary directory.  The NEW behavior for this policy is to issue an error if such a directory is
       used.

       This policy was introduced in CMake version 3.1.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0051
       List TARGET_OBJECTS in SOURCES target property.

       CMake 3.0 and lower did not include the TARGET_OBJECTS generator expression when  returning  the  SOURCES
       target property.

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

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

       This  policy  was introduced in CMake version 3.1.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 3.0

   CMP0050
       Disallow add_custom_command SOURCE signatures.

       CMake  2.8.12  and  lower  allowed  a  signature  for  add_custom_command() which specified an input to a
       command.  This was undocumented behavior.  Modern use of CMake  associates  custom  commands  with  their
       output, rather than their input.

       The  OLD behavior for this policy is to allow the use of add_custom_command() SOURCE signatures.  The NEW
       behavior for this policy is to issue an error if such a signature is used.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0049
       Do not expand variables in target source entries.

       CMake 2.8.12 and lower performed an extra layer of variable expansion when evaluating source file names:

          set(a_source foo.c)
          add_executable(foo \${a_source})

       This was undocumented behavior.

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0048
       The project() command manages VERSION variables.

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

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

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

       CMake 3.0 and above recognize that the QNX qcc compiler driver is different from the GNU compiler.  CMake
       now prefers to present this to projects by setting the CMAKE_<LANG>_COMPILER_ID variable to  QCC  instead
       of GNU.  However, existing projects may assume the compiler id for QNX qcc is just GNU as it was in CMake
       versions  prior  to 3.0.  Therefore this policy determines for QNX qcc which compiler id to report in the
       CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is enabled by the project() or  enable_language()
       command.  The policy must be set prior to the invocation of either command.

       The  OLD behavior for this policy is to use the GNU compiler id for the qcc and QCC compiler drivers. The
       NEW behavior for this policy is to use the QCC compiler id for those drivers.

       This policy was introduced in CMake version 3.0.  Use the cmake_policy() command to set  this  policy  to
       OLD  or  NEW  explicitly.   Unlike most policies, CMake version 3.16.3 does not warn by default when this
       policy is not set and simply uses OLD behavior.  See documentation  of  the  CMAKE_POLICY_WARNING_CMP0047
       variable to control the warning.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0046
       Error on non-existent dependency in add_dependencies.

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

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0045
       Error on non-existent target in get_target_property.

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

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0044
       Case sensitive <LANG>_COMPILER_ID generator expressions

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

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0043
       Ignore COMPILE_DEFINITIONS_<Config> properties

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

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

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

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

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0042
       MACOSX_RPATH is enabled by default.

       CMake  2.8.12  and  newer  has  support for using @rpath in a target’s install name.  This was enabled by
       setting the target property MACOSX_RPATH.  The @rpath in an install name is a more flexible and  powerful
       mechanism than @executable_path or @loader_path for locating shared libraries.

       CMake  3.0  and  later  prefer  this property to be ON by default.  Projects wanting @rpath in a target’s
       install name may remove any setting of the INSTALL_NAME_DIR and CMAKE_INSTALL_NAME_DIR variables.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0041
       Error on relative include with generator expression.

       Diagnostics in CMake 2.8.12 and lower silently ignored an entry in the INTERFACE_INCLUDE_DIRECTORIES of a
       target if it contained a generator expression at any position.

       The path entries in that target property should not be relative. High-level API  should  ensure  that  by
       adding either a source directory or a install directory prefix, as appropriate.

       As  an  additional  diagnostic, the INTERFACE_INCLUDE_DIRECTORIES generated on an IMPORTED target for the
       install location should not contain paths in the source directory or the build directory.

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0040
       The target in the TARGET signature of add_custom_command() must exist and must be defined in the  current
       directory.

       CMake  2.8.12  and  lower  silently  ignored  a  custom  command  created  with  the  TARGET signature of
       add_custom_command() if the target is unknown or was defined outside the current directory.

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0039
       Utility targets may not have link dependencies.

       CMake  2.8.12  and  lower  allowed  using  utility  targets  in  the  left  hand  side  position  of  the
       target_link_libraries() command. This is an indicator of a bug in user code.

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0038
       Targets may not link directly to themselves.

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

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

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

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

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

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

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

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

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0036
       The build_name() command should not be called.

       This command was added in May 2001 to compute a name  for  the  current  operating  system  and  compiler
       combination.   The  command  has long been documented as discouraged and replaced by the CMAKE_SYSTEM and
       CMAKE_<LANG>_COMPILER variables.

       CMake >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow  the
       command  to  be  called.   The NEW behavior for this policy is to issue a FATAL_ERROR when the command is
       called.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0035
       The variable_requires() command should not be called.

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

       CMake  >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow the
       command to be called.  The NEW behavior for this policy is to issue a FATAL_ERROR  when  the  command  is
       called.

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0034
       The utility_source() command should not be called.

       This  command  was introduced in March 2001 to help build executables used to generate other files.  This
       approach has long been replaced by add_executable() combined with add_custom_command().

       CMake >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow  the
       command  to  be  called.   The NEW behavior for this policy is to issue a FATAL_ERROR when the command is
       called.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0033
       The export_library_dependencies() command should not be called.

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

       CMake  >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow the
       command to be called.  The NEW behavior for this policy is to issue a FATAL_ERROR  when  the  command  is
       called.

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0032
       The output_required_files() command should not be called.

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

       CMake >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow  the
       command  to  be  called.   The NEW behavior for this policy is to issue a FATAL_ERROR when the command is
       called.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0031
       The load_command() command should not be called.

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

       CMake >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow  the
       command  to  be  called.   The NEW behavior for this policy is to issue a FATAL_ERROR when the command is
       called.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0030
       The use_mangled_mesa() command should not be called.

       This command was created in September 2001 to support VTK before modern CMake language and custom command
       capabilities.  VTK has not used it in years.

       CMake >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow  the
       command  to  be  called.   The NEW behavior for this policy is to issue a FATAL_ERROR when the command is
       called.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0029
       The subdir_depends() command should not be called.

       The implementation of this command has been  empty  since  December  2001  but  was  kept  in  CMake  for
       compatibility for a long time.

       CMake  >= 3.0 prefer that this command never be called.  The OLD behavior for this policy is to allow the
       command to be called.  The NEW behavior for this policy is to issue a FATAL_ERROR  when  the  command  is
       called.

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0028
       Double colon in target name means ALIAS or IMPORTED target.

       CMake   2.8.12   and   lower   allowed   the   use   of   targets   and   files  with  double  colons  in
       target_link_libraries(), with some buildsystem generators.

       The use of double-colons is a common pattern used to namespace IMPORTED targets and ALIAS targets.   When
       computing  the  link dependencies of a target, the name of each dependency could either be a target, or a
       file on disk.  Previously, if a target was not found with a matching name, the  name  was  considered  to
       refer  to a file on disk.  This can lead to confusing error messages if there is a typo in what should be
       a target name.

       The OLD behavior for this policy is to search for targets, then files on disk, even if  the  search  term
       contains  double-colons.  The NEW behavior for this policy is to issue a FATAL_ERROR if a link dependency
       contains double-colons but is not an IMPORTED target or an ALIAS target.

       This policy was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is  not  set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0027
       Conditionally linked imported targets with missing include directories.

       CMake 2.8.11 introduced introduced the concept of INTERFACE_INCLUDE_DIRECTORIES, and  a  check  at  cmake
       time  that  the entries in the INTERFACE_INCLUDE_DIRECTORIES of an IMPORTED target actually exist.  CMake
       2.8.11 also introduced generator expression support in the target_link_libraries() command.  However,  if
       an  imported  target  is  linked  as  a  result  of a generator expression evaluation, the entries in the
       INTERFACE_INCLUDE_DIRECTORIES of that target were not checked for existence as they should be.

       The OLD behavior of this policy is to report a warning if an entry in  the  INTERFACE_INCLUDE_DIRECTORIES
       of a generator-expression conditionally linked IMPORTED target does not exist.

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0026
       Disallow use of the LOCATION property for build targets.

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

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

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0025
       Compiler id for Apple Clang is now AppleClang.

       CMake  3.0 and above recognize that Apple Clang is a different compiler than upstream Clang and that they
       have different version  numbers.   CMake  now  prefers  to  present  this  to  projects  by  setting  the
       CMAKE_<LANG>_COMPILER_ID  variable to AppleClang instead of Clang.  However, existing projects may assume
       the compiler id for Apple Clang is just Clang as it was in CMake versions prior to 3.0.   Therefore  this
       policy  determines  for  Apple Clang which compiler id to report in the CMAKE_<LANG>_COMPILER_ID variable
       after language <LANG> is enabled by the project() or enable_language() command.  The policy must  be  set
       prior to the invocation of either command.

       The OLD behavior for this policy is to use compiler id Clang.  The NEW behavior for this policy is to use
       compiler id AppleClang.

       This  policy  was  introduced in CMake version 3.0.  Use the cmake_policy() command to set this policy to
       OLD or NEW explicitly.  Unlike most policies, CMake version 3.16.3 does not warn  by  default  when  this
       policy  is  not  set and simply uses OLD behavior.  See documentation of the CMAKE_POLICY_WARNING_CMP0025
       variable to control the warning.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0024
       Disallow include export result.

       CMake  2.8.12  and  lower  allowed  use of the include() command with the result of the export() command.
       This relies on the assumption that the export() command has an immediate effect at configure-time  during
       a  cmake  run.  Certain properties of targets are not fully determined until later at generate-time, such
       as the link language and complete list of link libraries.  Future refactoring will change the  effect  of
       the  export() command to be executed at generate-time.  Use ALIAS targets instead in cases where the goal
       is to refer to targets by another name.

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

       This  policy  was introduced in CMake version 3.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

POLICIES INTRODUCED BY CMAKE 2.8

   CMP0023
       Plain and keyword target_link_libraries() signatures cannot be mixed.

       CMake  2.8.12  introduced  the target_link_libraries() signature using the PUBLIC, PRIVATE, and INTERFACE
       keywords to generalize the LINK_PUBLIC and LINK_PRIVATE keywords  introduced  in  CMake  2.8.7.   Use  of
       signatures  with  any  of  these  keywords sets the link interface of a target explicitly, even if empty.
       This produces confusing behavior when used in combination with  the  historical  behavior  of  the  plain
       target_link_libraries() signature.  For example, consider the code:

          target_link_libraries(mylib A)
          target_link_libraries(mylib PRIVATE B)

       After  the  first  line  the  link  interface  has  not  been  set explicitly so CMake would use the link
       implementation, A, as the link interface.  However, the second line sets the link interface to empty.  In
       order to avoid this subtle behavior CMake now prefers to disallow mixing the plain and keyword signatures
       of target_link_libraries() for a single target.

       The OLD behavior for this policy is to allow keyword and plain target_link_libraries() signatures  to  be
       mixed.  The NEW behavior for this policy is to not to allow mixing of the keyword and plain signatures.

       This  policy  was  introduced in CMake version 2.8.12.  CMake version 3.16.3 warns when the policy is not
       set and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0022
       INTERFACE_LINK_LIBRARIES defines the link interface.

       CMake    2.8.11   constructed   the   ‘link   interface’   of   a   target   from   properties   matching
       (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.  The modern way to specify config-sensitive content  is
       to use generator expressions and the IMPORTED_ prefix makes uniform processing of the link interface with
       generator  expressions  impossible.   The  INTERFACE_LINK_LIBRARIES  target  property was introduced as a
       replacement   in   CMake   2.8.12.    This   new   property    is    named    consistently    with    the
       INTERFACE_COMPILE_DEFINITIONS,  INTERFACE_INCLUDE_DIRECTORIES  and  INTERFACE_COMPILE_OPTIONS properties.
       For in-build targets, CMake will use the INTERFACE_LINK_LIBRARIES property as  the  source  of  the  link
       interface  only if policy CMP0022 is NEW.  When exporting a target which has this policy set to NEW, only
       the INTERFACE_LINK_LIBRARIES property will be processed and generated for the IMPORTED target by default.
       A new option to the install(EXPORT) and export commands allows export of  the  old-style  properties  for
       compatibility  with  downstream  users  of CMake versions older than 2.8.12.  The target_link_libraries()
       command will no longer populate the  properties  matching  LINK_INTERFACE_LIBRARIES(_<CONFIG>)?  if  this
       policy is NEW.

       Warning-free  future-compatible  code  which  works  with CMake 2.8.7 onwards can be written by using the
       LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries().

       The OLD behavior for this policy is to ignore the INTERFACE_LINK_LIBRARIES property for in-build targets.
       The NEW behavior for this policy is to use the INTERFACE_LINK_LIBRARIES property  for  in-build  targets,
       and ignore the old properties matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.

       This  policy  was  introduced in CMake version 2.8.12.  CMake version 3.16.3 warns when the policy is not
       set and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0021
       Fatal error on relative paths in INCLUDE_DIRECTORIES target property.

       CMake  2.8.10.2 and lower allowed the INCLUDE_DIRECTORIES target property to contain relative paths.  The
       base path for such relative entries is not well defined.   CMake  2.8.12  issues  a  FATAL_ERROR  if  the
       INCLUDE_DIRECTORIES property contains a relative path.

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

       This  policy  was  introduced in CMake version 2.8.12.  CMake version 3.16.3 warns when the policy is not
       set and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0020
       Automatically link Qt executables to qtmain target on Windows.

       CMake  2.8.10 and lower required users of Qt to always specify a link dependency to the qtmain.lib static
       library manually on Windows.  CMake 2.8.11 gained the ability to  evaluate  generator  expressions  while
       determining  the link dependencies from IMPORTED targets.  This allows CMake itself to automatically link
       executables which link to Qt to the qtmain.lib library when using IMPORTED Qt targets.  For  applications
       already  linking  to qtmain.lib, this should have little impact.  For applications which supply their own
       alternative WinMain implementation and for applications which use the QAxServer library,  this  automatic
       linking will need to be disabled as per the documentation.

       The OLD behavior for this policy is not to link executables to qtmain.lib automatically when they link to
       the  QtCore  IMPORTED  target.   The  NEW  behavior  for this policy is to link executables to qtmain.lib
       automatically when they link to QtCore IMPORTED target.

       This policy was introduced in CMake version 2.8.11.  CMake version 3.16.3 warns when the  policy  is  not
       set and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0019
       Do not re-expand variables in include and link information.

       CMake 2.8.10 and lower re-evaluated  values  given  to  the  include_directories,  link_directories,  and
       link_libraries  commands to expand any leftover variable references at the end of the configuration step.
       This was for strict compatibility with VERY early CMake versions because all variable references are  now
       normally  evaluated  during  CMake language processing.  CMake 2.8.11 and higher prefer to skip the extra
       evaluation.

       The OLD behavior for this policy is to re-evaluate the values for strict compatibility.  The NEW behavior
       for this policy is to leave the values untouched.

       This policy was introduced in CMake version 2.8.11.  CMake version 3.16.3 warns when the  policy  is  not
       set and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0018
       Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS variable.

       CMake 2.8.8 and lower compiled sources in SHARED and MODULE libraries using the value of the undocumented
       CMAKE_SHARED_LIBRARY_<Lang>_FLAGS platform variable.   The  variable  contained  platform-specific  flags
       needed  to compile objects for shared libraries.  Typically it included a flag such as -fPIC for position
       independent code but also included other flags needed on  certain  platforms.   CMake  2.8.9  and  higher
       prefer  instead  to use the POSITION_INDEPENDENT_CODE target property to determine what targets should be
       position  independent,  and  new  undocumented  platform  variables  to  select  flags   while   ignoring
       CMAKE_SHARED_LIBRARY_<Lang>_FLAGS completely.

       The  default  for  either  approach  produces  identical  compilation  flags,  but  if a project modifies
       CMAKE_SHARED_LIBRARY_<Lang>_FLAGS from its original value this policy determines which approach to use.

       The OLD behavior for this policy is to ignore the POSITION_INDEPENDENT_CODE property for all targets  and
       use the modified value of CMAKE_SHARED_LIBRARY_<Lang>_FLAGS for SHARED and MODULE libraries.

       The NEW behavior for this policy is to ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS whether it is modified or
       not and honor the POSITION_INDEPENDENT_CODE target property.

       This policy was introduced in CMake version 2.8.9.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0017
       Prefer files from the CMake module directory when including from there.

       Starting with CMake 2.8.4, if a cmake-module shipped with  CMake  (i.e.   located  in  the  CMake  module
       directory)  calls  include()  or  find_package(),  the  files  located  in the CMake module directory are
       preferred over the files in CMAKE_MODULE_PATH.  This makes sure  that  the  modules  belonging  to  CMake
       always  get those files included which they expect, and against which they were developed and tested.  In
       all other cases, the files found in CMAKE_MODULE_PATH still take precedence over the ones  in  the  CMake
       module  directory.  The OLD behavior is to always prefer files from CMAKE_MODULE_PATH over files from the
       CMake modules directory.

       This policy was introduced in CMake version 2.8.4.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0016
       target_link_libraries() reports error if its only argument is not a target.

       In  CMake 2.8.2 and lower the target_link_libraries() command silently ignored if it was called with only
       one argument, and this argument wasn’t a valid target.  In CMake 2.8.3 and above it reports an  error  in
       this case.

       This policy was introduced in CMake version 2.8.3.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0015
          link_directories() treats paths relative to the source dir.

       In CMake 2.8.0 and lower the link_directories() command passed relative paths unchanged  to  the  linker.
       In  CMake 2.8.1 and above the link_directories() command prefers to interpret relative paths with respect
       to CMAKE_CURRENT_SOURCE_DIR, which is consistent with include_directories() and other commands.  The  OLD
       behavior  for  this policy is to use relative paths verbatim in the linker command.  The NEW behavior for
       this policy is  to  convert  relative  paths  to  absolute  paths  by  appending  the  relative  path  to
       CMAKE_CURRENT_SOURCE_DIR.

       This policy was introduced in CMake version 2.8.1.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0014
       Input directories must have CMakeLists.txt.

       CMake versions before 2.8 silently ignored missing CMakeLists.txt  files  in  directories  referenced  by
       add_subdirectory()  or   subdirs(), treating them as if present but empty.  In CMake 2.8.0 and above this
       cmake_policy() determines whether or not the case is an error.  The OLD behavior for this  policy  is  to
       silently ignore the problem.  The NEW behavior for this policy is to report an error.

       This policy was introduced in CMake version 2.8.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0013
       Duplicate binary directories are not allowed.

       CMake 2.6.3 and below silently permitted add_subdirectory() calls to create  the  same  binary  directory
       multiple  times.  During build system generation files would be written and then overwritten in the build
       tree and could lead to strange behavior.  CMake  2.6.4  and  above  explicitly  detect  duplicate  binary
       directories.   CMake  2.6.4  always  considers  this case an error.  In CMake 2.8.0 and above this policy
       determines whether or not the case is an error.  The OLD behavior for this policy is to  allow  duplicate
       binary directories.  The NEW behavior for this policy is to disallow duplicate binary directories with an
       error.

       This policy was introduced in CMake version 2.8.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0012
       if() recognizes numbers and boolean constants.

       In CMake versions 2.6.4 and lower the if() command implicitly  dereferenced  arguments  corresponding  to
       variables,  even  those named like numbers or boolean constants, except for 0 and 1.  Numbers and boolean
       constants such as true, false, yes, no, on, off, y, n,  notfound,  ignore  (all  case  insensitive)  were
       recognized  in  some  cases  but  not all.  For example, the code if(TRUE) might have evaluated as false.
       Numbers such as 2 were recognized only in boolean expressions like if(NOT 2) (leading to false)  but  not
       as a single-argument like if(2) (also leading to false).  Later versions of CMake prefer to treat numbers
       and boolean constants literally, so they should not be used as variable names.

       The  OLD  behavior  for this policy is to implicitly dereference variables named like numbers and boolean
       constants.  The NEW behavior for this policy is  to  recognize  numbers  and  boolean  constants  without
       dereferencing variables with such names.

       This policy was introduced in CMake version 2.8.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

POLICIES INTRODUCED BY CMAKE 2.6

   CMP0011
       Included scripts do automatic cmake_policy() PUSH and POP.

       In CMake 2.6.2 and below, CMake Policy settings in scripts loaded by  the  include()  and  find_package()
       commands  would  affect  the  includer.  Explicit invocations of cmake_policy(PUSH) and cmake_policy(POP)
       were required to isolate policy changes and protect the includer.  While some scripts  intend  to  affect
       the  policies  of their includer, most do not.  In CMake 2.6.3 and above, include() and find_package() by
       default PUSH  and  POP  an  entry  on  the  policy  stack  around  an  included  script,  but  provide  a
       NO_POLICY_SCOPE option to disable it.  This policy determines whether or not to imply NO_POLICY_SCOPE for
       compatibility.   The  OLD  behavior  for  this  policy  is  to  imply  NO_POLICY_SCOPE  for include() and
       find_package() commands.  The NEW behavior for this policy is to allow the commands to do  their  default
       cmake_policy PUSH and POP.

       This policy was introduced in CMake version 2.6.3.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0010
       Bad variable reference syntax is an error.

       In CMake 2.6.2 and below, incorrect variable reference syntax such as a missing close-brace  (${FOO)  was
       reported  but  did  not  stop  processing  of  CMake code.  This policy determines whether a bad variable
       reference is an error.  The OLD behavior for this policy is to warn about the  error,  leave  the  string
       untouched, and continue.  The NEW behavior for this policy is to report an error.

       If CMP0053 is set to NEW, this policy has no effect and is treated as always being NEW.

       This policy was introduced in CMake version 2.6.3.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0009
       FILE GLOB_RECURSE calls should not follow symlinks by default.

       In CMake 2.6.1 and below, file(GLOB_RECURSE) calls would follow through  symlinks,  sometimes  coming  up
       with unexpectedly large result sets because of symlinks to top level directories that contain hundreds of
       thousands of files.

       This  policy  determines  whether or not to follow symlinks encountered during a file(GLOB_RECURSE) call.
       The OLD behavior for this policy is to follow the symlinks.  The NEW behavior for this policy is  not  to
       follow  the  symlinks  by  default, but only if FOLLOW_SYMLINKS is given as an additional argument to the
       FILE command.

       This policy was introduced in CMake version 2.6.2.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0008
       Libraries linked by full-path must have a valid library file name.

       In CMake 2.4 and below it is possible to write code like

          target_link_libraries(myexe /full/path/to/somelib)

       where  somelib  is  supposed  to  be  a valid library file name such as libsomelib.a or somelib.lib.  For
       Makefile generators this produces an error at build time because the dependency on the full  path  cannot
       be  found.   For  Visual Studio Generators IDE and Xcode generators this used to work by accident because
       CMake would always split off the library directory and ask the linker to search for the library  by  name
       (-lsomelib  or  somelib.lib).   Despite the failure with Makefiles, some projects have code like this and
       build only with Visual Studio and/or Xcode.  This version of CMake prefers to pass the full path directly
       to the native build tool, which will fail in this case because it does not name a valid library file.

       This policy determines what to do with full paths that do not appear to name a valid library  file.   The
       OLD  behavior for this policy is to split the library name from the path and ask the linker to search for
       it.  The NEW behavior for this policy is to trust the given path and pass it directly to the native build
       tool unchanged.

       This policy was introduced in CMake version 2.6.1.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0007
       list command no longer ignores empty elements.

       This  policy  determines  whether the list command will ignore empty elements in the list.  CMake 2.4 and
       below list commands ignored all empty elements in the list.  For example, a;b;;c would have length 3  and
       not  4.   The  OLD  behavior for this policy is to ignore empty list elements.  The NEW behavior for this
       policy is to correctly count empty elements in a list.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0006
       Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.

       This policy determines whether the install(TARGETS) command must be given a BUNDLE DESTINATION when asked
       to  install  a  target  with  the  MACOSX_BUNDLE  property  set.  CMake 2.4 and below did not distinguish
       application bundles from normal executables when installing targets.  CMake 2.6 provides a BUNDLE  option
       to  the  install(TARGETS)  command  that  specifies  rules  specific  to  application bundles on the Mac.
       Projects should use this option when installing a target with the MACOSX_BUNDLE property set.

       The OLD behavior for this policy is to fall back to the RUNTIME DESTINATION if a  BUNDLE  DESTINATION  is
       not  given.   The  NEW  behavior  for  this policy is to produce an error if a bundle target is installed
       without a BUNDLE DESTINATION.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0005
       Preprocessor definition values are now escaped automatically.

       This  policy determines whether or not CMake should generate escaped preprocessor definition values added
       via add_definitions.  CMake versions 2.4 and below assumed that only trivial values would  be  given  for
       macros in add_definitions calls.  It did not attempt to escape non-trivial values such as string literals
       in  generated  build  rules.   CMake  versions  2.6 and above support escaping of most values, but cannot
       assume the user has not added escapes already in  an  attempt  to  work  around  limitations  in  earlier
       versions.

       The  OLD  behavior for this policy is to place definition values given to add_definitions directly in the
       generated build rules without attempting to escape anything.  The NEW behavior  for  this  policy  is  to
       generate   correct  escapes  for  all  native  build  tools  automatically.   See  documentation  of  the
       COMPILE_DEFINITIONS target property for limitations of the escaping implementation.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0004
       Libraries linked may not have leading or trailing whitespace.

       CMake  versions 2.4 and below silently removed leading and trailing whitespace from libraries linked with
       code like

          target_link_libraries(myexe " A ")

       This could lead to subtle errors in user projects.

       The OLD behavior for this policy is to silently remove leading and trailing whitespace.  The NEW behavior
       for this policy is to diagnose the existence of such whitespace as an error.  The setting for this policy
       used when checking the library names is that in effect when the target is created by an  add_executable()
       or add_library() command.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0003
       Libraries linked via full path no longer produce linker search paths.

       This policy affects how libraries whose full paths are NOT known are found at link time, but was  created
       due to a change in how CMake deals with libraries whose full paths are known.  Consider the code

          target_link_libraries(myexe /path/to/libA.so)

       CMake  2.4 and below implemented linking to libraries whose full paths are known by splitting them on the
       link line into separate components consisting of the linker  search  path  and  the  library  name.   The
       example code might have produced something like

          ... -L/path/to -lA ...

       in  order  to  link to library A.  An analysis was performed to order multiple link directories such that
       the linker would find library A in the desired location, but there are cases in which this does not work.
       CMake versions 2.6 and above use the more reliable  approach  of  passing  the  full  path  to  libraries
       directly to the linker in most cases.  The example code now produces something like

          ... /path/to/libA.so ....

       Unfortunately this change can break code like

          target_link_libraries(myexe /path/to/libA.so B)

       where  B  is meant to find /path/to/libB.so.  This code is wrong because the user is asking the linker to
       find library B but has not provided a linker search path (which may be added  with  the  link_directories
       command).   However,  with  the  old  linking implementation the code would work accidentally because the
       linker search path added for library A allowed library B to be found.

       In order to support projects depending on linker search paths added by linking to  libraries  with  known
       full  paths,  the  OLD behavior for this policy will add the linker search paths even though they are not
       needed for their own libraries.  When this policy is set to OLD, CMake will produce a link line such as

          ... -L/path/to /path/to/libA.so -lB ...

       which will allow library B to be found as it was previously.  When this policy is set to NEW, CMake  will
       produce a link line such as

          ... /path/to/libA.so -lB ...

       which more accurately matches what the project specified.

       The  setting  for  this  policy  used  when generating the link line is that in effect when the target is
       created by an add_executable or add_library command.  For the example described above, the code

          cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4)
          add_executable(myexe myexe.c)
          target_link_libraries(myexe /path/to/libA.so B)

       will work and suppress the warning for this policy.  It may also be updated to work  with  the  corrected
       linking approach:

          cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6)
          link_directories(/path/to) # needed to find library B
          add_executable(myexe myexe.c)
          target_link_libraries(myexe /path/to/libA.so B)

       Even better, library B may be specified with a full path:

          add_executable(myexe myexe.c)
          target_link_libraries(myexe /path/to/libA.so /path/to/libB.so)

       When all items on the link line have known paths CMake does not check this policy so it has no effect.

       Note  that the warning for this policy will be issued for at most one target.  This avoids flooding users
       with messages for every target when setting the policy once will probably fix all targets.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0002
       Logical target names must be globally unique.

       Targets  names  created  with  add_executable(),  add_library(), or add_custom_target() are logical build
       target names.  Logical target names must be globally unique because:

          - Unique names may be referenced unambiguously both in CMake
            code and on make tool command lines.
          - Logical names are used by Xcode and VS IDE generators
            to produce meaningful project names for the targets.

       The logical name of executable and library targets does not have to correspond to the physical file names
       built.  Consider using the OUTPUT_NAME target property to create two targets with the same physical  name
       while  keeping logical names distinct.  Custom targets must simply have globally unique names (unless one
       uses the global property ALLOW_DUPLICATE_CUSTOM_TARGETS with a Makefiles generator).

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

   CMP0001
       CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.

       The  behavior  is to check CMAKE_BACKWARDS_COMPATIBILITY and present it to the user.  The NEW behavior is
       to ignore CMAKE_BACKWARDS_COMPATIBILITY completely.

       In CMake 2.4 and below the variable CMAKE_BACKWARDS_COMPATIBILITY was used to request compatibility  with
       earlier  versions  of CMake.  In CMake 2.6 and above all compatibility issues are handled by policies and
       the cmake_policy() command.  However, CMake must still check CMAKE_BACKWARDS_COMPATIBILITY  for  projects
       written for CMake 2.4 and below.

       This policy was introduced in CMake version 2.6.0.  CMake version 3.16.3 warns when the policy is not set
       and uses OLD behavior.  Use the cmake_policy() command to set it to OLD or NEW explicitly.

       NOTE:
          The  OLD  behavior  of  a policy is deprecated by definition and may be removed in a future version of
          CMake.

   CMP0000
       A minimum required CMake version must be specified.

       CMake requires that projects specify the version of CMake to which they have been written.   This  policy
       has  been  put  in  place so users trying to build the project may be told when they need to update their
       CMake.  Specifying a version also helps the project build with CMake versions newer than that  specified.
       Use the cmake_minimum_required() command at the top of your main CMakeLists.txt file:

          cmake_minimum_required(VERSION <major>.<minor>)

       where  <major>.<minor>  is  the  version  of  CMake you want to support (such as 3.14).  The command will
       ensure that at least the given version of CMake is running and help newer versions be compatible with the
       project.  See documentation of cmake_minimum_required() for details.

       Note that the command invocation must appear in the CMakeLists.txt file itself; a  call  in  an  included
       file  is not sufficient.  However, the  cmake_policy() command may be called to set policy CMP0000 to OLD
       or NEW behavior explicitly.  The OLD behavior is to silently ignore  the  missing  invocation.   The  NEW
       behavior  is  to  issue  an  error  instead of a warning.  An included file may set CMP0000 explicitly to
       affect how this policy is enforced for the main CMakeLists.txt file.

       This policy was introduced in CMake version 2.6.0.

       NOTE:
          The OLD behavior of a policy is deprecated by definition and may be removed in  a  future  version  of
          CMake.

COPYRIGHT

       2000-2022 Kitware, Inc. and Contributors

3.16.3                                         September 27, 2022                              CMAKE-POLICIES(7)