Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CMAKE-POLICIES(7)		     CMake		     CMAKE-POLICIES(7)

NAME
       cmake-policies -	CMake Policies Reference

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

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

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

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

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

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

       The  CMAKE_MINIMUM_REQUIRED_VERSION variable may	also be	used to	deter-
       mine whether to report an error on use of deprecated  macros  or	 func-
       tions.

POLICIES INTRODUCED BY CMAKE 3.21
   CMP0126
       New in version 3.21.

       When  this policy is set	to NEW,	the set(CACHE) command does not	remove
       any normal variable of the same name from the current scope.   The  OLD
       behavior	 removes any normal variable of	the same name from the current
       scope in	the following situations:

       o No cache variable of that name	existed	previously.

       o A cache variable of that name existed previously, but it had no type.
	 This  can occur when the variable was set on the command line using a
	 form like cmake -DMYVAR=blah instead of cmake -DMYVAR:STRING=blah.

       Note that the NEW behavior has an important difference to  the  similar
       NEW behavior of policy CMP0077.	The set(CACHE) command always sets the
       cache variable if it  did  not  exist  previously,  regardless  of  the
       CMP0126	policy	setting.   The option()	command	will not set the cache
       variable	if a non-cache variable	of the same name  already  exists  and
       CMP0077 is set to NEW.

       Policy CMP0126 was introduced in	CMake version 3.21. Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies, CMake version 3.21.3 does not warn	when the policy	is not set and
       simply uses OLD behavior.  See documentation of the  CMAKE_POLICY_WARN-
       ING_CMP0126 variable to control the warning.

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

   CMP0125
       New in version 3.21.

       The find_file(),	find_path(), find_library()  and  find_program()  com-
       mands cache their result	in the variable	specified by their first argu-
       ment.  Prior to CMake 3.21, if a	cache variable of  that	 name  already
       existed	before	the  call  but	the  cache  variable  had no type, any
       non-cache variable of the same name would be discarded  and  the	 cache
       variable	 was always used (see also CMP0126 for a different but similar
       behavior).  This	contradicts the	convention that	a  non-cache  variable
       should  take precedence over a cache variable of	the same name.	Such a
       situation can arise if a	user sets a cache variable on the command line
       without	specifying  a  type, such as cmake -DMYVAR=blah	... instead of
       cmake -DMYVAR:FILEPATH=blah.

       Related to the above, if	a cache	variable of the	specified name already
       exists  and  it does have a type, the various find_...()	commands would
       return that value unchanged.  In	particular, if it contained a relative
       path, it	would not be converted to an absolute path in this situation.

       When  policy  CMP0125 is	set to OLD or is unset,	the behavior is	as de-
       scribed above.  When it is set to NEW, the behavior is as follows:

       o If a non-cache	 variable  of  the  specified  name  exists  when  the
	 find_...()  command  is  called, its value will be used regardless of
	 whether a cache variable of the same name already exists or  not.   A
	 cache	variable  will	not  be	 created in this case if no such cache
	 variable existed before.  If a	cache variable of the  specified  name
	 did  already  exist, the cache	will be	updated	to match the non-cache
	 variable.

       o The various find...() commands	will always provide an	absolute  path
	 in  the  result  variable, except where a relative path provided by a
	 cache or non-cache variable cannot be resolved	to an existing path.

       This policy was introduced in CMake version 3.21.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.3 does not warn	when the policy	is not set and
       simply uses OLD behavior.

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

   CMP0124
       New in version 3.21.

       When this policy	is set to NEW, the scope of loop variables defined  by
       the foreach() command is	restricted to the loop only.  They will	be un-
       set at the end of the loop.

       The OLD behavior	for this policy	still clears the loop variables	at the
       end of the loop,	but does not unset them.  This leaves them as defined,
       but empty.

       This policy was introduced in CMake version 3.21.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.3 does not warn	when the policy	is not set and
       simply uses OLD behavior.

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

   CMP0123
       New in version 3.21.

       ARMClang	cpu/arch compile and link flags	must be	set explicitly.

       CMake 3.20 and  lower  automatically  maps  the	CMAKE_SYSTEM_PROCESSOR
       variable	 and an	undocumented CMAKE_SYSTEM_ARCH to compile and link op-
       tions for ARMClang.  For	example, the -mcpu=cortex-m33  flag  is	 added
       when CMAKE_SYSTEM_PROCESSOR equals cortex-m33.  CMake requires projects
       to set either variable or  it  raises  a	 fatal	error.	 However,  the
       project	may  need  to  additionally  specify  CPU  features using e.g.
       -mcpu=cortex-m33+nodsp, conflicting with	the -mcpu=cortex-m33 added  by
       CMake.  This results in either link errors or unusable binaries.

       CMake 3.21 and above prefer instead to not add any cpu/arch compile and
       link flags automatically.  Instead, projects must specify them  explic-
       itly.   This  policy  provides compatibility for	projects that have not
       been updated.

       The OLD behavior	of this	policy requires	projects that use ARMClang  to
       set either CMAKE_SYSTEM_PROCESSOR or CMAKE_SYSTEM_ARCH and it automati-
       cally adds a compile option -mcpu= or -march= and a link	option	--cpu=
       based  on  those	 variables.   The NEW behavior does not	add compile or
       link options, and projects are responsible for setting correct options.

       This policy was introduced in CMake version 3.21.  CMake	version	3.21.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.

   CMP0122
       New in version 3.21.

       UseSWIG use library name	conventions for	CSharp language.

       Starting	with CMake 3.21, UseSWIG generates now a library using default
       naming conventions. This	policy provides	 compatibility	with  projects
       that expect the legacy behavior.

       This policy was introduced in CMake version 3.21.  CMake	version	3.21.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.

   CMP0121
       New in version 3.21.

       The list() command now detects invalid indices.

       Prior to	CMake version 3.21, the	list() command's GET, INSERT, SUBLIST,
       and REMOVE_AT subcommands did not detect	invalid	index arguments.

       The OLD behavior	of this	policy is for invalid indices to be treated as
       their integer value (if any) at the start of the	string.	 For  example,
       2good4you is a 2	and not_an_integer is a	0. The NEW behavior is for in-
       valid indices to	trigger	an error.

       This policy was introduced in CMake version 3.21.  CMake	version	3.21.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.20
   CMP0120
       New in version 3.20.

       The WriteCompilerDetectionHeader	module is removed.

       CMake  versions	3.1 through 3.19 provide this module to	generate a C++
       compatibility layer by re-using information from	CMake's	table of  pre-
       processor checks	for cmake-compile-features(7).	However:

       o Those granular	features have been superseded by meta-features for Re-
	 quiring Language Standards such  as  cxx_std_11.   Therefore  no  new
	 granular  feature  checks will	be added and projects will need	to use
	 other means to	conditionally use new C++ features.

       o The module exposes some of CMake's implementation details directly to
	 C++ translation units.

       o The  module's approach	effectively provides a header file with	CMake,
	 thus tying the	version	of the header to the version of	 CMake.	  Many
	 projects found	that the WriteCompilerDetectionHeader was best used by
	 manually generating its header	locally	with a recent version of CMake
	 and then bundling it with the project source so that it could be used
	 with older CMake versions.

       For reasons including the above,	CMake 3.20 and	above  prefer  to  not
       provide	the WriteCompilerDetectionHeader module.  This policy provides
       compatibility for projects that have not	 been  ported  away  from  it.
       Projects	using the module should	be updated to stop using it.  Alterna-
       tives include:

       o Bundle	a copy of the generated	header in the project's	source.

       o Use a third-party alternative,	such as	the CC0-licensed Hedley.

       o Drop support for compilers too	old to provide the features natively.

       The OLD behavior	of this	policy is  for	inclusion  of  the  deprecated
       WriteCompilerDetectionHeader  module  to	work.  The NEW behavior	is for
       inclusion of the	module to fail as if it	does not exist.

       This policy was introduced in CMake version 3.20.  CMake	version	3.21.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.

   CMP0119
       New in version 3.20.

       LANGUAGE	 source	 file  property	 explicitly compiles as	specified lan-
       guage.

       The LANGUAGE source file	property is documented to mean that the	source
       file  is	 written  in the specified language.  In CMake 3.19 and	below,
       setting this property causes CMake to compile the source	file using the
       compiler	 for  the  specified language.	However, it only passes	an ex-
       plicit flag to tell the compiler	to treat the source as	the  specified
       language	 for MSVC-like,	XL, and	Embarcadero compilers for the CXX lan-
       guage.  CMake 3.20 and above prefer to also explicitly  tell  the  com-
       piler  to  use  the specified language using a flag such	as -x c	on all
       compilers for which such	flags are known.

       This policy provides compatibility for projects that have not been  up-
       dated to	expect this behavior.  For example, some projects were setting
       the LANGUAGE property to	C on assembly-language .S source files in  or-
       der  to compile them using the C	compiler.  Such	projects should	be up-
       dated to	use enable_language(ASM), for which CMake  will	 often	choose
       the C compiler as the assembler on relevant platforms anyway.

       The  OLD	 behavior  for this policy is to interpret the LANGUAGE	<LANG>
       property	using its undocumented meaning to "use the  <LANG>  compiler".
       The  NEW	 behavior  for this policy is to interpret the LANGUAGE	<LANG>
       property	using its documented meaning to	"compile as a <LANG> source".

       This policy was introduced in CMake version 3.20.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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.

   CMP0118
       New in version 3.20.

       The GENERATED source file property is now visible in all	directories.

       Whether or not a	source file is generated is an	all-or-nothing	global
       property	 of  the source.  Consequently,	the associated GENERATED prop-
       erty is now visible from	any directory scope, not only from  the	 scope
       for which it was	set.

       Additionally,  the  GENERATED  property	may now	be set only to boolean
       values, and may not be turned off once turned on.

       The OLD behavior	of this	policy is to only allow	GENERATED to be	 visi-
       ble from	the directory scope for	which it was set.  The NEW behavior on
       the other hand allows it	to be visible from any scope.

       This policy was introduced in CMake version 3.20.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.3 does not warn	when this policy  is  not  set
       and simply uses OLD behavior with regard	to visibility of the GENERATED
       property.  However, CMake does warn about setting the  GENERATED	 prop-
       erty to a non-boolean value.

   CMP0117
       New in version 3.20.

       MSVC RTTI flag /GR is not added to CMAKE_CXX_FLAGS by default.

       When  using  MSVC-like compilers	in CMake 3.19 and below, the RTTI flag
       /GR is added to CMAKE_CXX_FLAGS by default.  This behavior is left from
       support	for  MSVC  versions from Visual	Studio 2003 and	below that did
       not enable RTTI by default.  It is no longer  necessary.	  Furthermore,
       it is problematic for projects that want	to change to /GR- programmati-
       cally.	In   particular,   it	requires   string   editing   of   the
       CMAKE_CXX_FLAGS variable	with knowledge of the CMake builtin default so
       it can be replaced.

       CMake 3.20 and above  prefer  to	 leave	out  /GR  from	the  value  of
       CMAKE_CXX_FLAGS by default.

       This policy provides compatibility with projects	that have not been up-
       dated to	expect the lack	of the /GR flag.  The policy setting takes ef-
       fect  as	 of the	first project()	or enable_language() command that ini-
       tializes	CMAKE_CXX_FLAGS.

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

       The  OLD	 behavior for this policy is to	place the MSVC /GR flag	in the
       default CMAKE_CXX_FLAGS cache entry.  The NEW behavior for this	policy
       is to not place the MSVC	/GR flag in the	default	cache entry.

       This  policy  was introduced in CMake version 3.20.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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.

   CMP0116
       New in version 3.20.

       Ninja generators	transform DEPFILE s from add_custom_command().

       In  CMake  3.19	and  below,  files  given  to  the DEPFILE argument of
       add_custom_command() were passed	directly to Ninja's  depfile  variable
       without	any  path  resolution. This meant that if add_custom_command()
       was called from a subdirectory  (created	 by  add_subdirectory()),  the
       DEPFILE	argument  would	 have  to be either an absolute	path or	a path
       relative	to CMAKE_BINARY_DIR, rather than CMAKE_CURRENT_BINARY_DIR.  In
       addition,  no  transformation  was  done	on the file listed in DEPFILE,
       which meant that	the paths within the DEPFILE  had  the	same  restric-
       tions.

       Starting	  with	CMake  3.20,  the  DEPFILE  argument  is  relative  to
       CMAKE_CURRENT_BINARY_DIR	(unless	it is absolute), and the paths in  the
       DEPFILE are also	relative to CMAKE_CURRENT_BINARY_DIR.  CMake automati-
       cally transforms	the paths in the DEPFILE (unless  they	are  absolute)
       after the custom	command	is run.	The file listed	in DEPFILE is not mod-
       ified in	any way. Instead, CMake	writes the transformation to  its  own
       internal	 file,	and passes this	internal file to Ninja's depfile vari-
       able.  This transformation happens regardless of	whether	or not DEPFILE
       is  relative,  and regardless of	whether	or not add_custom_command() is
       called from a subdirectory.

       The OLD behavior	for this policy	is to pass the DEPFILE to Ninja	 unal-
       tered. The NEW behavior for this	policy is to transform the DEPFILE af-
       ter running the custom command. The status of CMP0116  is  recorded  at
       the time	of the custom command's	creation, and you can have custom com-
       mands in	the same directory with	different values for CMP0116  by  set-
       ting the	policy before each custom command.

       This  policy  was  introduced in	CMake version 3.20.  Unlike most poli-
       cies, CMake version 3.21.3 does not warn	by default when	this policy is
       not  set	(unless	DEPFILE	is used	in a subdirectory) and simply uses OLD
       behavior.  See documentation of the CMAKE_POLICY_WARNING_CMP0116	 vari-
       able to control the warning.

   CMP0115
       New in version 3.20.

       Source file extensions must be explicit.

       In  CMake  3.19	and  below, if a source	file could not be found	by the
       name specified, it would	append a list of known extensions to the  name
       to see if the file with the extension could be found. For example, this
       would allow the user to run:

	  add_executable(exe main)

       and put main.c in the executable	without	specifying the extension.

       Starting	in CMake 3.20, CMake prefers all source	files  to  have	 their
       extensions explicitly listed:

	  add_executable(exe main.c)

       The  OLD	 behavior for this policy is to	implicitly append known	exten-
       sions to	source files if	they can't be found. The NEW behavior of  this
       policy  is  to  not  append known extensions and	require	them to	be ex-
       plicit.

       This policy was introduced in CMake version 3.20.  CMake	version	3.21.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.19
   CMP0114
       New in version 3.19.

       ExternalProject step targets fully adopt	their steps.

       The  ExternalProject_Add()  STEP_TARGETS	 option,  and the ExternalPro-
       ject_Add_StepTargets() function,	can be used to	create	build  targets
       for individual steps of an external project.

       In CMake	3.18 and below,	step targets have some limitations:

       o Step  targets	always	depend	on  targets  named by the ExternalPro-
	 ject_Add() DEPENDS option even	though not all steps  need  them.   In
	 order to allow	step targets to	be created without those dependencies,
	 the ExternalProject_Add() INDEPENDENT_STEP_TARGETS option or the  Ex-
	 ternalProject_Add_StepTargets()  NO_DEPENDS option may	be used.  How-
	 ever, adding such "independent" step targets  makes  sense  only  for
	 specific  steps  such	as download, update, and patch because they do
	 not need any of the external project's	build dependencies.   Further-
	 more,	it  does not make sense	to create independent step targets for
	 steps that depend on non-independent steps.  Such rules are  not  en-
	 forced,  and projects that do not follow them can generate build sys-
	 tems with confusing and generator-specific behavior.

       o Step targets hold copies of the custom	 commands  implementing	 their
	 steps that are	separate from the copies in the	primary	target created
	 by ExternalProject_Add(), and the primary target does not  depend  on
	 the  step  targets.  In parallel builds that drive the	primary	target
	 and step targets concurrently,	multiple copies	of the steps' commands
	 may run concurrently and race each other.

	 Also, prior to	policy CMP0113,	the step targets generated by Makefile
	 Generators also contain all the custom	commands on which  their  step
	 depends.   This can lead to repeated execution	of those steps even in
	 serial	builds.

       In CMake	3.19 and above,	the ExternalProject module prefers  a  revised
       design to address these problems:

       o Each  step  is	 classified  as	"independent" if it does not depend on
	 other targets named by	the ExternalProject_Add() DEPENDS.  The	prede-
	 fined steps are automatically classified by default:

	 o The download, update, and patch steps are independent.

	 o The configure, build, test, and install steps are not.

	 For  custom steps, the	ExternalProject_Add_Step() command provides an
	 INDEPENDENT option to mark them as independent.  It is	 an  error  to
	 mark a	step as	independent if it depends on other steps that are not.
	 Note that this	use of the term	"independent" refers only to  indepen-
	 dence	from  external targets and is orthogonal to a step's dependen-
	 cies on other steps.

       o Step targets created by the ExternalProject_Add() STEP_TARGETS	option
	 or the	ExternalProject_Add_Step() function are	now independent	if and
	 only if their steps are  marked  as  independent.   The  ExternalPro-
	 ject_Add()    INDEPENDENT_STEP_TARGETS	   option   and	  ExternalPro-
	 ject_Add_StepTargets()	NO_DEPENDS option are no longer	allowed.

       o Step targets, when created, are fully	responsible  for  holding  the
	 custom	commands implementing their steps.  The	primary	target created
	 by ExternalProject_Add() depends on the step targets,	and  the  step
	 targets  depend  on  each other.  The target-level dependencies match
	 the file-level	dependencies used by  the  custom  commands  for  each
	 step.

	 When	the   ExternalProject_Add()  UPDATE_DISCONNECTED  or  TEST_EX-
	 CLUDE_FROM_MAIN option	is used, or the	ExternalProject_Add_Step() EX-
	 CLUDE_FROM_MAIN  option  is used for a	custom step, some step targets
	 may be	created	automatically.	These are needed  to  hold  the	 steps
	 commonly  depended  upon  by  the primary target and the disconnected
	 step targets.

       Policy CMP0114 provides compatibility for projects that have  not  been
       updated	to  expect the new behavior.  The OLD behavior for this	policy
       is to use the above-documented behavior from 3.18 and below.   The  NEW
       behavior	 for  this policy is to	use the	above-documented behavior pre-
       ferred by 3.19 and above.

       This policy was introduced in CMake version 3.19.  CMake	version	3.21.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.

   CMP0113
       New in version 3.19.

       Makefile	Generators do not repeat custom	commands from target dependen-
       cies.

       Consider	a chain	of custom commands split across	two dependent targets:

	  add_custom_command(OUTPUT output-not-created
	    COMMAND ...	DEPENDS	...)
	  set_property(SOURCE output-not-created PROPERTY SYMBOLIC 1)
	  add_custom_command(OUTPUT output-created
	    COMMAND ...	DEPENDS	${CMAKE_CURRENT_BINARY_DIR}/output-not-created)
	  add_custom_target(first DEPENDS output-not-created)
	  add_custom_target(second DEPENDS output-created)
	  add_dependencies(second first)

       In  CMake  3.18	and  lower, the	Makefile generators put	a copy of both
       custom commands in the Makefile for target second even though  its  de-
       pendency	on target first	ensures	that the first custom command runs be-
       fore the	second.	 Running make second would cause the first custom com-
       mand  to	run once in the	first target and then again in the second tar-
       get.

       CMake 3.19 and above prefer to not duplicate custom commands in a  tar-
       get that	are already generated in other targets on which	the target de-
       pends (directly or indirectly).	This policy provides compatibility for
       projects	 that  have  not  been updated to expect the new behavior.  In
       particular, projects that relied	on the duplicate execution or that did
       not properly set	the SYMBOLIC source file property may be affected.

       The OLD behavior	for this policy	is to duplicate	custom commands	in de-
       pendent targets.	 The NEW behavior of this policy is to	not  duplicate
       custom commands in dependent targets.

       This  policy  was  introduced in	CMake version 3.19.  Unlike many poli-
       cies, CMake version 3.21.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.

   CMP0112
       New in version 3.19.

       Target file component generator expressions do not add target dependen-
       cies.

       The  following target-based generator expressions that query for	direc-
       tory or file name components no longer add a dependency on  the	evalu-
       ated target.

	  o TARGET_FILE_NAME

	  o TARGET_FILE_DIR

	  o TARGET_LINKER_FILE_BASE_NAME

	  o TARGET_LINKER_FILE_NAME

	  o TARGET_LINKER_FILE_DIR

	  o TARGET_SONAME_FILE_NAME

	  o TARGET_SONAME_FILE_DIR

	  o TARGET_PDB_FILE_NAME

	  o TARGET_PDB_FILE_DIR

	  o TARGET_BUNDLE_DIR

	  o TARGET_BUNDLE_CONTENT_DIR

       In  CMake  3.18	and  lower a dependency	on the evaluated target	of the
       above generator expressions would always	 be  added.   CMake  3.19  and
       above prefer to not add this dependency.	 This policy provides compati-
       bility for projects that	have not been updated to expect	the new	behav-
       ior.

       The  OLD	 behavior for this policy is to	add a dependency on the	evalu-
       ated target for the above generator expressions.	 The NEW  behavior  of
       this  policy is to not add a dependency on the evaluated	target for the
       above generator expressions.

       This policy was introduced in CMake version 3.19.   Unlike  many	 poli-
       cies, CMake version 3.21.3 does not warn	by default when	this policy is
       not set and  simply  uses  OLD  behavior.   See	documentation  of  the
       CMAKE_POLICY_WARNING_CMP0112 variable to	control	the warning.

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

   CMP0111
       New in version 3.19.

       An imported target missing its location property	fails  during  genera-
       tion.

       Imported	 Targets  for library files and	executables require that their
       location	on disk	is specified in	a target property such as IMPORTED_LO-
       CATION,	IMPORTED_IMPLIB,  or  a	 per-configuration  equivalent.	  If a
       needed location property	is not set, CMake 3.18 and below generate  the
       string  <TARGET_NAME>-NOTFOUND  in its place, which results in failures
       of the corresponding rules at build time.  CMake	3.19 and above	prefer
       instead to raise	an error during	generation.  This policy provides com-
       patibility for projects that have not been updated to  expect  the  new
       behavior.

       The  OLD	 behavior of this policy is to generate	the location of	an im-
       ported unknown, static or shared	library	target	as  <TARGET_NAME>-NOT-
       FOUND if	not set.  The NEW behavior is to raise an error.

       This policy was introduced in CMake version 3.19.  CMake	version	3.21.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.

   CMP0110
       New in version 3.19.

       add_test() supports arbitrary characters	in test	names.

       add_test() can now (officially) create tests with whitespace and	 other
       special characters in its name.	Before CMake version 3.19 that was not
       allowed,	however, it was	possible to work around	this limitation	by ex-
       plicitly	 putting escaped quotes	around the test's name in the add_test
       command.

       Although	never officially supported several projects in the wild	 found
       and  implemented	 this workaround.  However, the	new change which offi-
       cially allows the add_test command to support whitespace	and other spe-
       cial characters in test names now breaks	that workaround.  In order for
       these projects to work smoothly with newer CMake	versions, this	policy
       was introduced.

       The  OLD	behavior of this policy	is to still prevent add_test from han-
       dling whitespace	and special characters properly	(if not	using the men-
       tioned  workaround).   The  NEW behavior	on the other hand allows names
       with whitespace and special characters for tests	created	by add_test.

       This policy was introduced in CMake version 3.19.  CMake	version	3.21.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.

   CMP0109
       New in version 3.19.

       find_program() requires permission to execute but not to	read.

       In CMake	3.18 and below,	the find_program() command on UNIX would  find
       files that are readable without requiring execute permission, and would
       not find	files that are executable without read permission.   In	 CMake
       3.19  and above,	find_program now prefers to require execute permission
       but not read  permission.   This	 policy	 provides  compatibility  with
       projects	that have not been updated to expect the new behavior.

       The  OLD	 behavior  for this policy is for find_program to require read
       permission but not execute permission.  The NEW behavior	for this  pol-
       icy is for find_program to require execute permission but not read per-
       mission.

       This policy was introduced in CMake version 3.19.  CMake	version	3.21.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.18
   CMP0108
       New in version 3.18.

       A target	is not allowed to link to itself even through an ALIAS target.

       In  CMake  3.17 and below, a target can link to a target	aliased	to it-
       self.

       The OLD behavior	for this policy	is to allow a target to	link to	a tar-
       get aliased to itself.

       The  NEW	 behavior of this policy is to prevent a target	to link	to it-
       self through an ALIAS target.

       This policy was introduced in CMake version 3.17.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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.

   CMP0107
       New in version 3.18.

       It is not allowed to create an ALIAS target with	the same  name	as  an
       another target.

       In  CMake 3.17 and below, an ALIAS target can overwrite silently	an ex-
       isting target with the same name.

       The OLD behavior	for this policy	is to allow target overwrite.

       The NEW behavior	of this	policy is to prevent target overwriting.

       This policy was introduced in CMake version 3.17.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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.

   CMP0106
       New in version 3.18.

       The Documentation module	is removed.

       The Documentation was added as a	support	mechanism for the VTK  project
       and  was	tuned for that project.	Instead	of CMake providing this	module
       with (now old) VTK patterns for cache variables and required  packages,
       the module is now deprecated by CMake itself.

       The OLD behavior	of this	policy is for Documentation to add cache vari-
       ables and find VTK documentation	dependent packages. The	 NEW  behavior
       is to act as an empty module.

       This policy was introduced in CMake version 3.18.  CMake	version	3.21.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.

   CMP0105
       New in version 3.18.

       LINK_OPTIONS and	INTERFACE_LINK_OPTIONS target properties are now  used
       for the device link step.

       In  CMake  3.17 and below, link options are not used by the device link
       step.

       The OLD behavior	for this policy	is to ignore the link options.

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

       This  policy  was introduced in CMake version 3.17.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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.

   CMP0104
       New in version 3.18.

       Initialize   CMAKE_CUDA_ARCHITECTURES  when  CMAKE_CUDA_COMPILER_ID  is
       NVIDIA.	Raise an error if CUDA_ARCHITECTURES is	empty.

       CMAKE_CUDA_ARCHITECTURES	introduced in CMake 3.18 is used to initialize
       CUDA_ARCHITECTURES,  which  passes correct code generation flags	to the
       CUDA compiler.

       Previous	to this	users had to  manually	specify	 the  code  generation
       flags.  This policy is for backwards compatibility with manually	speci-
       fying code generation flags.

       The OLD behavior	for this policy	is to not initialize CMAKE_CUDA_ARCHI-
       TECTURES	 when  CMAKE_CUDA_COMPILER_ID is NVIDIA.  Empty	CUDA_ARCHITEC-
       TURES is	allowed.

       The NEW behavior	of this	policy is to  initialize  CMAKE_CUDA_ARCHITEC-
       TURES  when  CMAKE_CUDA_COMPILER_ID  is	NVIDIA	and  raise an error if
       CUDA_ARCHITECTURES is empty during generation.

       If CUDA_ARCHITECTURES is	set to a false value  no  architectures	 flags
       are  passed  to the compiler. This is intended to support packagers and
       the rare	cases where full control over the passed flags is required.

       This policy was introduced in CMake version 3.18.  CMake	version	3.21.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
	  set_target_properties(tgt PROPERTIES CUDA_ARCHITECTURES "35;50;72")

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

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

       Generates code for real architecture 70 and virtual architecture	72.

	  set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)

       CMake will not pass any architecture flags to the compiler.

   CMP0103
       New in version 3.18.

       Multiple	 calls to export() command with	same FILE without APPEND is no
       longer allowed.

       In CMake	3.17 and below,	multiple calls to export()  command  with  the
       same FILE without APPEND	are accepted silently but only the last	occur-
       rence is	taken into account during the generation.

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

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

       This policy was introduced in CMake version 3.18.  CMake	version	3.21.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.17
   CMP0102
       New in version 3.17.

       The  mark_as_advanced()	command	no longer creates a cache entry	if one
       does not	already	exist.

       In CMake	3.16 and below,	if a variable was not defined at all  or  just
       defined	locally,  the  mark_as_advanced()  command  would create a new
       cache entry with	an UNINITIALIZED type and no value. When a find_path()
       (or other similar find_ command)	would next run,	it would find this un-
       defined cache entry and set it up with  an  empty  string  value.  This
       process would end up deleting the local variable	in the process (due to
       the way the cache works), effectively clearing any stored find_ results
       that were only available	in the local scope.

       The  OLD	 behavior for this policy is to	create the empty cache defini-
       tion.  The NEW behavior of this policy is to ignore variables which  do
       not already exist in the	cache.

       This  policy  was introduced in CMake version 3.17.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.3 does not warn when	this policy is not set
       and simply uses OLD behavior.   See  documentation  of  the  CMAKE_POL-
       ICY_WARNING_CMP0102 variable to control the warning.

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

   CMP0101
       New in version 3.17.

       target_compile_options()	now honors BEFORE keyword in all scopes.

       In CMake	3.16 and below the target_compile_options() ignores the	BEFORE
       keyword in private scope. CMake 3.17 and	later honors BEFORE keyword in
       all scopes. This	policy provides	compatibility for projects  that  have
       not been	updated	to expect the new behavior.

       The OLD behavior	for this policy	is to not honor	BEFORE keyword in pri-
       vate scope. The NEW behavior of this policy is to honor BEFORE  keyword
       in all scopes.

       This  policy  was introduced in CMake version 3.17.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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.

   CMP0100
       New in version 3.17.

       Let AUTOMOC and AUTOUIC process header files that end with a .hh	exten-
       sion.

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

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

       The OLD behavior	for this policy	is to ignore .hh header	files in AUTO-
       MOC and AUTOUIC.

       The NEW behavior	for this policy	is to process .hh header files in  AU-
       TOMOC and AUTOUIC just like other header	files.

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

	      #	Source skip example:
	      set_property(SOURCE /path/to/file1.hh PROPERTY SKIP_AUTOMOC ON)
	      set_property(SOURCE /path/to/file2.hh PROPERTY SKIP_AUTOUIC ON)
	      set_property(SOURCE /path/to/file3.hh PROPERTY SKIP_AUTOGEN ON)

       This  policy  was  introduced  in  CMake	version	3.17.0.	 CMake version
       3.21.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.

   CMP0099
       New in version 3.17.

       Target link properties INTERFACE_LINK_OPTIONS,  INTERFACE_LINK_DIRECTO-
       RIES  and INTERFACE_LINK_DEPENDS	are now	transitive over	private	depen-
       dencies of static libraries.

       In CMake	3.16 and below the interface link properties attached  to  li-
       braries	are  not  propagated  for  private  dependencies of static li-
       braries.	 Only the libraries themselves are propagated to link the  de-
       pendent binary.	CMake 3.17 and later prefer to propagate all interface
       link properties.	 This policy provides compatibility for	projects  that
       have not	been updated to	expect the new behavior.

       The  OLD	 behavior  for	this policy is to not propagate	interface link
       properties. The NEW behavior of this policy is to  propagate  interface
       link properties.

       This  policy  was introduced in CMake version 3.17.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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.

   CMP0098
       New in version 3.17.

       FindFLEX	 runs  flex in directory CMAKE_CURRENT_BINARY_DIR when execut-
       ing.

       The module provides a FLEX_TARGET macro which  generates	 FLEX  output.
       In  CMake 3.16 and below	the macro would	generate a custom command that
       runs flex in the	current	source directory.  CMake 3.17 and later	prefer
       to  run	it  in the build directory and use CMAKE_CURRENT_BINARY_DIR as
       the WORKING_DIRECTORY of	its add_custom_command() invocation.  This en-
       sures  that  any	 implicitly  generated file is written relative	to the
       build tree rather than the source tree, unless the  generated  file  is
       provided	as absolute path.

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

       The OLD behavior	for this policy	is for FLEX_TARGET to use the  current
       source  directory  for  the WORKING_DIRECTORY and where to generate im-
       plicit files. The NEW behavior of this policy is	to use the current bi-
       nary  directory	for  the  WORKING_DIRECTORY relative to	which implicit
       files are generated unless provided as absolute path.

       This policy was introduced in CMake version 3.17.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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.16
   CMP0097
       New in version 3.16.

       ExternalProject_Add() with GIT_SUBMODULES "" initializes	no submodules.

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

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

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

       This  policy  was introduced in CMake version 3.16.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  most	 poli-
       cies,  CMake  version  3.21.3 does not warn when	this policy is not set
       and simply uses OLD behavior.

   CMP0096
       New in version 3.16.

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

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

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

       This policy was introduced in CMake version 3.16.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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
       New in version 3.16.

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

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

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

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

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

