cmakepolicies man page on Darwin

Man page or keyword search:  
man Server   23457 pages
apropos Keyword Search (all sections)
Output format
Darwin logo
[printable version]

cmakepolicies(1)					      cmakepolicies(1)

NAME
       cmakepolicies - Reference of CMake policies.

DESCRIPTION
       The  "cmake" executable is the CMake command-line interface.  It may be
       used to configure projects in scripts.  Project configuration  settings
       may be specified on the command line with the -D option.	 The -i option
       will cause cmake to interactively prompt for such settings.

       CMake is a cross-platform build	system	generator.   Projects  specify
       their  build process with platform-independent CMake listfiles included
       in each directory of a source tree with the name CMakeLists.txt.	 Users
       build  a project by using CMake to generate a build system for a native
       tool on their platform.

POLICIES
       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 sup‐
	      port (such as "2.6").  The command will ensure that at least the
	      given version of CMake is running and  help  newer  versions  be
	      compatible  with	the project.  See documentation of cmake_mini‐
	      mum_required for details.

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

	      This policy was introduced in CMake version 2.6.0.

       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_COMPATIBILITY completely.

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

	      This policy was introduced in CMake version 2.6.0.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0002
	      Logical target names must be globally unique.

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

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

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

	      This  policy  was introduced in CMake version 2.6.0.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

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

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

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

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

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

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

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

	      Unfortunately this change can break code like

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

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

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

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

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

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

	      which more accurately matches what the project specified.

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

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

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

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

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

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

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

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

	      This  policy  was introduced in CMake version 2.6.0.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0004
	      Libraries linked may not have leading or trailing whitespace.

	      CMake versions 2.4 and below silently removed leading and trail‐
	      ing 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 set‐
	      ting 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  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0005
	      Preprocessor definition values are now escaped automatically.

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

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

	      This  policy  was introduced in CMake version 2.6.0.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0006
	      Installing MACOSX_BUNDLE targets requires a BUNDLE DESTINATION.

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

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

	      This policy was introduced in CMake version 2.6.0.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0007
	      list command no longer ignores empty elements.

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

	      This policy was introduced in CMake version 2.6.0.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       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 accident because CMake would	 always	 split
	      off  the	library directory and ask the linker to search for the
	      library by name (-lsomelib or somelib.lib).  Despite the failure
	      with Makefiles, some projects have code like this and build only
	      with 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 ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0009
	      FILE GLOB_RECURSE calls should not follow symlinks by default.

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

	      This policy determines whether or not to follow symlinks encoun‐
	      tered during a FILE GLOB_RECURSE call. The OLD behavior for this
	      policy is to follow the symlinks. The NEW behavior for this pol‐
	      icy is not to follow the symlinks by default, but only  if  FOL‐
	      LOW_SYMLINKS is given as an additional argument to the FILE com‐
	      mand.

	      This policy was introduced in CMake version 2.6.2.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0010
	      Bad variable reference syntax is an error.

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

	      This  policy  was introduced in CMake version 2.6.3.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0011
	      Included scripts do automatic cmake_policy PUSH and POP.

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

	      This  policy  was introduced in CMake version 2.6.3.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0012
	      if() recognizes numbers and boolean constants.

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

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

	      This policy was introduced in CMake version 2.8.0.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       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.	  Dur‐
	      ing  build  system  generation  files  would be written and then
	      overwritten in the build tree and could lead to  strange	behav‐
	      ior.   CMake  2.6.4 and above explicitly detect duplicate binary
	      directories.  CMake 2.6.4 always considers this case  an	error.
	      In  CMake	 2.8.0 and above this policy determines whether or not
	      the case is an error.  The OLD behavior for this	policy	is  to
	      allow  duplicate	binary directories.  The NEW behavior for this
	      policy is to  disallow  duplicate	 binary	 directories  with  an
	      error.

	      This  policy  was introduced in CMake version 2.8.0.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0014
	      Input directories must have CMakeLists.txt.

	      CMake  versions  before  2.8  silently  ignored  missing	CMake‐
	      Lists.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 determines whether or not the case
	      is an error.  The OLD behavior for this policy  is  to  silently
	      ignore  the  problem.   The  NEW	behavior for this policy is to
	      report an error.

	      This policy was introduced in CMake version 2.8.0.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

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

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

	      This  policy  was introduced in CMake version 2.8.1.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       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  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

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

	      Starting with CMake 2.8.4, if a cmake-module shipped with	 CMake
	      (i.e.  located in the CMake module directory) calls include() or
	      find_package(), the files located in the CMake module  directory
	      are  preferred  over the files in CMAKE_MODULE_PATH.  This makes
	      sure that the modules belonging to CMake always get those	 files
	      included	which  they expect, and against which they were devel‐
	      oped 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 behaviour is to	always	prefer
	      files  from  CMAKE_MODULE_PATH over files from the CMake modules
	      directory.

	      This policy was introduced in CMake version 2.8.4.   CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       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 vari‐
	      able 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 pre‐
	      fer instead to use the POSITION_INDEPENDENT_CODE target property
	      to  determine  what  targets should be position independent, and
	      new undocumented platform variables to select flags while ignor‐
	      ing CMAKE_SHARED_LIBRARY_<Lang>_FLAGS completely.

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

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

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

	      This  policy  was introduced in CMake version 2.8.9.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

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

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

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

	      This policy was introduced in CMake version 2.8.11.  CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0020
	      Automatically link Qt executables to qtmain target on Windows.

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

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

	      This  policy was introduced in CMake version 2.8.11.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

       CMP0021
	      Fatal error on  relative	paths  in  INCLUDE_DIRECTORIES	target
	      property.

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

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

	      This policy was introduced in CMake version 2.8.12.  CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0022
	      INTERFACE_LINK_LIBRARIES defines the link interface.

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

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

	      This policy was introduced in CMake version 2.8.12.  CMake  ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.  Use the cmake_policy command to  set  it  to  OLD  or  NEW
	      explicitly.

       CMP0023
	      Plain  and  keyword  target_link_libraries  signatures cannot be
	      mixed.

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

	       target_link_libraries(mylib A)
	       target_link_libraries(mylib PRIVATE B)

	      After the first line the link interface has not been set explic‐
	      itly 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 tar‐
	      get_link_libraries for a single target.

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

	      This  policy was introduced in CMake version 2.8.12.  CMake ver‐
	      sion 2.8.12 warns when the policy is not set and uses OLD behav‐
	      ior.   Use  the  cmake_policy  command  to  set it to OLD or NEW
	      explicitly.

