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.8
   CMP0067
       Honor language standard in try_compile()	source-file signature.

       The try_compile() source	file signature is intended to allow callers to
       check whether they will be able to compile a given source file with the
       current	toolchain.   In	order to match compiler	behavior, any language
       standard	mode should match.  However, CMake 3.7 and below  did  not  do
       this.   CMake  3.8 and above prefer to honor the	language standard 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.8.2 does	not warn by default when this  policy  is  not
       set  and	simply uses OLD	behavior.  See documentation of	the CMAKE_POL-
       ICY_WARNING_CMP0067 variable to control the warning.

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

POLICIES INTRODUCED BY CMAKE 3.7
   CMP0066
       Honor per-config	flags in try_compile() source-file signature.

       The  source  file signature of the try_compile()	command	uses the value
       of the CMAKE_<LANG>_FLAGS variable in the test project so that the test
       compilation  works as it	would in the main project.  However, CMake 3.6
       and below do not	also honor  config-specific  compiler  flags  such  as
       those  in  the  CMAKE_<LANG>_FLAGS_DEBUG	variable.  CMake 3.7 and above
       prefer to honor config-specific compiler	flags too.  This  policy  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.8.2 does	not warn by default when this  policy  is  not
       set  and	simply uses OLD	behavior.  See documentation of	the CMAKE_POL-
       ICY_WARNING_CMP0066 variable to control the warning.

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

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

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

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

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

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

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

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

POLICIES INTRODUCED BY CMAKE 3.3
   CMP0063
       Honor visibility	properties for all target types.

       The <LANG>_VISIBILITY_PRESET and	VISIBILITY_INLINES_HIDDEN target prop-
       erties affect visibility	of symbols during dynamic linking.  When first
       introduced  these  properties  affected	compilation of sources only in
       shared libraries, module	libraries, and executables with	the ENABLE_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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

   CMP0062
       Disallow	install() of export() result.

       The  export()  command  generates  a  file containing Imported Targets,
       which is	suitable for use from the build	directory.  It is not suitable
       for  installation because it contains absolute paths to buildsystem 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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

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

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

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

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

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

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

   CMP0060
       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.8.2  does not warn by default when this policy	is not
       set and simply uses OLD behavior.  See documentation of the  CMAKE_POL-
       ICY_WARNING_CMP0060 variable to control the warning.

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

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

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

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

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

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

   CMP0058
       Ninja requires custom command byproducts	to be explicit.

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

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

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

       This works well for all generators except Ninja.	 The Ninja build  tool
       sees  a	rule listing byproduct.txt as a	dependency and no rule listing
       it as an	output.	 Ninja then complains that there is no way to  satisfy
       the  dependency and stops building even though there are	order-only 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.8.2
       warns when it sees unknown dependencies in out-of-source	build trees if
       the policy is not set and then uses OLD behavior.  Use  the  cmake_pol-
       icy()  command  to set the policy to OLD	or NEW explicitly.  The	policy
       setting must be in scope	at the end  of	the  top-level	CMakeLists.txt
       file of the project and has global effect.

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

   CMP0057
       Support new if()	IN_LIST	operator.

       CMake 3.3 adds support for the new IN_LIST operator.

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

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

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

POLICIES INTRODUCED BY CMAKE 3.2
   CMP0056
       Honor link flags	in try_compile() source-file signature.

       The try_compile() command  source-file  signature  generates  a	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.8.2 does	not warn by default when this  policy  is  not
       set  and	simply uses OLD	behavior.  See documentation of	the CMAKE_POL-
       ICY_WARNING_CMP0056 variable to control the warning.

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

   CMP0055
       Strict checking for the break() command.

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

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

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

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