POLICIES INTRODUCED BY CMAKE 3.15
   CMP0094
       New in version 3.15.

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

       Starting	 with  CMake  3.15, Modules FindPython3, FindPython2 and Find-
       Python	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_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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
       New in version 3.15.

       FindBoost reports Boost_VERSION in x.y.z	format.

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

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

       This policy was introduced in CMake version 3.15.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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
       New in version 3.15.

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

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

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

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

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

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

       This policy was introduced in CMake version 3.15.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike many poli-
       cies, CMake version 3.21.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
       New in version 3.15.

       MSVC runtime library flags are selected by an abstraction.

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

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

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

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

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

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

       This  policy  was introduced in CMake version 3.15.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  many	 poli-
       cies,  CMake  version  3.21.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
       New in version 3.15.

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

       In  CMake 3.14 and below	the export(PACKAGE) command populated the user
       package registry	by default and	users  needed  to  set	the  CMAKE_EX-
       PORT_NO_PACKAGE_REGISTRY	 to  disable  it,  e.g.	in automated build and
       packaging environments.	Since the user package registry	is stored out-
       side 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 en-
       able it.	 This policy provides compatibility with  projects  that  have
       not been	updated.

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

       This policy was introduced in CMake version 3.15.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike most poli-
       cies, CMake version 3.21.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
       New in version 3.15.

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

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

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

       This  policy  was introduced in CMake version 3.15.  Use	the cmake_pol-
       icy() command to	set this policy	to OLD or NEW explicitly.  Unlike most
       policies,  CMake	version	3.21.3 does not	warn by	default	when this pol-
       icy 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
       New in version 3.14.

       FindBISON runs bison in CMAKE_CURRENT_BINARY_DIR	when executing.

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

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

       The OLD behavior	for this policy	is for BISON_TARGET to use the current
       source directory	for the	WORKING_DIRECTORY and where  to	 generate  im-
       plicit files. The NEW behavior of this policy is	to use the current bi-
       nary directory for the WORKING_DIRECTORY	and where to generate implicit
       files.

       This  policy  was introduced in CMake version 3.14.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  most	 poli-
       cies,  CMake  version  3.21.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
       New in version 3.14.

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

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

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

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

       This policy was introduced in CMake version 3.14.  CMake	version	3.21.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
       New in version 3.14.

       UseSWIG honors SWIG_MODULE_NAME via -module flag.

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

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

       This policy was introduced in CMake version 3.14.  CMake	version	3.21.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
       New in version 3.14.

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

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

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

       This policy was introduced in CMake version 3.14.  CMake	version	3.21.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
       New in version 3.14.

       The FindQt module does not exist	for find_package().

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

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

       The OLD behavior	of this	policy is for FindQt to	exist  for  find_pack-
       age().  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.21.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
       New in version 3.14.

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

       CMake 3.13 and lower did	not add	these link flags  when	POSITION_INDE-
       PENDENT_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:

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

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

       o 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	Check-
       PIESupported module to check for	 support  to  ensure  that  the	 POSI-
       TION_INDEPENDENT_CODE  target  property for executables will be honored
       at link time.

       This policy was introduced in CMake version 3.14.  Use  the  cmake_pol-
       icy()  command  to  set it to OLD or NEW	explicitly.  Unlike most poli-
       cies, CMake version 3.21.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
       New in version 3.14.

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

       CMake  3.13 and lower ran the install rules from	add_subdirectory() af-
       ter all other install rules, even if add_subdirectory() was called  be-
       fore  the  other	 install rules.	 CMake 3.14 and	above prefer to	inter-
       leave these add_subdirectory() install rules with the  others  so  that
       they are	run in the order they are declared.  This policy provides com-
       patibility for projects that have not been updated to  expect  the  new
       behavior.

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

       This  policy  was  introduced in	CMake version 3.14.  Unlike most poli-
       cies, CMake version 3.21.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
       New in version 3.13.

       Relative	paths not allowed in LINK_DIRECTORIES target property.

       CMake 3.12 and lower allowed the	LINK_DIRECTORIES directory property to
       contain relative	paths.	The base path for such relative	entries	is not
       well  defined.	CMake  3.13  and later will issue a FATAL_ERROR	if the
       LINK_DIRECTORIES	target property	(which is initialized by the  LINK_DI-
       RECTORIES 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.21.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
       New in version 3.13.

       BundleUtilities cannot be included at configure time.

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

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

       The OLD behavior	of this	policy is to allow BundleUtilities to  be  in-
       cluded  at configure time. The NEW behavior of this policy is to	disal-
       low such	inclusion.

       This policy was introduced in CMake version 3.13.  CMake	version	3.21.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
       New in version 3.13.

       target_link_libraries() allows use with targets in other	directories.

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

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

       This policy provides compatibility with projects	that already use  tar-
       get_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.21.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
       New in version 3.13.

       UseSWIG generates standard target names.

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

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

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

       o STANDARD: target name matches specified name.

       This policy was introduced in CMake version 3.13.  CMake	version	3.21.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
       New in version 3.13.

       option()	honors normal variables.

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

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

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

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

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

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

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

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

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

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

       This policy was introduced in CMake version 3.13.  CMake	version	3.21.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
       New in version 3.13.

       The target_sources() command converts relative paths to absolute.

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

       o Source	files are added	to the target's	INTERFACE_SOURCES property.

       o The	target's   SOURCE_DIR	property   differs   from   CMAKE_CUR-
	 RENT_SOURCE_DIR.

       A path that begins with a generator expression is always	 left  unmodi-
       fied.

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

       This policy was introduced in CMake version 3.13.  CMake	version	3.21.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
       New in version 3.12.

       Include file check macros honor CMAKE_REQUIRED_LIBRARIES.

       In CMake	3.12 and above,	the

       o check_include_file macro in the CheckIncludeFile module, the

       o check_include_file_cxx	macro in the CheckIncludeFileCXX  module,  and
	 the

       o 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.21.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
       New in version 3.12.

       find_package() uses <PackageName>_ROOT variables.

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

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

       This policy was introduced in CMake version 3.12.  CMake	version	3.21.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
       New in version 3.12.

       Do not produce legacy _LIB_DEPENDS cache	entries.

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

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

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

       This  policy  was introduced in CMake version 3.12.  Use	the cmake_pol-
       icy() command to	set it to OLD or NEW explicitly.   Unlike  most	 poli-
       cies,  CMake  version  3.21.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
       New in version 3.11.

       FindOpenGL prefers GLVND	by default when	available.

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

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

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

       This policy was introduced in CMake version 3.11.  CMake	version	3.21.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
       New in version 3.10.

       Let AUTOMOC and AUTOUIC process GENERATED files.

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

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

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

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

       NOTE:
	  To silence the CMP0071 warning source	files can be excluded from AU-
	  TOMOC	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.21.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
       New in version 3.10.

       Define file(GENERATE) behavior for relative paths.

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

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

       This policy was introduced in CMake version 3.10.  CMake	version	3.21.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
       New in version 3.9.

       INTERPROCEDURAL_OPTIMIZATION is enforced	when enabled.

       CMake  3.9 and newer prefer to add IPO flags whenever the INTERPROCEDU-
       RAL_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 CheckIPOSup-
       ported module to	check for support before  enabling  the	 INTERPROCEDU-
       RAL_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 environ-
       ment known to support IPO even if the project does not enable the prop-
       erty.

       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.21.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.	  Pro-
       duce  an	 error	if  CMake does not know	IPO flags for the current com-
       piler:

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

	  # ...

	  set_property(TARGET ... PROPERTY INTERPROCEDURAL_OPTIMIZATION	TRUE)

   CMP0068
       New in version 3.9.

       RPATH settings on macOS do not affect install_name.

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

       o BUILD_WITH_INSTALL_RPATH target property

       o SKIP_BUILD_RPATH target property

       o CMAKE_SKIP_RPATH variable

       o CMAKE_SKIP_INSTALL_RPATH variable

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

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

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

       This  policy was	introduced in CMake version 3.9.  CMake	version	3.21.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
       New in version 3.8.

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

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

       o CMAKE_C_STANDARD

       o CMAKE_C_STANDARD_REQUIRED

       o CMAKE_C_EXTENSIONS

       o CMAKE_CXX_STANDARD

       o CMAKE_CXX_STANDARD_REQUIRED

       o CMAKE_CXX_EXTENSIONS

       o CMAKE_CUDA_STANDARD

       o CMAKE_CUDA_STANDARD_REQUIRED

       o CMAKE_CUDA_EXTENSIONS

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

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

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

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

POLICIES INTRODUCED BY CMAKE 3.7
   CMP0066
       New in version 3.7.

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

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

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

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

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

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

POLICIES INTRODUCED BY CMAKE 3.4
   CMP0065
       New in version 3.4.

       Do not add flags	to export symbols from	executables  without  the  EN-
       ABLE_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  EN-
       ABLE_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.21.3 does not warn by default when this policy  is  not
       set  and	simply uses OLD	behavior.  See documentation of	the CMAKE_POL-
       ICY_WARNING_CMP0065 variable to control the warning.

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

   CMP0064
       New in version 3.4.

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

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

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

       This  policy was	introduced in CMake version 3.4.  CMake	version	3.21.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
       New in version 3.3.

       Honor visibility	properties for all target types.

       The <LANG>_VISIBILITY_PRESET and	VISIBILITY_INLINES_HIDDEN target prop-
       erties affect visibility	of symbols during dynamic linking.  When first
       introduced these	properties affected compilation	 of  sources  only  in
       shared libraries, module	libraries, and executables with	the ENABLE_EX-
       PORTS 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 ex-
       ports.  The NEW behavior	for this policy	is  to	honor  the  visibility
       properties for all target types.

       This  policy was	introduced in CMake version 3.3.  CMake	version	3.21.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
       New in version 3.3.

       Disallow	install() of export() result.

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

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

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

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

       This  policy was	introduced in CMake version 3.3.  CMake	version	3.21.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
       New in version 3.3.

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

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

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

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

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

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

   CMP0060
       New in version 3.3.

       Link libraries by full path even	in implicit directories.

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

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

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

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

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

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

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

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

   CMP0059
       New in version 3.3.

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

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

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

       This  policy was	introduced in CMake version 3.3.  CMake	version	3.21.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
       New in version 3.3.

       Ninja requires custom command byproducts	to be explicit.

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

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

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

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

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

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

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

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

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

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

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

       This  policy was	introduced in CMake version 3.3.  CMake	version	3.21.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_pol-
       icy() command to	set the	policy to OLD or NEW explicitly.   The	policy
       setting	must  be  in  scope at the end of the top-level	CMakeLists.txt
       file of the project and has global effect.

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

   CMP0057
       New in version 3.3.

       Support new if()	IN_LIST	operator.

       CMake 3.3 adds support for the new IN_LIST operator.

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

       This policy was introduced in CMake version 3.3.	 CMake version	3.21.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
       New in version 3.2.

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

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

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

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

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

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

   CMP0055
       New in version 3.2.

       Strict checking for the break() command.

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

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

       This  policy was	introduced in CMake version 3.2.  CMake	version	3.21.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
       New in version 3.1.

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

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

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

       Given the following partial example:

	  set(A	E)
	  set(E	"")

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

       After explicit expansion	of variables this gives:

	  if("E" STREQUAL "")

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

	  if(""	STREQUAL "")

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

	  if("E" STREQUAL "")

       This  policy was	introduced in CMake version 3.1.  CMake	version	3.21.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
       New in version 3.1.

       Simplify	variable reference and escape sequence evaluation.

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

       o Expansion of @VAR@ reference syntax defined by	 the  configure_file()
	 and  string(CONFIGURE)	 commands is no	longer performed in other con-
	 texts.

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

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

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

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

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

       This  policy was	introduced in CMake version 3.1.  CMake	version	3.21.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
       New in version 3.1.

       Reject source and build dirs  in	 installed  INTERFACE_INCLUDE_DIRECTO-
       RIES.

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

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

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

       This policy was introduced in CMake version 3.1.	 CMake version	3.21.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
       New in version 3.1.

       List TARGET_OBJECTS in SOURCES target property.

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

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

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

       This policy was introduced in CMake version 3.1.	 CMake version	3.21.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_com-
       mand() SOURCE signatures.  The NEW behavior for this policy is to issue
       an error	if such	a signature is used.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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  pro-
       cessing the target sources.  The	NEW behavior for this policy is	to is-
       sue an error if such variables need to be expanded.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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() com-
       mand to specify a project version as well as the	 name.	 In  order  to
       keep  PROJECT_VERSION  and  related  variables consistent with variable
       PROJECT_NAME it is necessary to set the VERSION variables to the	 empty
       string when no VERSION is given to project().  However, this can	change
       behavior	for existing projects that set	VERSION	 variables  themselves
       since  project()	may now	clear them.  This policy controls the behavior
       for compatibility with such projects.

       The OLD behavior	for this policy	is  to	leave  VERSION	variables  un-
       touched.	  The  NEW behavior for	this policy is to set VERSION as docu-
       mented by the project() command.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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 dif-
       ferent from the GNU compiler.  CMake now	prefers	 to  present  this  to
       projects	 by  setting  the CMAKE_<LANG>_COMPILER_ID variable to QCC in-
       stead of	GNU.  However, existing	projects may assume  the  compiler  id
       for  QNX	 qcc  is  just	GNU  as	it was in CMake	versions prior to 3.0.
       Therefore this policy determines	for QNX	qcc which compiler id  to  re-
       port  in	the CMAKE_<LANG>_COMPILER_ID variable after language <LANG> is
       enabled by the project()	or enable_language() command.  The policy must
       be set prior to the invocation of either	command.

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

       This  policy  was  introduced in	CMake version 3.0.  Use	the cmake_pol-
       icy() command to	set this policy	to OLD or NEW explicitly.  Unlike most
       policies,  CMake	version	3.21.3 does not	warn by	default	when this pol-
       icy 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 de-
       pendencies. The NEW behavior for	this policy is to report an  error  if
       non-existent dependencies are listed in the add_dependencies() command.

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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 re-
       sult  variable  to a -NOTFOUND value.  The NEW behavior for this	policy
       is to issue a FATAL_ERROR if the	command	is called with a  non-existent
       target.

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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 com-
       parison with the	value in the <LANG>_COMPILER_ID	 expression.  The  NEW
       behavior	for this policy	is to perform a	case-sensitive comparison with
       the value in the	<LANG>_COMPILER_ID expression.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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 gen-
       erator expressions for setting  configuration-dependent	content.   The
       continued  existence of the suffixed variables is redundant, and	causes
       a maintenance  burden.	Population  of	the  COMPILE_DEFINITIONS_DEBUG
       property	 may  be replaced with a population of COMPILE_DEFINITIONS di-
       rectly or via target_compile_definitions():

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

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

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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  in-
       stall  name.   This  was	 enabled  by  setting  the target property MA-
       COSX_RPATH.  The	@rpath in an install name is a more flexible and  pow-
       erful  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.21.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	gener-
       ated on an IMPORTED target for the install location should not  contain
       paths in	the source directory or	the build directory.

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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  un-
       known  targets.	The NEW	behavior for this policy is to report an error
       if the target referenced	in add_custom_command()	is unknown or was  de-
       fined outside the current directory.

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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 indi-
       cator of	a bug in user code.

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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  di-
       rectly  with  a target_link_libraries() call. This is an	indicator of a
       bug in user code.

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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 pat-
       tern.

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

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

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

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

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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	behav-
       ior for this policy is to allow the command to be called.  The NEW  be-
       havior  for  this  policy is to issue a FATAL_ERROR when	the command is
       called.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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	condi-
       tional logic.  It has long been replaced	by the if() command.

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW be-
       havior for this policy is to issue a FATAL_ERROR	when  the  command  is
       called.

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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  in-
       ternal  CMake  cache entries to a file for installation with a project.
       This was	used at	the time to allow transitive link dependencies to work
       for  applications outside of the	original build tree of a project.  The
       functionality has been superseded by the	export()  and  install(EXPORT)
       commands.

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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	 func-
       tionality is better achieved through dedicated outside tools.

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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 arbi-
       trary commands implemented in C or C++.	However, it does not work when
       the  toolchain  in use does not match the ABI of	the CMake process.  It
       has been	mostly superseded by the macro() and function()	commands.

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW be-
       havior for this policy is to issue a FATAL_ERROR	when  the  command  is
       called.

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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	behav-
       ior for this policy is to allow the command to be called.  The NEW  be-
       havior  for  this  policy is to issue a FATAL_ERROR when	the command is
       called.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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 be-
       havior for this policy is to issue a FATAL_ERROR	if a  link  dependency
       contains	 double-colons	but is not an IMPORTED target or an ALIAS tar-
       get.

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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_DI-
       RECTORIES, and a	check at cmake time that the  entries  in  the	INTER-
       FACE_INCLUDE_DIRECTORIES	 of  an	IMPORTED target	actually exist.	 CMake
       2.8.11  also  introduced	 generator  expression	support	 in  the  tar-
       get_link_libraries() command.  However, if an imported target is	linked
       as a result of a	generator expression evaluation, the  entries  in  the
       INTERFACE_INCLUDE_DIRECTORIES of	that target were not checked for exis-
       tence as	they should be.

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

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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	 loca-
       tion  of	 build targets.	 This relies on	the assumption that all	neces-
       sary information	is available at	configure-time to determine the	 final
       location	 and  filename	of  the	target.	 However, this property	is not
       fully determined	until later at generate-time.  At generate  time,  the
       $<TARGET_FILE>  generator expression can	be used	to determine the even-
       tual LOCATION of	a target output.

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

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

       This policy was introduced in CMake version 3.0.	 CMake version	3.21.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.  How-
       ever,  existing	projects may assume the	compiler id for	Apple Clang is
       just Clang as it	was in CMake versions prior to	3.0.   Therefore  this
       policy  determines  for	Apple Clang which compiler id to report	in the
       CMAKE_<LANG>_COMPILER_ID	variable after language	<LANG> is  enabled  by
       the  project()  or  enable_language()  command.	The policy must	be set
       prior to	the invocation of either command.

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

       This  policy  was  introduced in	CMake version 3.0.  Use	the cmake_pol-
       icy() command to	set this policy	to OLD or NEW explicitly.  Unlike most
       policies,  CMake	version	3.21.3 does not	warn by	default	when this pol-
       icy 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 un-
       til later at generate-time, such	as the link language and complete list
       of  link	 libraries.   Future refactoring will change the effect	of the
       export()	command	to be executed at generate-time.   Use	ALIAS  targets
       instead in cases	where the goal is to refer to targets by another name.

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

       This  policy was	introduced in CMake version 3.0.  CMake	version	3.21.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 explic-
       itly, even if empty.  This produces confusing  behavior	when  used  in
       combination  with  the historical behavior of the plain target_link_li-
       braries() 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 tar-
       get_link_libraries() signatures to be mixed.  The NEW behavior for this
       policy is to not	to allow mixing	of the keyword and plain signatures.

       This  policy  was  introduced  in  CMake	version	2.8.12.	 CMake version
       3.21.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  proper-
       ties  matching  (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.   The
       modern way to specify config-sensitive content is to use	generator  ex-
       pressions and the IMPORTED_ prefix makes	uniform	processing of the link
       interface  with	 generator   expressions   impossible.	  The	INTER-
       FACE_LINK_LIBRARIES  target property was	introduced as a	replacement in
       CMake 2.8.12.  This new property	is named consistently with the	INTER-
       FACE_COMPILE_DEFINITIONS,   INTERFACE_INCLUDE_DIRECTORIES   and	INTER-
       FACE_COMPILE_OPTIONS properties.	 For in-build targets, CMake will  use
       the  INTERFACE_LINK_LIBRARIES property as the source of the link	inter-
       face only if policy CMP0022 is NEW.  When exporting a target which  has
       this policy set to NEW, only the	INTERFACE_LINK_LIBRARIES property will
       be processed and	generated for the IMPORTED target by default.	A  new
       option  to the install(EXPORT) and export commands allows export	of the
       old-style properties for	compatibility with downstream users  of	 CMake
       versions	 older	than 2.8.12.  The target_link_libraries() command will
       no  longer  populate   the   properties	 matching   LINK_INTERFACE_LI-
       BRARIES(_<CONFIG>)? if this policy is NEW.

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

       The  OLD	 behavior  for this policy is to ignore	the INTERFACE_LINK_LI-
       BRARIES property	for in-build targets.  The NEW behavior	for this  pol-
       icy  is	to use the INTERFACE_LINK_LIBRARIES property for in-build tar-
       gets, and ignore	the old	 properties  matching  (IMPORTED_)?LINK_INTER-
       FACE_LIBRARIES(_<CONFIG>)?.

       This  policy  was  introduced  in  CMake	version	2.8.12.	 CMake version
       3.21.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	 prop-
       erty  to	 contain  relative paths.  The base path for such relative en-
       tries is	not well defined.  CMake 2.8.12	issues a  FATAL_ERROR  if  the
       INCLUDE_DIRECTORIES property contains a relative	path.

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

       This policy was introduced in  CMake  version  2.8.12.	CMake  version
       3.21.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 de-
       termining the link dependencies from  IMPORTED  targets.	  This	allows
       CMake  itself to	automatically link executables which link to Qt	to the
       qtmain.lib library when using IMPORTED Qt  targets.   For  applications
       already linking to qtmain.lib, this should have little impact.  For ap-
       plications which	supply their own  alternative  WinMain	implementation
       and  for	 applications  which use the QAxServer library,	this automatic
       linking will need to be disabled	as per the documentation.

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

       This  policy  was  introduced  in  CMake	version	2.8.11.	 CMake version
       3.21.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_direc-
       tories,	link_directories,  and	link_libraries	commands to expand any
       leftover	variable references at the  end	 of  the  configuration	 step.
       This  was  for  strict compatibility with VERY early CMake versions be-
       cause all variable references are now normally evaluated	 during	 CMake
       language	 processing.  CMake 2.8.11 and higher prefer to	skip the extra
       evaluation.

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

       This policy was introduced in  CMake  version  2.8.11.	CMake  version
       3.21.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	deter-
       mine what targets should	be position independent, and new  undocumented
       platform	 variables  to	select	flags  while ignoring CMAKE_SHARED_LI-
       BRARY_<Lang>_FLAGS completely.

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

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

       The  NEW	 behavior  for	this  policy  is  to  ignore  CMAKE_SHARED_LI-
       BRARY_<Lang>_FLAGS  whether  it	is modified or not and honor the POSI-
       TION_INDEPENDENT_CODE target property.

       This policy was introduced  in  CMake  version  2.8.9.	CMake  version
       3.21.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_pack-
       age(),  the  files  located in the CMake	module directory are preferred
       over the	files in CMAKE_MODULE_PATH.  This makes	sure that the  modules
       belonging  to  CMake always get those files included which they expect,
       and against which they were developed and tested.  In all other	cases,
       the  files  found  in  CMAKE_MODULE_PATH	still take precedence over the
       ones in the CMake module	directory.  The	OLD behavior is	to always pre-
       fer  files from CMAKE_MODULE_PATH over files from the CMake modules di-
       rectory.

       This policy was introduced  in  CMake  version  2.8.4.	CMake  version
       3.21.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.21.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_di-
       rectories() command prefers to interpret	relative paths with respect to
       CMAKE_CURRENT_SOURCE_DIR,  which	 is  consistent	 with include_directo-
       ries() 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.21.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_pol-
       icy() 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.21.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 explic-
       itly detect duplicate binary directories.  CMake	2.6.4 always considers
       this  case  an  error.  In CMake	2.8.0 and above	this policy determines
       whether or not the case is an error.  The OLD behavior for this	policy
       is  to  allow  duplicate	binary directories.  The NEW behavior for this
       policy is to disallow duplicate binary directories with an error.

       This policy was introduced  in  CMake  version  2.8.0.	CMake  version
       3.21.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 derefer-
       enced arguments corresponding to	variables, even	those named like  num-
       bers  or	 boolean  constants,  except for 0 and 1.  Numbers and boolean
       constants such as true, false, yes, no, on, off,	y, n, notfound,	ignore
       (all  case insensitive) were recognized in some cases but not all.  For
       example,	the code if(TRUE) might	have evaluated as false.  Numbers such
       as  2 were recognized only in boolean expressions like if(NOT 2)	(lead-
       ing to false) but not as	a single-argument like if(2) (also leading  to
       false).	 Later	versions  of CMake prefer to treat numbers and boolean
       constants literally, so they should not be used as variable names.

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

       This  policy  was  introduced  in  CMake	 version 2.8.0.	 CMake version
       3.21.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	deter-
       mines whether or	not to imply NO_POLICY_SCOPE for  compatibility.   The
       OLD  behavior for this policy is	to imply NO_POLICY_SCOPE for include()
       and find_package() commands.  The NEW behavior for this	policy	is  to
       allow the commands to do	their default cmake_policy PUSH	and POP.

       This  policy  was  introduced  in  CMake	 version 2.6.3.	 CMake version
       3.21.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.21.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  be-
       cause  of  symlinks  to	top level directories that contain hundreds of
       thousands of files.

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

       This policy was introduced  in  CMake  version  2.6.2.	CMake  version
       3.21.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 lib-
       somelib.a or somelib.lib.  For Makefile generators this produces	an er-
       ror  at	build  time  because the dependency on the full	path cannot be
       found.  For Visual Studio Generators IDE	and Xcode generators this used
       to  work	 by  accident because CMake would always split off the library
       directory and ask  the  linker  to  search  for	the  library  by  name
       (-lsomelib  or  somelib.lib).  Despite the failure with Makefiles, some
       projects	have code like this and	build only with	Visual	Studio	and/or
       Xcode.  This version of CMake prefers to	pass the full path directly to
       the native build	tool, which will fail in this case because it does not
       name a valid library file.

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

       This  policy  was  introduced  in  CMake	 version 2.6.1.	 CMake version
       3.21.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  ele-
       ments in	the list.  CMake 2.4 and below list commands ignored all empty
       elements	in the list.  For example, a;b;;c would	have length 3 and  not
       4.   The	OLD behavior for this policy is	to ignore empty	list elements.
       The NEW behavior	for this policy	is to correctly	count  empty  elements
       in a list.

       This  policy  was  introduced  in  CMake	 version 2.6.0.	 CMake version
       3.21.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 MA-
       COSX_BUNDLE property set.  CMake	2.4 and	below did not distinguish  ap-
       plication  bundles  from	 normal	 executables  when installing targets.
       CMake 2.6 provides a BUNDLE option to the install(TARGETS) command that
       specifies  rules	 specific to application bundles on the	Mac.  Projects
       should use this option when installing a	target with the	 MACOSX_BUNDLE
       property	set.

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

       This policy was introduced  in  CMake  version  2.6.0.	CMake  version
       3.21.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  ver-
       sions 2.4 and below assumed that	only trivial values would be given for
       macros  in  add_definitions  calls.   It	 did  not  attempt  to	escape
       non-trivial  values  such  as string literals in	generated build	rules.
       CMake versions 2.6 and above support escaping of	most values, but  can-
       not assume the user has not added escapes already in an attempt to work
       around limitations in earlier versions.

       The OLD behavior	for this policy	is to place definition values given to
       add_definitions	directly in the	generated build	rules without attempt-
       ing to escape anything.	The NEW	behavior for this policy is to	gener-
       ate correct escapes for all native build	tools automatically.  See doc-
       umentation of the COMPILE_DEFINITIONS target property  for  limitations
       of the escaping implementation.

       This  policy  was  introduced  in  CMake	 version 2.6.0.	 CMake version
       3.21.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.21.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 mul-
       tiple link directories such that	the linker would find library A	in the
       desired	location,  but	there  are  cases in which this	does not work.
       CMake versions 2.6 and above use	the more reliable approach of  passing
       the  full  path to libraries directly to	the linker in most cases.  The
       example code now	produces something like

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

       Unfortunately this change can break code	like

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

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

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

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

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

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

       which more accurately matches what the project specified.

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

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

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

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

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

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

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

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

       This policy was introduced  in  CMake  version  2.6.0.	CMake  version
       3.21.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_cus-
       tom_target() are	logical	build target names.  Logical target names must
       be globally unique because:

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

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

       This policy was introduced  in  CMake  version  2.6.0.	CMake  version
       3.21.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_COMPATIBIL-
       ITY completely.

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

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

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

   CMP0000
       A minimum required CMake	version	must be	specified.

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

	  cmake_minimum_required(VERSION <major>.<minor>)

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

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

       This policy was introduced in CMake version 2.6.0.

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

COPYRIGHT
       2000-2021 Kitware, Inc. and Contributors

3.21.3				 Nov 04, 2021		     CMAKE-POLICIES(7)

NAME | INTRODUCTION | POLICIES INTRODUCED BY CMAKE 3.21 | POLICIES INTRODUCED BY CMAKE 3.20 | POLICIES INTRODUCED BY CMAKE 3.19 | POLICIES INTRODUCED BY CMAKE 3.18 | POLICIES INTRODUCED BY CMAKE 3.17 | POLICIES INTRODUCED BY CMAKE 3.16 | POLICIES INTRODUCED BY CMAKE 3.15 | POLICIES INTRODUCED BY CMAKE 3.14 | POLICIES INTRODUCED BY CMAKE 3.13 | POLICIES INTRODUCED BY CMAKE 3.12 | POLICIES INTRODUCED BY CMAKE 3.11 | POLICIES INTRODUCED BY CMAKE 3.10 | POLICIES INTRODUCED BY CMAKE 3.9 | POLICIES INTRODUCED BY CMAKE 3.8 | POLICIES INTRODUCED BY CMAKE 3.7 | POLICIES INTRODUCED BY CMAKE 3.4 | POLICIES INTRODUCED BY CMAKE 3.3 | POLICIES INTRODUCED BY CMAKE 3.2 | POLICIES INTRODUCED BY CMAKE 3.1 | POLICIES INTRODUCED BY CMAKE 3.0 | POLICIES INTRODUCED BY CMAKE 2.8 | POLICIES INTRODUCED BY CMAKE 2.6 | COPYRIGHT

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=cmake-policies&sektion=7&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help