COPYRIGHT
       Copyright 2000-2012 Kitware, Inc., Insight  Software  Consortium.   All
       rights reserved.

       Redistribution and use in source and binary forms, with or without mod‐
       ification, are permitted provided that  the  following  conditions  are
       met:

       Redistributions	of source code must retain the above copyright notice,
       this list of conditions and the following disclaimer.

       Redistributions in binary  form	must  reproduce	 the  above  copyright
       notice,	this  list  of	conditions and the following disclaimer in the
       documentation and/or other materials provided with the distribution.

       Neither the names of Kitware, Inc., the	Insight	 Software  Consortium,
       nor  the	 names of their contributors may be used to endorse or promote
       products derived from this software without specific prior written per‐
       mission.

       THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
       IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT  NOT  LIMITED
       TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTIC‐
       ULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER  OR
       CONTRIBUTORS  BE	 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
       EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,	BUT  NOT  LIMITED  TO,
       PROCUREMENT  OF	SUBSTITUTE  GOODS  OR  SERVICES; LOSS OF USE, DATA, OR
       PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY  OF
       LIABILITY,  WHETHER  IN	CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
       NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT	OF  THE	 USE  OF  THIS
       SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

SEE ALSO
       ccmake(1), cpack(1), ctest(1), cmakecommands(1), cmakecompat(1), cmake‐
       modules(1), cmakeprops(1), cmakevars(1)

       The following resources are available to get help using CMake:

       Home Page
	      http://www.cmake.org

	      The primary starting point for learning about CMake.

       Frequently Asked Questions
	      http://www.cmake.org/Wiki/CMake_FAQ

	      A Wiki is provided containing answers to frequently asked	 ques‐
	      tions.

       Online Documentation
	      http://www.cmake.org/HTML/Documentation.html

	      Links to available documentation may be found on this web page.

       Mailing List
	      http://www.cmake.org/HTML/MailingLists.html

	      For  help	 and  discussion  about using cmake, a mailing list is
	      provided at cmake@cmake.org. The list  is	 member-post-only  but
	      one  may	sign  up  on the CMake web page. Please first read the
	      full documentation at http://www.cmake.org before posting	 ques‐
	      tions to the list.

cmake 2.8.12		       January 15, 2014		      cmakepolicies(1)
[top]

List of man pages available for Darwin

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net