POLICIES INTRODUCED BY CMAKE 3.1
   CMP0054
       Only interpret if() arguments as	variables or keywords when unquoted.

       CMake  3.1  and above no	longer implicitly dereference variables	or 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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

   CMP0053
       Simplify	variable reference and escape sequence evaluation.

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

       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 +.  Variables
	 with  other  characters  in  their name may still be referenced indi-
	 rectly, 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

   CMP0052
       Reject source and build dirs  in	 installed  INTERFACE_INCLUDE_DIRECTO-
       RIES.

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

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

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

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

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

   CMP0051
       List TARGET_OBJECTS in SOURCES target property.

       CMake  3.0  and	lower did not include the TARGET_OBJECTS generator 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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0049
       Do not expand variables in target source	entries.

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

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

       This was	undocumented behavior.

       The OLD behavior	for this policy	is to expand such variables when  pro-
       cessing the target sources.  The	NEW behavior for this policy is	to is-
       sue an error if such variables need to be expanded.

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

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

   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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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

       CMake  3.0 and above recognize that the QNX qcc compiler	driver is dif-
       ferent from the GNU compiler.  CMake now	prefers	 to  present  this  to
       projects	 by  setting  the CMAKE_<LANG>_COMPILER_ID variable to QCC 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.8.2 does not warn by default when this	policy
       is not set and simply uses OLD  behavior.   See	documentation  of  the
       CMAKE_POLICY_WARNING_CMP0047 variable to	control	the warning.

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

   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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0045
       Error on	non-existent target in get_target_property.

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

       The OLD behavior	for this policy	is to issue no warning and set the 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0044
       Case sensitive <LANG>_COMPILER_ID generator expressions

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

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

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

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

   CMP0043
       Ignore COMPILE_DEFINITIONS_<Config> properties

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

       Since CMake 2.8.10, the COMPILE_DEFINITIONS property has	supported gen-
       erator expressions for setting  configuration-dependent	content.   The
       continued  existence of the suffixed variables is redundant, and	causes
       a maintenance  burden.	Population  of	the  COMPILE_DEFINITIONS_DEBUG
       property	 may  be replaced with a population of COMPILE_DEFINITIONS 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0042
       MACOSX_RPATH is enabled by default.

       CMake 2.8.12 and	newer has support for using @rpath in a	 target's  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0041
       Error on	relative include with generator	expression.

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

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

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

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

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

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

   CMP0040
       The  target  in the TARGET signature of add_custom_command() must exist
       and must	be defined in 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy() command to set it	to OLD or NEW explicitly.

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

   CMP0039
       Utility targets may not have link dependencies.

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

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

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

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

   CMP0038
       Targets may not link directly to	themselves.

       CMake 2.8.12 and	lower allowed a	build target to	 link  to  itself  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0037
       Target  names  should  not be reserved and should match a validity pat-
       tern.

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

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

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

       The OLD behavior	for this policy	is to allow creating targets with  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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0036
       The build_name()	command	should not be called.

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

       CMake  >= 3.0 prefer that this command never be called.	The OLD	behav-
       ior for this policy is to allow the command to be called.  The NEW  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0035
       The variable_requires() command should not be called.

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

       CMake >=	3.0 prefer that	this command never be called.  The OLD	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0034
       The utility_source() command should not be called.

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

       CMake >=	3.0 prefer that	this command never be called.  The OLD	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0033
       The export_library_dependencies() command should	not be called.

       This command was	added in January 2003 to export	<tgt>_LIB_DEPENDS  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0032
       The output_required_files() command should not be called.

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

       CMake  >= 3.0 prefer that this command never be called.	The OLD	behav-
       ior for this policy is to allow the command to be called.  The NEW  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0031
       The load_command() command should not be	called.

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

       CMake >=	3.0 prefer that	this command never be called.  The OLD	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0030
       The use_mangled_mesa() command should not be called.

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

       CMake >=	3.0 prefer that	this command never be called.  The OLD	behav-
       ior  for	this policy is to allow	the command to be called.  The NEW 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0029
       The subdir_depends() command should not be called.

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

       CMake  >= 3.0 prefer that this command never be called.	The OLD	behav-
       ior for this policy is to allow the command to be called.  The NEW  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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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

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

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

       The OLD behavior	for this policy	is to search for targets,  then	 files
       on  disk,  even if the search term contains double-colons.  The NEW 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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0027
       Conditionally linked imported targets with missing include directories.

       CMake 2.8.11 introduced introduced the concept of 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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0025
       Compiler	id for Apple Clang is now AppleClang.

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

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

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

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

   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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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 tar-
       get.

       The  OLD	 behavior  for	this policy is to allow	keyword	and plain tar-
       get_link_libraries signatures to	be mixed.  The NEW behavior  for  this
       policy is to not	to allow mixing	of the keyword and plain signatures.

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

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

   CMP0022
       INTERFACE_LINK_LIBRARIES	defines	the link interface.

       CMake 2.8.11 constructed	the 'link interface' of	a target from  proper-
       ties  matching  (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?.   The
       modern way to specify config-sensitive content is to use	generator  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_LIBRARIES(_<CON-
       FIG>)? 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.8.2 warns when	the policy is not set and uses OLD behavior.  Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0021
       Fatal error on relative paths in	INCLUDE_DIRECTORIES target property.

       CMake 2.8.10.2 and lower	allowed	the INCLUDE_DIRECTORIES	 target	 prop-
       erty  to	 contain  relative paths.  The base path for such relative 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.8.2  warns when the policy is not set and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0020
       Automatically link Qt executables to qtmain target on Windows.

       CMake  2.8.10  and  lower required users	of Qt to always	specify	a link
       dependency to the qtmain.lib static library manually on Windows.	 CMake
       2.8.11  gained  the ability to evaluate generator expressions while 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.8.2 warns when	the policy is not set and uses OLD behavior.  Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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

       CMake 2.8.10 and	lower re-evaluated values given	to the	include_direc-
       tories,	link_directories,  and	link_libraries	commands to expand any
       leftover	variable references at the  end	 of  the  configuration	 step.
       This  was  for  strict compatibility with VERY early CMake versions 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.8.2  warns when the policy is not set and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0018
       Ignore CMAKE_SHARED_LIBRARY_<Lang>_FLAGS	variable.

       CMake  2.8.8  and lower compiled	sources	in SHARED and MODULE libraries
       using the value of the  undocumented  CMAKE_SHARED_LIBRARY_<Lang>_FLAGS
       platform	 variable.   The  variable  contained  platform-specific flags
       needed to compile objects for shared libraries.	Typically it  included
       a  flag	such  as -fPIC for position independent	code but also included
       other flags needed on certain platforms.	 CMake 2.8.9 and higher	prefer
       instead	to use the POSITION_INDEPENDENT_CODE target property to	deter-
       mine what targets should	be position independent, and new  undocumented
       platform	 variables  to	select	flags  while ignoring CMAKE_SHARED_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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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

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

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

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

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

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

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

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

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

       In CMake	2.8.0 and lower	the link_directories() command passed relative
       paths  unchanged	 to the	linker.	 In CMake 2.8.1	and above the link_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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0014
       Input directories must have CMakeLists.txt.

       CMake versions before 2.8 silently ignored missing CMakeLists.txt files
       in  directories referenced by add_subdirectory()	or subdirs(), treating
       them as if present but empty.  In CMake 2.8.0 and above this policy de-
       termines	 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0013
       Duplicate binary	directories are	not allowed.

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

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

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

   CMP0012
       if() recognizes numbers and boolean constants.

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

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

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

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

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.8.2
       warns  when  the	 policy	 is  not  set  and uses	OLD behavior.  Use the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0010
       Bad variable reference syntax is	an error.

       In CMake	2.6.2 and below, incorrect variable reference syntax such as a
       missing close-brace ("${FOO") was reported but did not stop  processing
       of CMake	code.  This policy determines whether a	bad variable reference
       is an error.  The OLD behavior for this policy is to warn about the er-
       ror,  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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0009
       FILE GLOB_RECURSE calls should not follow symlinks by default.

       In CMake	2.6.1 and below, FILE GLOB_RECURSE calls would follow  through
       symlinks,  sometimes  coming up with unexpectedly large result sets 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

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

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

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

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

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

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

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

   CMP0007
       list command no longer ignores empty elements.

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

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

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

   CMP0006
       Installing MACOSX_BUNDLE	targets	requires a BUNDLE DESTINATION.

       This  policy  determines	 whether  the install(TARGETS) command must be
       given a BUNDLE DESTINATION when asked to	install	a target with the  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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0005
       Preprocessor definition values are now escaped automatically.

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

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

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

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

   CMP0004
       Libraries linked	may not	have leading or	trailing whitespace.

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

	  target_link_libraries(myexe "	A ")

       This could lead to subtle errors	in user	projects.

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

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

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

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

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

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

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

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

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

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

       Unfortunately this change can break code	like

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

       where  "B" is meant to find "/path/to/libB.so".	This code is wrong be-
       cause the user is asking	the linker to find library B but has not  pro-
       vided  a	 linker	search path (which may be added	with the link_directo-
       ries command).  However,	with the old linking implementation  the  code
       would  work  accidentally  because the linker search path added for li-
       brary 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.8.2
       warns when the policy is	not  set  and  uses  OLD  behavior.   Use  the
       cmake_policy command to set it to OLD or	NEW explicitly.

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

   CMP0002
       Logical target names must be globally unique.

       Targets names created with  add_executable,  add_library,  or  add_cus-
       tom_target  are	logical	build target names.  Logical target names must
       be globally unique because:

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

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

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

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

   CMP0001
       CMAKE_BACKWARDS_COMPATIBILITY should no longer be used.

       The OLD behavior	is to check CMAKE_BACKWARDS_COMPATIBILITY and  present
       it to the user.	The NEW	behavior is to ignore CMAKE_BACKWARDS_COMPATI-
       BILITY completely.

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

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

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

   CMP0000
       A minimum required CMake	version	must be	specified.

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

	  cmake_minimum_required(VERSION <major>.<minor>)

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

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

       This policy was introduced in CMake version 2.6.0.

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

COPYRIGHT
       2000-2017 Kitware, Inc. and Contributors

3.8.2				 Jul 02, 2017		     CMAKE-POLICIES(7)

NAME | INTRODUCTION | 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+12.1-RELEASE+and+Ports>

home | help