Unix/Linux Go Back    


CentOS 7.0 - man page for cmakecommands (centos section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


cmakecommands(1)								 cmakecommands(1)

NAME
       cmakecommands - Reference of available CMake commands.

COMMANDS
       add_custom_command
	      Add a custom build rule to the generated build system.

	      There  are  two  main  signatures for add_custom_command The first signature is for
	      adding a custom command to produce an output.

		add_custom_command(OUTPUT output1 [output2 ...]
				   COMMAND command1 [ARGS] [args1...]
				   [COMMAND command2 [ARGS] [args2...] ...]
				   [MAIN_DEPENDENCY depend]
				   [DEPENDS [depends...]]
				   [IMPLICIT_DEPENDS <lang1> depend1
						    [<lang2> depend2] ...]
				   [WORKING_DIRECTORY dir]
				   [COMMENT comment] [VERBATIM] [APPEND])

	      This defines a command to generate specified OUTPUT file(s).  A target  created  in
	      the  same  directory  (CMakeLists.txt file) that specifies any output of the custom
	      command as a source file is given a rule to generate the file using the command  at
	      build  time.   Do  not list the output in more than one independent target that may
	      build in parallel or the two instances  of  the  rule  may  conflict  (instead  use
	      add_custom_target  to  drive  the command and make the other targets depend on that
	      one).  If an output name is a relative path it will be interpreted relative to  the
	      build  tree  directory  corresponding  to  the  current source directory. Note that
	      MAIN_DEPENDENCY is completely optional and is used as a suggestion to visual studio
	      about where to hang the custom command. In makefile terms this creates a new target
	      in the following form:

		OUTPUT: MAIN_DEPENDENCY DEPENDS
			COMMAND

	      If more than one command is specified they will be executed in order. The  optional
	      ARGS argument is for backward compatibility and will be ignored.

	      The  second  signature  adds a custom command to a target such as a library or exe-
	      cutable. This is useful for performing an operation before or  after  building  the
	      target.  The command becomes part of the target and will only execute when the tar-
	      get itself is built.  If the target is already built, the command will not execute.

		add_custom_command(TARGET target
				   PRE_BUILD | PRE_LINK | POST_BUILD
				   COMMAND command1 [ARGS] [args1...]
				   [COMMAND command2 [ARGS] [args2...] ...]
				   [WORKING_DIRECTORY dir]
				   [COMMENT comment] [VERBATIM])

	      This defines a new command that will be associated with building the specified tar-
	      get. When the command will happen is determined by which of the following is speci-
	      fied:

		PRE_BUILD - run before all other dependencies
		PRE_LINK - run after other dependencies
		POST_BUILD - run after the target has been built

	      Note that the PRE_BUILD option is only supported on Visual Studio 7 or  later.  For
	      all other generators PRE_BUILD will be treated as PRE_LINK.

	      If  WORKING_DIRECTORY  is  specified  the command will be executed in the directory
	      given. If it is a relative path it will be interpreted relative to the  build  tree
	      directory  corresponding	to  the  current source directory. If COMMENT is set, the
	      value will be displayed as a message before the  commands  are  executed	at  build
	      time.  If APPEND is specified the COMMAND and DEPENDS option values are appended to
	      the custom command for the first output specified. There must have already  been	a
	      previous call to this command with the same output. The COMMENT, WORKING_DIRECTORY,
	      and MAIN_DEPENDENCY options are currently ignored when APPEND is given, but may  be
	      used in the future.

	      If  VERBATIM  is	given then all arguments to the commands will be escaped properly
	      for the build tool so that the invoked command receives  each  argument  unchanged.
	      Note that one level of escapes is still used by the CMake language processor before
	      add_custom_command even sees the arguments. Use of VERBATIM is  recommended  as  it
	      enables  correct behavior. When VERBATIM is not given the behavior is platform spe-
	      cific because there is no protection of tool-specific special characters.

	      If the output of the custom command is not actually created as a file  on  disk  it
	      should be marked as SYMBOLIC with SET_SOURCE_FILES_PROPERTIES.

	      The  IMPLICIT_DEPENDS option requests scanning of implicit dependencies of an input
	      file.  The language given specifies the programming  language  whose  corresponding
	      dependency  scanner should be used.  Currently only C and CXX language scanners are
	      supported. The language has to be specified for every file in the  IMPLICIT_DEPENDS
	      list.  Dependencies  discovered  from the scanning are added to those of the custom
	      command at build time.  Note that the IMPLICIT_DEPENDS  option  is  currently  sup-
	      ported only for Makefile generators and will be ignored by other generators.

	      If COMMAND specifies an executable target (created by ADD_EXECUTABLE) it will auto-
	      matically be replaced by the location of the  executable	created  at  build  time.
	      Additionally  a target-level dependency will be added so that the executable target
	      will be built before any target using this custom command.  However this	does  NOT
	      add  a file-level dependency that would cause the custom command to re-run whenever
	      the executable is recompiled.

	      Arguments to COMMAND may use "generator  expressions"  with  the	syntax	"$<...>".
	      Generator expressions are evaluted during build system generation to produce infor-
	      mation specific to each build configuration.  Valid expressions are:

		$<0:...>		  = empty string (ignores "...")
		$<1:...>		  = content of "..."
		$<CONFIG:cfg>		  = '1' if config is "cfg", else '0'
		$<CONFIGURATION>	  = configuration name
		$<BOOL:...>		  = '1' if the '...' is true, else '0'
		$<STREQUAL:a,b> 	  = '1' if a is STREQUAL b, else '0'
		$<ANGLE-R>		  = A literal '>'. Used to compare strings which contain a '>' for example.
		$<COMMA>		  = A literal ','. Used to compare strings which contain a ',' for example.
		$<SEMICOLON>		  = A literal ';'. Used to prevent list expansion on an argument with ';'.
		$<TARGET_NAME:...>	  = Marks ... as being the name of a target.  This is required if exporting targets to multiple dependent export sets.	The '...' must be a literal name of a target- it may not contain generator expressions.
		$<INSTALL_INTERFACE:...>  = content of "..." when the property is exported using install(EXPORT), and empty otherwise.
		$<BUILD_INTERFACE:...>	  = content of "..." when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
		$<TARGET_FILE:tgt>	  = main file (.exe, .so.1.2, .a)
		$<TARGET_LINKER_FILE:tgt> = file used to link (.a, .lib, .so)
		$<TARGET_SONAME_FILE:tgt> = file with soname (.so.3)

	      where "tgt" is the name of a target.  Target file expressions produce a full  path,
	      but _DIR and _NAME versions can produce the directory and file name components:

		$<TARGET_FILE_DIR:tgt>/$<TARGET_FILE_NAME:tgt>
		$<TARGET_LINKER_FILE_DIR:tgt>/$<TARGET_LINKER_FILE_NAME:tgt>
		$<TARGET_SONAME_FILE_DIR:tgt>/$<TARGET_SONAME_FILE_NAME:tgt>

		$<TARGET_PROPERTY:tgt,prop>   = The value of the property prop on the target tgt.

	      Note  that tgt is not added as a dependency of the target this expression is evalu-
	      ated on.

		$<TARGET_POLICY:pol>	      = '1' if the policy was NEW when the 'head' target was created, else '0'.  If the policy was not set, the warning message for the policy will be emitted.  This generator expression only works for a subset of policies.
		$<INSTALL_PREFIX>	  = Content of the install prefix when the target is exported via INSTALL(EXPORT) and empty otherwise.

	      Boolean expressions:

		$<AND:?[,?]...> 	  = '1' if all '?' are '1', else '0'
		$<OR:?[,?]...>		  = '0' if all '?' are '0', else '1'
		$<NOT:?>		  = '0' if '?' is '1', else '1'

	      where '?' is always either '0' or '1'.

	      Expressions with an implicit 'this' target:

		$<TARGET_PROPERTY:prop>   = The value of the property prop on the target on which the generator expression is evaluated.

	      References to target names in generator expressions  imply  target-level	dependen-
	      cies,  but  NOT file-level dependencies.	List target names with the DEPENDS option
	      to add file dependencies.

	      The DEPENDS option specifies files on which the command depends.	If any dependency
	      is  an OUTPUT of another custom command in the same directory (CMakeLists.txt file)
	      CMake automatically brings the other custom command into the target in  which  this
	      command  is  built.   If DEPENDS is not specified the command will run whenever the
	      OUTPUT is missing; if the command does not actually create the OUTPUT then the rule
	      will  always  run.  If DEPENDS specifies any target (created by an ADD_* command) a
	      target-level dependency is created to make sure the target is built before any tar-
	      get  using  this	custom	command.  Additionally, if the target is an executable or
	      library a file-level dependency is created to cause the custom  command  to  re-run
	      whenever the target is recompiled.

       add_custom_target
	      Add a target with no output so it will always be built.

		add_custom_target(Name [ALL] [command1 [args1...]]
				  [COMMAND command2 [args2...] ...]
				  [DEPENDS depend depend depend ... ]
				  [WORKING_DIRECTORY dir]
				  [COMMENT comment] [VERBATIM]
				  [SOURCES src1 [src2...]])

	      Adds  a target with the given name that executes the given commands. The target has
	      no output file and is ALWAYS CONSIDERED OUT OF DATE even if  the	commands  try  to
	      create  a  file  with  the name of the target. Use ADD_CUSTOM_COMMAND to generate a
	      file with dependencies. By default  nothing  depends  on	the  custom  target.  Use
	      ADD_DEPENDENCIES to add dependencies to or from other targets. If the ALL option is
	      specified it indicates that this target should be added to the default build target
	      so  that	it will be run every time (the command cannot be called ALL). The command
	      and arguments are optional and if not specified an empty target will be created. If
	      WORKING_DIRECTORY  is set, then the command will be run in that directory. If it is
	      a relative path it will be interpreted relative to the build tree directory  corre-
	      sponding to the current source directory. If COMMENT is set, the value will be dis-
	      played as a message before the commands are executed at  build  time.  Dependencies
	      listed with the DEPENDS argument may reference files and outputs of custom commands
	      created with add_custom_command() in the same directory (CMakeLists.txt file).

	      If VERBATIM is given then all arguments to the commands will  be	escaped  properly
	      for  the	build  tool so that the invoked command receives each argument unchanged.
	      Note that one level of escapes is still used by the CMake language processor before
	      add_custom_target  even  sees  the  arguments. Use of VERBATIM is recommended as it
	      enables correct behavior. When VERBATIM is not given the behavior is platform  spe-
	      cific because there is no protection of tool-specific special characters.

	      The  SOURCES  option specifies additional source files to be included in the custom
	      target.  Specified source files will be added to IDE project files for  convenience
	      in editing even if they have not build rules.

       add_definitions
	      Adds -D define flags to the compilation of source files.

		add_definitions(-DFOO -DBAR ...)

	      Adds  flags  to  the compiler command line for sources in the current directory and
	      below.  This command can be used to add any flags, but it was  originally  intended
	      to  add  preprocessor definitions.  Flags beginning in -D or /D that look like pre-
	      processor definitions are automatically added to the  COMPILE_DEFINITIONS  property
	      for  the	current directory.  Definitions with non-trival values may be left in the
	      set of flags instead of being converted for  reasons  of	backwards  compatibility.
	      See  documentation  of  the  directory, target, and source file COMPILE_DEFINITIONS
	      properties for details on adding preprocessor definitions to  specific  scopes  and
	      configurations.

       add_dependencies
	      Add a dependency between top-level targets.

		add_dependencies(target-name depend-target1
				 depend-target2 ...)

	      Make  a  top-level target depend on other top-level targets.  A top-level target is
	      one created by ADD_EXECUTABLE, ADD_LIBRARY, or ADD_CUSTOM_TARGET.  Adding dependen-
	      cies  with this command can be used to make sure one target is built before another
	      target.  Dependencies added to an IMPORTED target are followed transitively in  its
	      place  since  the target itself does not build.  See the DEPENDS option of ADD_CUS-
	      TOM_TARGET and ADD_CUSTOM_COMMAND for  adding  file-level  dependencies  in  custom
	      rules.   See  the  OBJECT_DEPENDS  option  in  SET_SOURCE_FILES_PROPERTIES  to  add
	      file-level dependencies to object files.

       add_executable
	      Add an executable to the project using the specified source files.

		add_executable(<name> [WIN32] [MACOSX_BUNDLE]
			       [EXCLUDE_FROM_ALL]
			       source1 source2 ... sourceN)

	      Adds an executable target called <name> to be built from the source files listed in
	      the command invocation.  The <name> corresponds to the logical target name and must
	      be globally unique within a project.  The actual file name of the executable  built
	      is  constructed  based on conventions of the native platform (such as <name>.exe or
	      just <name>).

	      By default the executable file will be created in the build tree	directory  corre-
	      sponding	to the source tree directory in which the command was invoked.	See docu-
	      mentation of the RUNTIME_OUTPUT_DIRECTORY target property to change this	location.
	      See  documentation  of the OUTPUT_NAME target property to change the <name> part of
	      the final file name.

	      If WIN32 is given the property WIN32_EXECUTABLE will be set on the target  created.
	      See documentation of that target property for details.

	      If  MACOSX_BUNDLE  is  given  the corresponding property will be set on the created
	      target.  See documentation of the MACOSX_BUNDLE target property for details.

	      If EXCLUDE_FROM_ALL is given the corresponding property will be set on the  created
	      target.  See documentation of the EXCLUDE_FROM_ALL target property for details.

	      The  add_executable  command can also create IMPORTED executable targets using this
	      signature:

		add_executable(<name> IMPORTED [GLOBAL])

	      An IMPORTED executable target references an executable  file  located  outside  the
	      project.	 No  rules  are  generated to build it.  The target name has scope in the
	      directory in which it is created and below, but the GLOBAL option extends  visibil-
	      ity.  It may be referenced like any target built within the project.  IMPORTED exe-
	      cutables are useful for convenient reference from commands like add_custom_command.
	      Details  about  the  imported  executable are specified by setting properties whose
	      names begin in "IMPORTED_".  The most important such property is	IMPORTED_LOCATION
	      (and  its per-configuration version IMPORTED_LOCATION_<CONFIG>) which specifies the
	      location of the main executable file on disk.  See documentation of the  IMPORTED_*
	      properties for more information.

       add_library
	      Add a library to the project using the specified source files.

		add_library(<name> [STATIC | SHARED | MODULE]
			    [EXCLUDE_FROM_ALL]
			    source1 source2 ... sourceN)

	      Adds a library target called <name> to be built from the source files listed in the
	      command invocation.  The <name> corresponds to the logical target name and must  be
	      globally	unique	within	a  project.  The actual file name of the library built is
	      constructed based on conventions of the native platform  (such  as  lib<name>.a  or
	      <name>.lib).

	      STATIC,  SHARED,	or  MODULE may be given to specify the type of library to be cre-
	      ated.  STATIC libraries are archives of object files for	use  when  linking  other
	      targets.	 SHARED  libraries  are linked dynamically and loaded at runtime.  MODULE
	      libraries are plugins that are not linked into other  targets  but  may  be  loaded
	      dynamically  at  runtime	using  dlopen-like  functionality.   If  no type is given
	      explicitly the type is STATIC or SHARED based on whether the current value  of  the
	      variable	BUILD_SHARED_LIBS  is  true.   For  SHARED and MODULE libraries the POSI-
	      TION_INDEPENDENT_CODE target property is set to TRUE automatically.

	      By default the library file will be created in the build tree directory correspond-
	      ing  to the source tree directory in which the command was invoked.  See documenta-
	      tion of the ARCHIVE_OUTPUT_DIRECTORY,  LIBRARY_OUTPUT_DIRECTORY,	and  RUNTIME_OUT-
	      PUT_DIRECTORY  target properties to change this location.  See documentation of the
	      OUTPUT_NAME target property to change the <name> part of the final file name.

	      If EXCLUDE_FROM_ALL is given the corresponding property will be set on the  created
	      target.  See documentation of the EXCLUDE_FROM_ALL target property for details.

	      The  add_library command can also create IMPORTED library targets using this signa-
	      ture:

		add_library(<name> <SHARED|STATIC|MODULE|UNKNOWN> IMPORTED
			    [GLOBAL])

	      An IMPORTED library target references a library file located outside  the  project.
	      No  rules are generated to build it.  The target name has scope in the directory in
	      which it is created and below, but the GLOBAL option extends visibility.	It may be
	      referenced like any target built within the project.  IMPORTED libraries are useful
	      for convenient reference from commands like target_link_libraries.   Details  about
	      the  imported  library  are  specified  by  setting properties whose names begin in
	      "IMPORTED_".  The most  important  such  property  is  IMPORTED_LOCATION	(and  its
	      per-configuration  version IMPORTED_LOCATION_<CONFIG>) which specifies the location
	      of the main library file on disk.  See documentation of the  IMPORTED_*  properties
	      for more information.

	      The signature

		add_library(<name> OBJECT <src>...)

	      creates a special "object library" target.  An object library compiles source files
	      but does not archive or link their object files into a library.  Instead other tar-
	      gets  created  by  add_library or add_executable may reference the objects using an
	      expression of the form $<TARGET_OBJECTS:objlib> as a source, where "objlib" is  the
	      object library name.  For example:

		add_library(... $<TARGET_OBJECTS:objlib> ...)
		add_executable(... $<TARGET_OBJECTS:objlib> ...)

	      will  include objlib's object files in a library and an executable along with those
	      compiled from their own sources.	Object libraries may contain  only  sources  (and
	      headers) that compile to object files.  They may contain custom commands generating
	      such  sources,  but  not	PRE_BUILD,  PRE_LINK,  or  POST_BUILD  commands.   Object
	      libraries  cannot  be  imported, exported, installed, or linked.	Some native build
	      systems may not like targets that have only object files,  so  consider  adding  at
	      least one real source file to any target that references $<TARGET_OBJECTS:objlib>.

       add_subdirectory
	      Add a subdirectory to the build.

		add_subdirectory(source_dir [binary_dir]
				 [EXCLUDE_FROM_ALL])

	      Add  a  subdirectory  to the build. The source_dir specifies the directory in which
	      the source CmakeLists.txt and code files are located. If it is a relative  path  it
	      will be evaluated with respect to the current directory (the typical usage), but it
	      may also be an absolute path. The binary_dir specifies the directory  in	which  to
	      place  the output files. If it is a relative path it will be evaluated with respect
	      to the current output directory, but it may also be an absolute path. If binary_dir
	      is not specified, the value of source_dir, before expanding any relative path, will
	      be used (the typical usage). The CMakeLists.txt file in the specified source direc-
	      tory  will be processed immediately by CMake before processing in the current input
	      file continues beyond this command.

	      If the EXCLUDE_FROM_ALL argument is provided then targets in the subdirectory  will
	      not  be  included in the ALL target of the parent directory by default, and will be
	      excluded from IDE project files.	Users must explicitly build targets in the subdi-
	      rectory.	 This  is meant for use when the subdirectory contains a separate part of
	      the project that is useful but not necessary, such as a set of examples.	Typically
	      the subdirectory should contain its own project() command invocation so that a full
	      build system will be generated in the subdirectory  (such  as  a	VS  IDE  solution
	      file).   Note that inter-target dependencies supercede this exclusion.  If a target
	      built by the parent project depends on a target in the subdirectory,  the  dependee
	      target  will  be	included in the parent project build system to satisfy the depen-
	      dency.

       add_test
	      Add a test to the project with the specified arguments.

		add_test(testname Exename arg1 arg2 ... )

	      If the ENABLE_TESTING command has been run, this command adds a test target to  the
	      current  directory.  If ENABLE_TESTING has not been run, this command does nothing.
	      The tests are run by the testing subsystem by executing Exename with the	specified
	      arguments.   Exename  can be either an executable built by this project or an arbi-
	      trary executable on the system (like tclsh).  The test will be run with the current
	      working  directory  set  to  the CMakeList.txt files corresponding directory in the
	      binary tree.

		add_test(NAME <name> [CONFIGURATIONS [Debug|Release|...]]
			 [WORKING_DIRECTORY dir]
			 COMMAND <command> [arg1 [arg2 ...]])

	      If COMMAND specifies an executable target (created by add_executable) it will auto-
	      matically  be replaced by the location of the executable created at build time.  If
	      a CONFIGURATIONS option is given then the test will be executed only  when  testing
	      under one of the named configurations.  If a WORKING_DIRECTORY option is given then
	      the test will be executed in the given directory.

	      Arguments after COMMAND may use "generator expressions" with the	syntax	"$<...>".
	      Generator expressions are evaluted during build system generation to produce infor-
	      mation specific to each build configuration.  Valid expressions are:

		$<0:...>		  = empty string (ignores "...")
		$<1:...>		  = content of "..."
		$<CONFIG:cfg>		  = '1' if config is "cfg", else '0'
		$<CONFIGURATION>	  = configuration name
		$<BOOL:...>		  = '1' if the '...' is true, else '0'
		$<STREQUAL:a,b> 	  = '1' if a is STREQUAL b, else '0'
		$<ANGLE-R>		  = A literal '>'. Used to compare strings which contain a '>' for example.
		$<COMMA>		  = A literal ','. Used to compare strings which contain a ',' for example.
		$<SEMICOLON>		  = A literal ';'. Used to prevent list expansion on an argument with ';'.
		$<TARGET_NAME:...>	  = Marks ... as being the name of a target.  This is required if exporting targets to multiple dependent export sets.	The '...' must be a literal name of a target- it may not contain generator expressions.
		$<INSTALL_INTERFACE:...>  = content of "..." when the property is exported using install(EXPORT), and empty otherwise.
		$<BUILD_INTERFACE:...>	  = content of "..." when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
		$<TARGET_FILE:tgt>	  = main file (.exe, .so.1.2, .a)
		$<TARGET_LINKER_FILE:tgt> = file used to link (.a, .lib, .so)
		$<TARGET_SONAME_FILE:tgt> = file with soname (.so.3)

	      where "tgt" is the name of a target.  Target file expressions produce a full  path,
	      but _DIR and _NAME versions can produce the directory and file name components:

		$<TARGET_FILE_DIR:tgt>/$<TARGET_FILE_NAME:tgt>
		$<TARGET_LINKER_FILE_DIR:tgt>/$<TARGET_LINKER_FILE_NAME:tgt>
		$<TARGET_SONAME_FILE_DIR:tgt>/$<TARGET_SONAME_FILE_NAME:tgt>

		$<TARGET_PROPERTY:tgt,prop>   = The value of the property prop on the target tgt.

	      Note  that tgt is not added as a dependency of the target this expression is evalu-
	      ated on.

		$<TARGET_POLICY:pol>	      = '1' if the policy was NEW when the 'head' target was created, else '0'.  If the policy was not set, the warning message for the policy will be emitted.  This generator expression only works for a subset of policies.
		$<INSTALL_PREFIX>	  = Content of the install prefix when the target is exported via INSTALL(EXPORT) and empty otherwise.

	      Boolean expressions:

		$<AND:?[,?]...> 	  = '1' if all '?' are '1', else '0'
		$<OR:?[,?]...>		  = '0' if all '?' are '0', else '1'
		$<NOT:?>		  = '0' if '?' is '1', else '1'

	      where '?' is always either '0' or '1'.

	      Example usage:

		add_test(NAME mytest
			 COMMAND testDriver --config $<CONFIGURATION>
					    --exe $<TARGET_FILE:myexe>)

	      This creates a test "mytest" whose command runs a testDriver tool passing the  con-
	      figuration  name	and  the  full	path  to  the  executable file produced by target
	      "myexe".

       aux_source_directory
	      Find all source files in a directory.

		aux_source_directory(<dir> <variable>)

	      Collects the names of all the source files in the specified  directory  and  stores
	      the  list  in  the  <variable>  provided.   This	command is intended to be used by
	      projects that use explicit template instantiation.   Template  instantiation  files
	      can  be stored in a "Templates" subdirectory and collected automatically using this
	      command to avoid manually listing all instantiations.

	      It is tempting to use this command to avoid writing the list of source files for	a
	      library  or executable target.  While this seems to work, there is no way for CMake
	      to generate a build system that knows when a new source file has been added.   Nor-
	      mally  the  generated  build  system knows when it needs to rerun CMake because the
	      CMakeLists.txt file is modified to add a new source.  When the source is just added
	      to  the  directory  without  modifying  this file, one would have to manually rerun
	      CMake to generate a build system incorporating the new file.

       break  Break from an enclosing foreach or while loop.

		break()

	      Breaks from an enclosing foreach loop or while loop

       build_command
	      Get the command line to build this project.

		build_command(<variable>
			      [CONFIGURATION <config>]
			      [PROJECT_NAME <projname>]
			      [TARGET <target>])

	      Sets the given <variable> to a string containing the command line for building  one
	      configuration  of  a  target  in a project using the build tool appropriate for the
	      current CMAKE_GENERATOR.

	      If CONFIGURATION	is  omitted,  CMake  chooses  a  reasonable  default  value   for
	      multi-configuration  generators.	CONFIGURATION is ignored for single-configuration
	      generators.

	      If PROJECT_NAME is omitted, the resulting command line will  build  the  top  level
	      PROJECT in the current build tree.

	      If TARGET is omitted, the resulting command line will build everything, effectively
	      using build target 'all' or 'ALL_BUILD'.

		build_command(<cachevariable> <makecommand>)

	      This second signature is deprecated, but still available for backwards  compatibil-
	      ity. Use the first signature instead.

	      Sets  the  given	<cachevariable>  to a string containing the command to build this
	      project from the root of the build tree using the build  tool  given  by	<makecom-
	      mand>.   <makecommand> should be the full path to msdev, devenv, nmake, make or one
	      of the end user build tools.

       cmake_minimum_required
	      Set the minimum required version of cmake for a project.

		cmake_minimum_required(VERSION major[.minor[.patch[.tweak]]]
				       [FATAL_ERROR])

	      If the current version of CMake is lower than that required it will stop processing
	      the  project  and report an error.  When a version higher than 2.4 is specified the
	      command implicitly invokes

		cmake_policy(VERSION major[.minor[.patch[.tweak]]])

	      which sets the cmake policy version level to the version specified.   When  version
	      2.4 or lower is given the command implicitly invokes

		cmake_policy(VERSION 2.4)

	      which enables compatibility features for CMake 2.4 and lower.

	      The  FATAL_ERROR option is accepted but ignored by CMake 2.6 and higher.	It should
	      be specified so CMake versions 2.4 and lower fail with an error instead of  just	a
	      warning.

       cmake_policy
	      Manage CMake Policy settings.

	      As  CMake evolves it is sometimes necessary to change existing behavior in order to
	      fix bugs or improve implementations of existing features.  The CMake Policy  mecha-
	      nism  is	designed to help keep existing projects building as new versions of CMake
	      introduce changes in behavior.  Each new policy (behavioral  change)  is	given  an
	      identifier  of the form "CMP<NNNN>" where "<NNNN>" is an integer index.  Documenta-
	      tion associated with each policy describes the OLD and NEW behavior and the  reason
	      the  policy  was	introduced.   Projects	may set each policy to select the desired
	      behavior.  When CMake needs to know which behavior to use it checks for  a  setting
	      specified  by  the project.  If no setting is available the OLD behavior is assumed
	      and a warning is produced requesting that the policy be set.

	      The cmake_policy command is used to set policies to OLD  or  NEW	behavior.   While
	      setting  policies  individually is supported, we encourage projects to set policies
	      based on CMake versions.

		cmake_policy(VERSION major.minor[.patch[.tweak]])

	      Specify that the current CMake list file is written for the given version of CMake.
	      All  policies introduced in the specified version or earlier will be set to use NEW
	      behavior.  All policies introduced  after  the  specified  version  will	be  unset
	      (unless  variable CMAKE_POLICY_DEFAULT_CMP<NNNN> sets a default).  This effectively
	      requests behavior preferred as of a given CMake version and tells newer CMake  ver-
	      sions  to  warn  about their new policies.  The policy version specified must be at
	      least 2.4 or the command will report an error.  In order to get compatibility  fea-
	      tures supporting versions earlier than 2.4 see documentation of policy CMP0001.

		cmake_policy(SET CMP<NNNN> NEW)
		cmake_policy(SET CMP<NNNN> OLD)

	      Tell  CMake  to use the OLD or NEW behavior for a given policy.  Projects depending
	      on the old behavior of a given policy may silence a policy warning by  setting  the
	      policy  state  to  OLD.  Alternatively one may fix the project to work with the new
	      behavior and set the policy state to NEW.

		cmake_policy(GET CMP<NNNN> <variable>)

	      Check whether a given policy is set to OLD or NEW behavior.   The  output  variable
	      value will be "OLD" or "NEW" if the policy is set, and empty otherwise.

	      CMake keeps policy settings on a stack, so changes made by the cmake_policy command
	      affect only the top of the stack.  A new entry on the policy stack is managed auto-
	      matically  for  each  subdirectory to protect its parents and siblings.  CMake also
	      manages a new entry for scripts loaded by  include()  and  find_package()  commands
	      except when invoked with the NO_POLICY_SCOPE option (see also policy CMP0011).  The
	      cmake_policy command provides an interface to manage custom entries on  the  policy
	      stack:

		cmake_policy(PUSH)
		cmake_policy(POP)

	      Each  PUSH  must	have a matching POP to erase any changes.  This is useful to make
	      temporary changes to policy settings.

	      Functions and macros record policy settings when	they  are  created  and  use  the
	      pre-record policies when they are invoked.  If the function or macro implementation
	      sets policies, the changes automatically propagate up through  callers  until  they
	      reach the closest nested policy stack entry.

       configure_file
	      Copy a file to another location and modify its contents.

		configure_file(<input> <output>
			       [COPYONLY] [ESCAPE_QUOTES] [@ONLY]
			       [NEWLINE_STYLE [UNIX|DOS|WIN32|LF|CRLF] ])

	      Copies  a  file <input> to file <output> and substitutes variable values referenced
	      in the file content.  If <input> is a relative path it is evaluated with respect to
	      the  current  source  directory.	 The <input> must be a file, not a directory.  If
	      <output> is a relative path it is evaluated with	respect  to  the  current  binary
	      directory.   If  <output>  names	an existing directory the input file is placed in
	      that directory with its original name.

	      If the <input> file is modified the build system will re-run CMake to  re-configure
	      the file and generate the build system again.

	      This command replaces any variables in the input file referenced as ${VAR} or @VAR@
	      with their values as determined by CMake.  If a variable is not defined, it will be
	      replaced	with  nothing.	If COPYONLY is specified, then no variable expansion will
	      take place.  If ESCAPE_QUOTES is specified then  any  substituted  quotes  will  be
	      C-style  escaped.   The  file  will  be configured with the current values of CMake
	      variables. If @ONLY is specified, only variables of the form @VAR@ will be replaced
	      and  ${VAR}  will  be  ignored.	This  is  useful for configuring scripts that use
	      ${VAR}.

	      Input file lines of the form "#cmakedefine VAR ..." will be  replaced  with  either
	      "#define VAR ..." or "/* #undef VAR */" depending on whether VAR is set in CMake to
	      any value not considered a false constant by the if() command. (Content  of  "...",
	      if  any,	is processed as above.) Input file lines of the form "#cmakedefine01 VAR"
	      will be replaced with either "#define VAR 1" or "#define VAR 0" similarly.

	      With NEWLINE_STYLE the line ending could be adjusted:

		  'UNIX' or 'LF' for \n, 'DOS', 'WIN32' or 'CRLF' for \r\n.

	      COPYONLY must not be used with NEWLINE_STYLE.

       create_test_sourcelist
	      Create a test driver and source list for building test programs.

		create_test_sourcelist(sourceListName driverName
				       test1 test2 test3
				       EXTRA_INCLUDE include.h
				       FUNCTION function)

	      A test driver is a program that links together many small tests into a single  exe-
	      cutable.	 This  is useful when building static executables with large libraries to
	      shrink the total required size.  The list of source files needed to build the  test
	      driver  will  be in sourceListName.  DriverName is the name of the test driver pro-
	      gram.  The rest of the arguments consist of a list of test  source  files,  can  be
	      semicolon  separated.   Each  test source file should have a function in it that is
	      the same name as the file with no  extension  (foo.cxx  should  have  int  foo(int,
	      char*[]);) DriverName will be able to call each of the tests by name on the command
	      line. If EXTRA_INCLUDE is specified, then the next argument is  included	into  the
	      generated  file.	If  FUNCTION  is  specified, then the next argument is taken as a
	      function name that is passed a pointer to ac and av.  This can be used to add extra
	      command	line   processing   to	 each	test.	The  cmake  variable  CMAKE_TEST-
	      DRIVER_BEFORE_TESTMAIN can be set to have code that will be placed directly  before
	      calling  the  test  main	function.   CMAKE_TESTDRIVER_AFTER_TESTMAIN can be set to
	      have code that will be placed directly after the call to the test main function.

       define_property
	      Define and document custom properties.

		define_property(<GLOBAL | DIRECTORY | TARGET | SOURCE |
				 TEST | VARIABLE | CACHED_VARIABLE>
				 PROPERTY <name> [INHERITED]
				 BRIEF_DOCS <brief-doc> [docs...]
				 FULL_DOCS <full-doc> [docs...])

	      Define one property in a scope for use with the set_property and get_property  com-
	      mands.   This  is  primarily  useful to associate documentation with property names
	      that may be retrieved with the get_property command.  The first argument determines
	      the kind of scope in which the property should be used.  It must be one of the fol-
	      lowing:

		GLOBAL	  = associated with the global namespace
		DIRECTORY = associated with one directory
		TARGET	  = associated with one target
		SOURCE	  = associated with one source file
		TEST	  = associated with a test named with add_test
		VARIABLE  = documents a CMake language variable
		CACHED_VARIABLE = documents a CMake cache variable

	      Note that unlike set_property and get_property no actual scope needs to  be  given;
	      only the kind of scope is important.

	      The  required  PROPERTY  option is immediately followed by the name of the property
	      being defined.

	      If the INHERITED option then the get_property command will chain	up  to	the  next
	      higher  scope when the requested property is not set in the scope given to the com-
	      mand.  DIRECTORY scope chains to GLOBAL.	TARGET, SOURCE, and TEST chain to  DIREC-
	      TORY.

	      The  BRIEF_DOCS and FULL_DOCS options are followed by strings to be associated with
	      the property as its brief and full documentation.   Corresponding  options  to  the
	      get_property command will retrieve the documentation.

       else   Starts the else portion of an if block.

		else(expression)

	      See the if command.

       elseif Starts the elseif portion of an if block.

		elseif(expression)

	      See the if command.

       enable_language
	      Enable a language (CXX/C/Fortran/etc)

		enable_language(languageName [OPTIONAL] )

	      This  command  enables support for the named language in CMake. This is the same as
	      the project command but does not create any of the extra variables that are created
	      by the project command. Example languages are CXX, C, Fortran. If OPTIONAL is used,
	      use the CMAKE_<languageName>_COMPILER_WORKS variable to check whether the  language
	      has been enabled successfully.

	      This  command must be called on file scope (not inside a function) and the language
	      enabled can only be used in the calling project  or  its	subdirectories	added  by
	      add_subdirectory(). Also note that at present, the OPTIONAL argument does not work.

       enable_testing
	      Enable testing for current directory and below.

		enable_testing()

	      Enables testing for this directory and below.  See also the add_test command.  Note
	      that ctest expects to find a test file in the  build  directory  root.   Therefore,
	      this command should be in the source directory root.

       endforeach
	      Ends a list of commands in a FOREACH block.

		endforeach(expression)

	      See the FOREACH command.

       endfunction
	      Ends a list of commands in a function block.

		endfunction(expression)

	      See the function command.

       endif  Ends a list of commands in an if block.

		endif(expression)

	      See the if command.

       endmacro
	      Ends a list of commands in a macro block.

		endmacro(expression)

	      See the macro command.

       endwhile
	      Ends a list of commands in a while block.

		endwhile(expression)

	      See the while command.

       execute_process
	      Execute one or more child processes.

		execute_process(COMMAND <cmd1> [args1...]]
				[COMMAND <cmd2> [args2...] [...]]
				[WORKING_DIRECTORY <directory>]
				[TIMEOUT <seconds>]
				[RESULT_VARIABLE <variable>]
				[OUTPUT_VARIABLE <variable>]
				[ERROR_VARIABLE <variable>]
				[INPUT_FILE <file>]
				[OUTPUT_FILE <file>]
				[ERROR_FILE <file>]
				[OUTPUT_QUIET]
				[ERROR_QUIET]
				[OUTPUT_STRIP_TRAILING_WHITESPACE]
				[ERROR_STRIP_TRAILING_WHITESPACE])

	      Runs  the  given	sequence of one or more commands with the standard output of each
	      process piped to the standard input of the next.	A single standard error  pipe  is
	      used  for all processes.	If WORKING_DIRECTORY is given the named directory will be
	      set as the current working directory of the child processes.  If TIMEOUT	is  given
	      the  child processes will be terminated if they do not finish in the specified num-
	      ber of seconds (fractions are allowed).  If RESULT_VARIABLE is given  the  variable
	      will  be set to contain the result of running the processes.  This will be an inte-
	      ger return code from the last child or a string describing an error condition.   If
	      OUTPUT_VARIABLE or ERROR_VARIABLE are given the variable named will be set with the
	      contents of the standard output and standard error pipes respectively.  If the same
	      variable is named for both pipes their output will be merged in the order produced.
	      If INPUT_FILE, OUTPUT_FILE, or ERROR_FILE is given the file named will be  attached
	      to the standard input of the first process, standard output of the last process, or
	      standard error of all processes respectively.  If OUTPUT_QUIET  or  ERROR_QUIET  is
	      given  then  the standard output or standard error results will be quietly ignored.
	      If more than one OUTPUT_* or ERROR_* option is given for the same pipe  the  prece-
	      dence  is  not  specified.   If no OUTPUT_* or ERROR_* options are given the output
	      will be shared with the corresponding pipes of the CMake process itself.

	      The execute_process command is a newer more powerful version of  exec_program,  but
	      the old command has been kept for compatibility.

       export Export targets from the build tree for use by outside projects.

		export(TARGETS [target1 [target2 [...]]] [NAMESPACE <namespace>]
		       [APPEND] FILE <filename>)

	      Create a file <filename> that may be included by outside projects to import targets
	      from the current project's build tree.  This is useful  during  cross-compiling  to
	      build utility executables that can run on the host platform in one project and then
	      import them into another project being compiled for the target  platform.   If  the
	      NAMESPACE  option  is  given the <namespace> string will be prepended to all target
	      names written to the file.  If the APPEND option is given the generated  code  will
	      be appended to the file instead of overwriting it.  If a library target is included
	      in the export but a target to which it  links  is  not  included	the  behavior  is
	      unspecified.

	      The  file created by this command is specific to the build tree and should never be
	      installed.  See the install(EXPORT) command to export targets from an  installation
	      tree.

	      Do not set properties that affect the location of a target after passing it to this
	      command.	 These	include  properties  whose  names   match   "(RUNTIME|LIBRARY|AR-
	      CHIVE)_OUTPUT_(NAME|DIRECTORY)(_<CONFIG>)?",     "(IMPLIB_)?(PREFIX|SUFFIX)",    or
	      "LINKER_LANGUAGE".  Failure to follow this rule is not  diagnosed  and  leaves  the
	      location of the target undefined.

		export(PACKAGE <name>)

	      Store  the  current  build directory in the CMake user package registry for package
	      <name>.  The find_package command may consider the directory  while  searching  for
	      package <name>.  This helps dependent projects find and use a package from the cur-
	      rent project's build tree without help from the user.  Note that the entry  in  the
	      package registry that this command creates works only in conjunction with a package
	      configuration file (<name>Config.cmake) that works with the build tree.

       file   File manipulation command.

		file(WRITE filename "message to write"... )
		file(APPEND filename "message to write"... )
		file(READ filename variable [LIMIT numBytes] [OFFSET offset] [HEX])
		file(<MD5|SHA1|SHA224|SHA256|SHA384|SHA512> filename variable)
		file(STRINGS filename variable [LIMIT_COUNT num]
		     [LIMIT_INPUT numBytes] [LIMIT_OUTPUT numBytes]
		     [LENGTH_MINIMUM numBytes] [LENGTH_MAXIMUM numBytes]
		     [NEWLINE_CONSUME] [REGEX regex]
		     [NO_HEX_CONVERSION])
		file(GLOB variable [RELATIVE path] [globbing expressions]...)
		file(GLOB_RECURSE variable [RELATIVE path]
		     [FOLLOW_SYMLINKS] [globbing expressions]...)
		file(RENAME <oldname> <newname>)
		file(REMOVE [file1 ...])
		file(REMOVE_RECURSE [file1 ...])
		file(MAKE_DIRECTORY [directory1 directory2 ...])
		file(RELATIVE_PATH variable directory file)
		file(TO_CMAKE_PATH path result)
		file(TO_NATIVE_PATH path result)
		file(DOWNLOAD url file [INACTIVITY_TIMEOUT timeout]
		     [TIMEOUT timeout] [STATUS status] [LOG log] [SHOW_PROGRESS]
		     [EXPECTED_HASH ALGO=value] [EXPECTED_MD5 sum]
		     [TLS_VERIFY on|off] [TLS_CAINFO file])
		file(UPLOAD filename url [INACTIVITY_TIMEOUT timeout]
		     [TIMEOUT timeout] [STATUS status] [LOG log] [SHOW_PROGRESS])
		file(TIMESTAMP filename variable [<format string>] [UTC])

	      WRITE will write a message into a file called 'filename'. It overwrites the file if
	      it  already  exists,  and  creates the file if it does not exist. (If the file is a
	      build input, use configure_file to update the file only when its content changes.)

	      APPEND will write a message into a file same as WRITE, except it will append it  to
	      the end of the file

	      READ  will read the content of a file and store it into the variable. It will start
	      at the given offset and read up to numBytes. If the  argument  HEX  is  given,  the
	      binary data will be converted to hexadecimal representation and this will be stored
	      in the variable.

	      MD5, SHA1, SHA224, SHA256, SHA384, and SHA512 will compute a cryptographic hash  of
	      the content of a file.

	      STRINGS  will parse a list of ASCII strings from a file and store it in a variable.
	      Binary data in the file are ignored. Carriage return (CR) characters  are  ignored.
	      It  works  also  for Intel Hex and Motorola S-record files, which are automatically
	      converted to binary format when reading them. Disable this using NO_HEX_CONVERSION.

	      LIMIT_COUNT sets the maximum number of strings to return. LIMIT_INPUT sets the max-
	      imum  number  of	bytes  to read from the input file. LIMIT_OUTPUT sets the maximum
	      number of bytes to store in the output variable. LENGTH_MINIMUM  sets  the  minimum
	      length  of a string to return. Shorter strings are ignored. LENGTH_MAXIMUM sets the
	      maximum length of a string to return.  Longer strings are  split	into  strings  no
	      longer  than  the maximum length. NEWLINE_CONSUME allows newlines to be included in
	      strings instead of terminating them.

	      REGEX specifies a regular expression that a string must match to be returned. Typi-
	      cal usage

		file(STRINGS myfile.txt myfile)

	      stores  a list in the variable "myfile" in which each item is a line from the input
	      file.

	      GLOB will generate a list of all files that  match  the  globbing  expressions  and
	      store  it  into  the  variable. Globbing expressions are similar to regular expres-
	      sions, but much simpler. If RELATIVE flag  is  specified	for  an  expression,  the
	      results  will  be returned as a relative path to the given path.	(We do not recom-
	      mend using GLOB to collect a list of source files from your  source  tree.   If  no
	      CMakeLists.txt  file  changes  when a source is added or removed then the generated
	      build system cannot know when to ask CMake to regenerate.)

	      Examples of globbing expressions include:

		 *.cxx	    - match all files with extension cxx
		 *.vt?	    - match all files with extension vta,...,vtz
		 f[3-5].txt - match files f3.txt, f4.txt, f5.txt

	      GLOB_RECURSE will generate a list similar to the regular GLOB, except it will  tra-
	      verse  all  the subdirectories of the matched directory and match the files. Subdi-
	      rectories that are symlinks are only traversed if FOLLOW_SYMLINKS is given or cmake
	      policy CMP0009 is not set to NEW. See cmake --help-policy CMP0009 for more informa-
	      tion.

	      Examples of recursive globbing include:

		 /dir/*.py  - match all python files in /dir and subdirectories

	      MAKE_DIRECTORY will create the given directories, also if their parent  directories
	      don't exist yet

	      RENAME  moves  a	file  or directory within a filesystem, replacing the destination
	      atomically.

	      REMOVE will remove the given files, also in subdirectories

	      REMOVE_RECURSE will remove the given files and directories, also non-empty directo-
	      ries

	      RELATIVE_PATH will determine relative path from directory to the given file.

	      TO_CMAKE_PATH will convert path into a cmake style path with unix /.  The input can
	      be a single path or a system path like "$ENV{PATH}".  Note the double quotes around
	      the ENV call TO_CMAKE_PATH only takes  one argument. This command will also convert
	      the native list delimiters for a list of paths like the PATH environment variable.

	      TO_NATIVE_PATH works just like TO_CMAKE_PATH, but will convert from  a cmake  style
	      path into the native path style \ for windows and / for UNIX.

	      DOWNLOAD	will  download the given URL to the given file. If LOG var is specified a
	      log of the download will be put in var. If STATUS var is specified  the  status  of
	      the operation will be put in var. The status is returned in a list of length 2. The
	      first element is the numeric return value for the operation, and the second element
	      is a string value for the error. A 0 numeric error means no error in the operation.
	      If TIMEOUT time is specified, the operation will timeout after time  seconds,  time
	      should be specified as an integer. The INACTIVITY_TIMEOUT specifies an integer num-
	      ber of seconds of  inactivity  after  which  the	operation  should  terminate.  If
	      EXPECTED_HASH  ALGO=value  is  specified,  the operation will verify that the down-
	      loaded file's actual hash matches the expected value, where ALGO	is  one  of  MD5,
	      SHA1, SHA224, SHA256, SHA384, or SHA512.	If it does not match, the operation fails
	      with an error. ("EXPECTED_MD5 sum" is short-hand for "EXPECTED_HASH  MD5=sum".)  If
	      SHOW_PROGRESS is specified, progress information will be printed as status messages
	      until the operation is complete. For https URLs CMake must be built  with  OpenSSL.
	      TLS/SSL  certificates  are  not  checked by default.  Set TLS_VERIFY to ON to check
	      certificates and/or use EXPECTED_HASH to verify downloaded content.  Set TLS_CAINFO
	      to  specify a custom Certificate Authority file.	If either TLS option is not given
	      CMake will check variables CMAKE_TLS_VERIFY and CMAKE_TLS_CAINFO, respectively.

	      UPLOAD will upload the given file to the given URL. If LOG var is specified  a  log
	      of  the  upload  will  be  put in var. If STATUS var is specified the status of the
	      operation will be put in var. The status is returned in a list  of  length  2.  The
	      first element is the numeric return value for the operation, and the second element
	      is a string value for the error. A 0 numeric error means no error in the operation.
	      If  TIMEOUT  time is specified, the operation will timeout after time seconds, time
	      should be specified as an integer. The INACTIVITY_TIMEOUT specifies an integer num-
	      ber  of  seconds	of  inactivity	after  which  the  operation should terminate. If
	      SHOW_PROGRESS is specified, progress information will be printed as status messages
	      until the operation is complete.

	      TIMESTAMP  will  write a string representation of the modification time of filename
	      to variable.

	      Should the command be unable to obtain a timestamp variable  will  be  set  to  the
	      empty string "".

	      See documentation of the string TIMESTAMP sub-command for more details.

	      The file() command also provides COPY and INSTALL signatures:

		file(<COPY|INSTALL> files... DESTINATION <dir>
		     [FILE_PERMISSIONS permissions...]
		     [DIRECTORY_PERMISSIONS permissions...]
		     [NO_SOURCE_PERMISSIONS] [USE_SOURCE_PERMISSIONS]
		     [FILES_MATCHING]
		     [[PATTERN <pattern> | REGEX <regex>]
		      [EXCLUDE] [PERMISSIONS permissions...]] [...])

	      The COPY signature copies files, directories, and symlinks to a destination folder.
	      Relative input paths are evaluated with respect to the  current  source  directory,
	      and  a  relative	destination is evaluated with respect to the current build direc-
	      tory.  Copying preserves input file timestamps, and optimizes  out  a  file  if  it
	      exists at the destination with the same timestamp.  Copying preserves input permis-
	      sions unless explicit permissions or NO_SOURCE_PERMISSIONS are  given  (default  is
	      USE_SOURCE_PERMISSIONS).	 See  the install(DIRECTORY) command for documentation of
	      permissions, PATTERN, REGEX, and EXCLUDE options.

	      The INSTALL signature differs slightly from COPY: it prints  status  messages,  and
	      NO_SOURCE_PERMISSIONS  is default.  Installation scripts generated by the install()
	      command use this signature (with some undocumented options for internal use).

       find_file
	      Find the full path to a file.

		 find_file(<VAR> name1 [path1 path2 ...])

	      This is the short-hand signature for the command that is sufficient in many  cases.
	      It is the same as find_file(<VAR> name1 [PATHS path1 path2 ...])

		 find_file(
			   <VAR>
			   name | NAMES name1 [name2 ...]
			   [HINTS path1 [path2 ... ENV var]]
			   [PATHS path1 [path2 ... ENV var]]
			   [PATH_SUFFIXES suffix1 [suffix2 ...]]
			   [DOC "cache documentation string"]
			   [NO_DEFAULT_PATH]
			   [NO_CMAKE_ENVIRONMENT_PATH]
			   [NO_CMAKE_PATH]
			   [NO_SYSTEM_ENVIRONMENT_PATH]
			   [NO_CMAKE_SYSTEM_PATH]
			   [CMAKE_FIND_ROOT_PATH_BOTH |
			    ONLY_CMAKE_FIND_ROOT_PATH |
			    NO_CMAKE_FIND_ROOT_PATH]
			  )

	      This  command  is  used  to  find a full path to named file. A cache entry named by
	      <VAR> is created to store the result of this command.  If the full path to  a  file
	      is  found  the result is stored in the variable and the search will not be repeated
	      unless the variable is cleared.  If nothing is found, the result will be <VAR>-NOT-
	      FOUND,  and  the	search will be attempted again the next time find_file is invoked
	      with the same variable.  The name of the full path to a file that is  searched  for
	      is  specified  by  the  names  listed after the NAMES argument.	Additional search
	      locations can be specified after the PATHS argument.  If ENV var is  found  in  the
	      HINTS or PATHS section the environment variable var will be read and converted from
	      a system environment variable to a cmake style list of paths.  For example ENV PATH
	      would  be  a  way  to list the system path variable. The argument after DOC will be
	      used for the documentation string in the cache.  PATH_SUFFIXES specifies additional
	      subdirectories to check below each search path.

	      If  NO_DEFAULT_PATH is specified, then no additional paths are added to the search.
	      If NO_DEFAULT_PATH is not specified, the search process is as follows:

	      1. Search paths specified in cmake-specific cache variables.  These are intended to
	      be  used	on  the  command  line	with  a  -DVAR=value.	This  can  be  skipped if
	      NO_CMAKE_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

	      2. Search paths specified  in  cmake-specific  environment  variables.   These  are
	      intended	to  be	set  in  the  user's shell configuration.  This can be skipped if
	      NO_CMAKE_ENVIRONMENT_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

	      3. Search the paths specified by the HINTS option.  These should be paths  computed
	      by  system  introspection,  such as a hint provided by the location of another item
	      already found.  Hard-coded guesses should be specified with the PATHS option.

	      4. Search the standard system environment variables. This can be skipped if NO_SYS-
	      TEM_ENVIRONMENT_PATH is an argument.

		 PATH
		 INCLUDE

	      5.  Search  cmake  variables  defined in the Platform files for the current system.
	      This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

	      6. Search the paths specified by the PATHS option or in the short-hand  version  of
	      the command.  These are typically hard-coded guesses.

	      On   Darwin   or	 systems   supporting	OS   X	Frameworks,  the  cmake  variable
	      CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

		 "FIRST"  - Try to find frameworks before standard
			    libraries or headers. This is the default on Darwin.
		 "LAST"   - Try to find frameworks after standard
			    libraries or headers.
		 "ONLY"   - Only try to find frameworks.
		 "NEVER" - Never try to find frameworks.

	      On Darwin or systems supporting  OS  X  Application  Bundles,  the  cmake  variable
	      CMAKE_FIND_APPBUNDLE can be set to empty or one of the following:

		 "FIRST"  - Try to find application bundles before standard
			    programs. This is the default on Darwin.
		 "LAST"   - Try to find application bundles after standard
			    programs.
		 "ONLY"   - Only try to find application bundles.
		 "NEVER" - Never try to find application bundles.

	      The  CMake  variable  CMAKE_FIND_ROOT_PATH  specifies one or more directories to be
	      prepended to all other search directories. This effectively "re-roots"  the  entire
	      search  under given locations. By default it is empty. It is especially useful when
	      cross-compiling to point to the root directory of the target environment and  CMake
	      will   search   there   too.   By  default  at  first  the  directories  listed  in
	      CMAKE_FIND_ROOT_PATH and then the non-rooted  directories  will  be  searched.  The
	      default  behavior  can  be  adjusted  by setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE.
	      This  behavior  can  be  manually  overridden  on  a  per-call  basis.   By   using
	      CMAKE_FIND_ROOT_PATH_BOTH   the  search  order  will  be	as  described  above.  If
	      NO_CMAKE_FIND_ROOT_PATH is used then CMAKE_FIND_ROOT_PATH  will  not  be	used.  If
	      ONLY_CMAKE_FIND_ROOT_PATH  is  used  then  only  the  re-rooted directories will be
	      searched.

	      The default search order is designed to be most-specific to least-specific for com-
	      mon  use cases.  Projects may override the order by simply calling the command mul-
	      tiple times and using the NO_* options:

		 find_file(<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
		 find_file(<VAR> NAMES name)

	      Once one of the calls succeeds the result variable will be set and  stored  in  the
	      cache so that no call will search again.

       find_library
	      Find a library.

		 find_library(<VAR> name1 [path1 path2 ...])

	      This  is the short-hand signature for the command that is sufficient in many cases.
	      It is the same as find_library(<VAR> name1 [PATHS path1 path2 ...])

		 find_library(
			   <VAR>
			   name | NAMES name1 [name2 ...] [NAMES_PER_DIR]
			   [HINTS path1 [path2 ... ENV var]]
			   [PATHS path1 [path2 ... ENV var]]
			   [PATH_SUFFIXES suffix1 [suffix2 ...]]
			   [DOC "cache documentation string"]
			   [NO_DEFAULT_PATH]
			   [NO_CMAKE_ENVIRONMENT_PATH]
			   [NO_CMAKE_PATH]
			   [NO_SYSTEM_ENVIRONMENT_PATH]
			   [NO_CMAKE_SYSTEM_PATH]
			   [CMAKE_FIND_ROOT_PATH_BOTH |
			    ONLY_CMAKE_FIND_ROOT_PATH |
			    NO_CMAKE_FIND_ROOT_PATH]
			  )

	      This command is used to find a library. A cache entry named by <VAR> is created  to
	      store  the result of this command.  If the library is found the result is stored in
	      the variable and the search will not be repeated unless the  variable  is  cleared.
	      If  nothing  is  found,  the  result will be <VAR>-NOTFOUND, and the search will be
	      attempted again the next time find_library is invoked with the same variable.   The
	      name of the library that is searched for is specified by the names listed after the
	      NAMES argument.	Additional search locations can  be  specified	after  the  PATHS
	      argument.   If ENV var is found in the HINTS or PATHS section the environment vari-
	      able var will be read and converted from a system environment variable to  a  cmake
	      style  list  of paths.  For example ENV PATH would be a way to list the system path
	      variable. The argument after DOC will be used for the documentation string  in  the
	      cache.   PATH_SUFFIXES  specifies  additional  subdirectories  to  check below each
	      search path.

	      If NO_DEFAULT_PATH is specified, then no additional paths are added to the  search.
	      If NO_DEFAULT_PATH is not specified, the search process is as follows:

	      1. Search paths specified in cmake-specific cache variables.  These are intended to
	      be used  on  the	command  line  with  a	-DVAR=value.   This  can  be  skipped  if
	      NO_CMAKE_PATH is passed.

		 <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_LIBRARY_PATH
		 CMAKE_FRAMEWORK_PATH

	      2.  Search  paths  specified  in	cmake-specific	environment variables.	These are
	      intended to be set in the user's shell  configuration.   This  can  be  skipped  if
	      NO_CMAKE_ENVIRONMENT_PATH is passed.

		 <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_LIBRARY_PATH
		 CMAKE_FRAMEWORK_PATH

	      3.  Search the paths specified by the HINTS option.  These should be paths computed
	      by system introspection, such as a hint provided by the location	of  another  item
	      already found.  Hard-coded guesses should be specified with the PATHS option.

	      4. Search the standard system environment variables. This can be skipped if NO_SYS-
	      TEM_ENVIRONMENT_PATH is an argument.

		 PATH
		 LIB

	      5. Search cmake variables defined in the Platform files  for  the  current  system.
	      This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.

		 <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/lib for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_LIBRARY_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

	      6.  Search  the paths specified by the PATHS option or in the short-hand version of
	      the command.  These are typically hard-coded guesses.

	      On  Darwin  or  systems  supporting   OS	 X   Frameworks,   the	 cmake	 variable
	      CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

		 "FIRST"  - Try to find frameworks before standard
			    libraries or headers. This is the default on Darwin.
		 "LAST"   - Try to find frameworks after standard
			    libraries or headers.
		 "ONLY"   - Only try to find frameworks.
		 "NEVER" - Never try to find frameworks.

	      On  Darwin  or  systems  supporting  OS  X  Application Bundles, the cmake variable
	      CMAKE_FIND_APPBUNDLE can be set to empty or one of the following:

		 "FIRST"  - Try to find application bundles before standard
			    programs. This is the default on Darwin.
		 "LAST"   - Try to find application bundles after standard
			    programs.
		 "ONLY"   - Only try to find application bundles.
		 "NEVER" - Never try to find application bundles.

	      The CMake variable CMAKE_FIND_ROOT_PATH specifies one or	more  directories  to  be
	      prepended  to  all other search directories. This effectively "re-roots" the entire
	      search under given locations. By default it is empty. It is especially useful  when
	      cross-compiling  to point to the root directory of the target environment and CMake
	      will  search  there  too.  By  default  at  first   the	directories   listed   in
	      CMAKE_FIND_ROOT_PATH  and  then  the  non-rooted	directories will be searched. The
	      default behavior can  be	adjusted  by  setting  CMAKE_FIND_ROOT_PATH_MODE_LIBRARY.
	      This   behavior	can  be  manually  overridden  on  a  per-call	basis.	By  using
	      CMAKE_FIND_ROOT_PATH_BOTH  the  search  order  will  be  as  described  above.   If
	      NO_CMAKE_FIND_ROOT_PATH  is  used  then  CMAKE_FIND_ROOT_PATH  will not be used. If
	      ONLY_CMAKE_FIND_ROOT_PATH is used then  only  the  re-rooted  directories  will  be
	      searched.

	      The default search order is designed to be most-specific to least-specific for com-
	      mon use cases.  Projects may override the order by simply calling the command  mul-
	      tiple times and using the NO_* options:

		 find_library(<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
		 find_library(<VAR> NAMES name)

	      Once  one  of  the calls succeeds the result variable will be set and stored in the
	      cache so that no call will search again.

	      When more than one value is given to the NAMES option this command by default  will
	      consider	one  name at a time and search every directory for it.	The NAMES_PER_DIR
	      option tells this command to consider one directory at a time and  search  for  all
	      names in it.

	      If  the  library found is a framework, then VAR will be set to the full path to the
	      framework <fullPath>/A.framework. When a full path to a  framework  is  used  as	a
	      library, CMake will use a -framework A, and a -F<fullPath> to link the framework to
	      the target.

	      If the global property FIND_LIBRARY_USE_LIB64_PATHS is set all search paths will be
	      tested as normal, with "64/" appended, and with all matches of "lib/" replaced with
	      "lib64/". This property is automatically set for the platforms that  are	known  to
	      need  it	if  at	least  one  of	the languages supported by the PROJECT command is
	      enabled.

       find_package
	      Load settings for an external project.

		find_package(<package> [version] [EXACT] [QUIET] [MODULE]
			     [REQUIRED] [[COMPONENTS] [components...]]
			     [OPTIONAL_COMPONENTS components...]
			     [NO_POLICY_SCOPE])

	      Finds and loads settings from an external project.  <package>_FOUND will be set  to
	      indicate whether the package was found.  When the package is found package-specific
	      information is provided through variables and imported targets  documented  by  the
	      package itself.  The QUIET option disables messages if the package cannot be found.
	      The MODULE option disables the second signature  documented  below.   The  REQUIRED
	      option stops processing with an error message if the package cannot be found.

	      A  package-specific  list of required components may be listed after the COMPONENTS
	      option (or after the REQUIRED option if present).  Additional  optional  components
	      may  be listed after OPTIONAL_COMPONENTS.  Available components and their influence
	      on whether a package is considered to be found are defined by the target package.

	      The [version] argument requests a version with which the package	found  should  be
	      compatible  (format  is  major[.minor[.patch[.tweak]]]).	The EXACT option requests
	      that the version be matched exactly.  If no  [version]  and/or  component  list  is
	      given  to  a recursive invocation inside a find-module, the corresponding arguments
	      are forwarded automatically from the outer call (including the EXACT flag for [ver-
	      sion]).	Version  support is currently provided only on a package-by-package basis
	      (details below).

	      User code should generally look for packages using the above simple signature.  The
	      remainder  of  this  command documentation specifies the full command signature and
	      details of the search process.  Project maintainers wishing to provide a package to
	      be found by this command are encouraged to read on.

	      The  command  has  two  modes  by which it searches for packages: "Module" mode and
	      "Config" mode.  Module mode is available when the command is invoked with the above
	      reduced  signature.   CMake searches for a file called "Find<package>.cmake" in the
	      CMAKE_MODULE_PATH followed by the CMake installation.  If the file is found, it  is
	      read  and  processed by CMake.  It is responsible for finding the package, checking
	      the version, and producing any needed messages.  Many find-modules provide  limited
	      or  no  support  for  versioning;  check the module documentation.  If no module is
	      found and the MODULE option is not given the command proceeds to Config mode.

	      The complete Config mode command signature is:

		find_package(<package> [version] [EXACT] [QUIET]
			     [REQUIRED] [[COMPONENTS] [components...]]
			     [CONFIG|NO_MODULE]
			     [NO_POLICY_SCOPE]
			     [NAMES name1 [name2 ...]]
			     [CONFIGS config1 [config2 ...]]
			     [HINTS path1 [path2 ... ]]
			     [PATHS path1 [path2 ... ]]
			     [PATH_SUFFIXES suffix1 [suffix2 ...]]
			     [NO_DEFAULT_PATH]
			     [NO_CMAKE_ENVIRONMENT_PATH]
			     [NO_CMAKE_PATH]
			     [NO_SYSTEM_ENVIRONMENT_PATH]
			     [NO_CMAKE_PACKAGE_REGISTRY]
			     [NO_CMAKE_BUILDS_PATH]
			     [NO_CMAKE_SYSTEM_PATH]
			     [NO_CMAKE_SYSTEM_PACKAGE_REGISTRY]
			     [CMAKE_FIND_ROOT_PATH_BOTH |
			      ONLY_CMAKE_FIND_ROOT_PATH |
			      NO_CMAKE_FIND_ROOT_PATH])

	      The CONFIG option may be used to skip Module mode explicitly and switch  to  Config
	      mode.   It is synonymous to using NO_MODULE.  Config mode is also implied by use of
	      options not specified in the reduced signature.

	      Config mode attempts to locate a configuration file provided by the package  to  be
	      found.   A  cache  entry called <package>_DIR is created to hold the directory con-
	      taining the file.  By default the command searches for  a  package  with	the  name
	      <package>.  If the NAMES option is given the names following it are used instead of
	      <package>.   The	command  searches  for	a  file  called  "<name>Config.cmake"  or
	      "<lower-case-name>-config.cmake"	for  each  name  specified.  A replacement set of
	      possible configuration file names may be	given  using  the  CONFIGS  option.   The
	      search  procedure  is  specified below.  Once found, the configuration file is read
	      and processed by CMake.  Since the file is provided by the package it already knows
	      the  location  of  package  contents.   The  full path to the configuration file is
	      stored in the cmake variable <package>_CONFIG.

	      All configuration files which have been considered by CMake while searching for  an
	      installation  of	the  package  with an appropriate version are stored in the cmake
	      variable <package>_CONSIDERED_CONFIGS, the associated versions in <package>_CONSID-
	      ERED_VERSIONS.

	      If  the  package	configuration  file  cannot be found CMake will generate an error
	      describing the problem unless the QUIET argument	is  specified.	 If  REQUIRED  is
	      specified and the package is not found a fatal error is generated and the configure
	      step stops executing.  If <package>_DIR has been set to a directory not  containing
	      a configuration file CMake will ignore it and search from scratch.

	      When  the  [version]  argument is given Config mode will only find a version of the
	      package  that  claims  compatibility  with  the  requested   version   (format   is
	      major[.minor[.patch[.tweak]]]).  If the EXACT option is given only a version of the
	      package claiming an exact match of the requested version may be found.  CMake  does
	      not  establish  any convention for the meaning of version numbers.  Package version
	      numbers are checked by "version" files provided by the packages themselves.  For	a
	      candidate  package  configuration file "<config-file>.cmake" the corresponding ver-
	      sion file is located next to it and named either	"<config-file>-version.cmake"  or
	      "<config-file>Version.cmake".   If  no such version file is available then the con-
	      figuration file is assumed to not be compatible  with  any  requested  version.	A
	      basic  version  file  containing generic version matching code can be created using
	      the  macro  write_basic_package_version_file(),  see  its  documentation	for  more
	      details.	 When a version file is found it is loaded to check the requested version
	      number.  The version file is loaded in a nested scope in which the following  vari-
	      ables have been defined:

		PACKAGE_FIND_NAME	   = the <package> name
		PACKAGE_FIND_VERSION	   = full requested version string
		PACKAGE_FIND_VERSION_MAJOR = major version if requested, else 0
		PACKAGE_FIND_VERSION_MINOR = minor version if requested, else 0
		PACKAGE_FIND_VERSION_PATCH = patch version if requested, else 0
		PACKAGE_FIND_VERSION_TWEAK = tweak version if requested, else 0
		PACKAGE_FIND_VERSION_COUNT = number of version components, 0 to 4

	      The  version  file checks whether it satisfies the requested version and sets these
	      variables:

		PACKAGE_VERSION 	   = full provided version string
		PACKAGE_VERSION_EXACT	   = true if version is exact match
		PACKAGE_VERSION_COMPATIBLE = true if version is compatible
		PACKAGE_VERSION_UNSUITABLE = true if unsuitable as any version

	      These variables are checked by the find_package command to  determine  whether  the
	      configuration  file  provides  an acceptable version.  They are not available after
	      the find_package call returns.  If the version is acceptable  the  following  vari-
	      ables are set:

		<package>_VERSION	= full provided version string
		<package>_VERSION_MAJOR = major version if provided, else 0
		<package>_VERSION_MINOR = minor version if provided, else 0
		<package>_VERSION_PATCH = patch version if provided, else 0
		<package>_VERSION_TWEAK = tweak version if provided, else 0
		<package>_VERSION_COUNT = number of version components, 0 to 4

	      and  the corresponding package configuration file is loaded.  When multiple package
	      configuration files are available whose version files claim compatibility with  the
	      version  requested  it  is  unspecified which one is chosen.  No attempt is made to
	      choose a highest or closest version number.

	      Config mode provides an elaborate interface and  search  procedure.   Much  of  the
	      interface  is  provided  for  completeness  and  for use internally by find-modules
	      loaded by Module mode.  Most user code should simply call

		find_package(<package> [major[.minor]] [EXACT] [REQUIRED|QUIET])

	      in order to find a package.  Package maintainers providing CMake package configura-
	      tion files are encouraged to name and install them such that the procedure outlined
	      below will find them without requiring use of additional options.

	      CMake constructs a set of possible installation prefixes for  the  package.   Under
	      each  prefix several directories are searched for a configuration file.  The tables
	      below show the directories searched.  Each entry is meant  for  installation  trees
	      following Windows (W), UNIX (U), or Apple (A) conventions.

		<prefix>/						(W)
		<prefix>/(cmake|CMake)/ 				(W)
		<prefix>/<name>*/					(W)
		<prefix>/<name>*/(cmake|CMake)/ 			(W)
		<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/		(U)
		<prefix>/(lib/<arch>|lib|share)/<name>*/		(U)
		<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/	(U)

	      On  systems supporting OS X Frameworks and Application Bundles the following direc-
	      tories are searched for frameworks or bundles containing a configuration file:

		<prefix>/<name>.framework/Resources/			(A)
		<prefix>/<name>.framework/Resources/CMake/		(A)
		<prefix>/<name>.framework/Versions/*/Resources/ 	(A)
		<prefix>/<name>.framework/Versions/*/Resources/CMake/	(A)
		<prefix>/<name>.app/Contents/Resources/ 		(A)
		<prefix>/<name>.app/Contents/Resources/CMake/		(A)

	      In all cases the <name> is treated as case-insensitive and corresponds  to  any  of
	      the names specified (<package> or names given by NAMES).	Paths with lib/<arch> are
	      enabled if CMAKE_LIBRARY_ARCHITECTURE is set.  If PATH_SUFFIXES  is  specified  the
	      suffixes are appended to each (W) or (U) directory entry one-by-one.

	      This  set of directories is intended to work in cooperation with projects that pro-
	      vide configuration files in their installation  trees.   Directories  above  marked
	      with  (W)  are  intended for installations on Windows where the prefix may point at
	      the top of an application's installation directory.   Those  marked  with  (U)  are
	      intended for installations on UNIX platforms where the prefix is shared by multiple
	      packages.  This is merely a convention, so all (W) and (U)  directories  are  still
	      searched	on all platforms.  Directories marked with (A) are intended for installa-
	      tions  on  Apple	platforms.   The   cmake   variables   CMAKE_FIND_FRAMEWORK   and
	      CMAKE_FIND_APPBUNDLE determine the order of preference as specified below.

	      The  set	of  installation  prefixes  is constructed using the following steps.  If
	      NO_DEFAULT_PATH is specified all NO_* options are enabled.

	      1. Search paths specified in cmake-specific cache variables.  These are intended to
	      be  used	on  the  command  line	with  a  -DVAR=value.	This  can  be  skipped if
	      NO_CMAKE_PATH is passed.

		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

	      2. Search paths specified  in  cmake-specific  environment  variables.   These  are
	      intended	to  be	set  in  the  user's shell configuration.  This can be skipped if
	      NO_CMAKE_ENVIRONMENT_PATH is passed.

		 <package>_DIR
		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

	      3. Search paths specified by the HINTS option.  These should be paths  computed  by
	      system  introspection,  such  as	a  hint  provided by the location of another item
	      already found.  Hard-coded guesses should be specified with the PATHS option.

	      4. Search the standard system environment variables. This can be skipped if NO_SYS-
	      TEM_ENVIRONMENT_PATH is passed.  Path entries ending in "/bin" or "/sbin" are auto-
	      matically converted to their parent directories.

		 PATH

	      5. Search project build trees recently configured in a  CMake  GUI.   This  can  be
	      skipped if NO_CMAKE_BUILDS_PATH is passed.  It is intended for the case when a user
	      is building multiple dependent projects one after another.

	      6. Search paths stored in the CMake user package registry.  This can be skipped  if
	      NO_CMAKE_PACKAGE_REGISTRY  is passed.  On Windows a <package> may appear under reg-
	      istry key

		HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\<package>

	      as a REG_SZ value, with arbitrary name, that specifies the directory containing the
	      package  configuration  file.   On  UNIX platforms a <package> may appear under the
	      directory

		~/.cmake/packages/<package>

	      as a file, with arbitrary name, whose content specifies  the  directory  containing
	      the  package  configuration  file.   See the export(PACKAGE) command to create user
	      package registry entries for project build trees.

	      7. Search cmake variables defined in the Platform files  for  the  current  system.
	      This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.

		 CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH
		 CMAKE_SYSTEM_APPBUNDLE_PATH

	      8.  Search  paths stored in the CMake system package registry.  This can be skipped
	      if NO_CMAKE_SYSTEM_PACKAGE_REGISTRY is passed.  On Windows a <package>  may  appear
	      under registry key

		HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<package>

	      as a REG_SZ value, with arbitrary name, that specifies the directory containing the
	      package configuration file.  There is no system  package	registry  on  non-Windows
	      platforms.

	      9.  Search  paths  specified  by	the PATHS option.  These are typically hard-coded
	      guesses.

	      On  Darwin  or  systems  supporting   OS	 X   Frameworks,   the	 cmake	 variable
	      CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

		 "FIRST"  - Try to find frameworks before standard
			    libraries or headers. This is the default on Darwin.
		 "LAST"   - Try to find frameworks after standard
			    libraries or headers.
		 "ONLY"   - Only try to find frameworks.
		 "NEVER" - Never try to find frameworks.

	      On  Darwin  or  systems  supporting  OS  X  Application Bundles, the cmake variable
	      CMAKE_FIND_APPBUNDLE can be set to empty or one of the following:

		 "FIRST"  - Try to find application bundles before standard
			    programs. This is the default on Darwin.
		 "LAST"   - Try to find application bundles after standard
			    programs.
		 "ONLY"   - Only try to find application bundles.
		 "NEVER" - Never try to find application bundles.

	      The CMake variable CMAKE_FIND_ROOT_PATH specifies one or	more  directories  to  be
	      prepended  to  all other search directories. This effectively "re-roots" the entire
	      search under given locations. By default it is empty. It is especially useful  when
	      cross-compiling  to point to the root directory of the target environment and CMake
	      will  search  there  too.  By  default  at  first   the	directories   listed   in
	      CMAKE_FIND_ROOT_PATH  and  then  the  non-rooted	directories will be searched. The
	      default behavior can  be	adjusted  by  setting  CMAKE_FIND_ROOT_PATH_MODE_PACKAGE.
	      This   behavior	can  be  manually  overridden  on  a  per-call	basis.	By  using
	      CMAKE_FIND_ROOT_PATH_BOTH  the  search  order  will  be  as  described  above.   If
	      NO_CMAKE_FIND_ROOT_PATH  is  used  then  CMAKE_FIND_ROOT_PATH  will not be used. If
	      ONLY_CMAKE_FIND_ROOT_PATH is used then  only  the  re-rooted  directories  will  be
	      searched.

	      The default search order is designed to be most-specific to least-specific for com-
	      mon use cases.  Projects may override the order by simply calling the command  mul-
	      tiple times and using the NO_* options:

		 find_package(<package> PATHS paths... NO_DEFAULT_PATH)
		 find_package(<package>)

	      Once  one  of  the calls succeeds the result variable will be set and stored in the
	      cache so that no call will search again.

	      Every non-REQUIRED find_package() call can be  disabled  by  setting  the  variable
	      CMAKE_DISABLE_FIND_PACKAGE_<package>   to  TRUE.	See  the  documentation  for  the
	      CMAKE_DISABLE_FIND_PACKAGE_<package> variable for more information.

	      When loading a find module or package configuration file find_package defines vari-
	      ables  to provide information about the call arguments (and restores their original
	      state before returning):

	       <package>_FIND_REQUIRED	    = true if REQUIRED option was given
	       <package>_FIND_QUIETLY	    = true if QUIET option was given
	       <package>_FIND_VERSION	    = full requested version string
	       <package>_FIND_VERSION_MAJOR = major version if requested, else 0
	       <package>_FIND_VERSION_MINOR = minor version if requested, else 0
	       <package>_FIND_VERSION_PATCH = patch version if requested, else 0
	       <package>_FIND_VERSION_TWEAK = tweak version if requested, else 0
	       <package>_FIND_VERSION_COUNT = number of version components, 0 to 4
	       <package>_FIND_VERSION_EXACT = true if EXACT option was given
	       <package>_FIND_COMPONENTS    = list of requested components
	       <package>_FIND_REQUIRED_<c>  = true if component <c> is required
					      false if component <c> is optional

	      In Module mode the loaded find module is responsible to honor the request  detailed
	      by  these  variables; see the find module for details.  In Config mode find_package
	      handles REQUIRED, QUIET, and version options automatically but  leaves  it  to  the
	      package  configuration  file to handle components in a way that makes sense for the
	      package.	The package configuration file may set <package>_FOUND to false  to  tell
	      find_package that component requirements are not satisfied.

	      See  the cmake_policy() command documentation for discussion of the NO_POLICY_SCOPE
	      option.

       find_path
	      Find the directory containing a file.

		 find_path(<VAR> name1 [path1 path2 ...])

	      This is the short-hand signature for the command that is sufficient in many  cases.
	      It is the same as find_path(<VAR> name1 [PATHS path1 path2 ...])

		 find_path(
			   <VAR>
			   name | NAMES name1 [name2 ...]
			   [HINTS path1 [path2 ... ENV var]]
			   [PATHS path1 [path2 ... ENV var]]
			   [PATH_SUFFIXES suffix1 [suffix2 ...]]
			   [DOC "cache documentation string"]
			   [NO_DEFAULT_PATH]
			   [NO_CMAKE_ENVIRONMENT_PATH]
			   [NO_CMAKE_PATH]
			   [NO_SYSTEM_ENVIRONMENT_PATH]
			   [NO_CMAKE_SYSTEM_PATH]
			   [CMAKE_FIND_ROOT_PATH_BOTH |
			    ONLY_CMAKE_FIND_ROOT_PATH |
			    NO_CMAKE_FIND_ROOT_PATH]
			  )

	      This  command  is used to find a directory containing the named file. A cache entry
	      named by <VAR> is created to store the result of this command.  If the  file  in	a
	      directory  is found the result is stored in the variable and the search will not be
	      repeated unless the variable is cleared.	If nothing is found, the result  will  be
	      <VAR>-NOTFOUND,  and  the search will be attempted again the next time find_path is
	      invoked with the same variable.  The name of  the  file  in  a  directory  that  is
	      searched	for  is  specified  by the names listed after the NAMES argument.   Addi-
	      tional search locations can be specified after the PATHS argument.  If ENV  var  is
	      found  in  the HINTS or PATHS section the environment variable var will be read and
	      converted from a system environment variable to a cmake style list of  paths.   For
	      example  ENV  PATH  would  be  a way to list the system path variable. The argument
	      after DOC will be used for the documentation string in  the  cache.   PATH_SUFFIXES
	      specifies additional subdirectories to check below each search path.

	      If  NO_DEFAULT_PATH is specified, then no additional paths are added to the search.
	      If NO_DEFAULT_PATH is not specified, the search process is as follows:

	      1. Search paths specified in cmake-specific cache variables.  These are intended to
	      be  used	on  the  command  line	with  a  -DVAR=value.	This  can  be  skipped if
	      NO_CMAKE_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

	      2. Search paths specified  in  cmake-specific  environment  variables.   These  are
	      intended	to  be	set  in  the  user's shell configuration.  This can be skipped if
	      NO_CMAKE_ENVIRONMENT_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

	      3. Search the paths specified by the HINTS option.  These should be paths  computed
	      by  system  introspection,  such as a hint provided by the location of another item
	      already found.  Hard-coded guesses should be specified with the PATHS option.

	      4. Search the standard system environment variables. This can be skipped if NO_SYS-
	      TEM_ENVIRONMENT_PATH is an argument.

		 PATH
		 INCLUDE

	      5.  Search  cmake  variables  defined in the Platform files for the current system.
	      This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

	      6. Search the paths specified by the PATHS option or in the short-hand  version  of
	      the command.  These are typically hard-coded guesses.

	      On   Darwin   or	 systems   supporting	OS   X	Frameworks,  the  cmake  variable
	      CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

		 "FIRST"  - Try to find frameworks before standard
			    libraries or headers. This is the default on Darwin.
		 "LAST"   - Try to find frameworks after standard
			    libraries or headers.
		 "ONLY"   - Only try to find frameworks.
		 "NEVER" - Never try to find frameworks.

	      On Darwin or systems supporting  OS  X  Application  Bundles,  the  cmake  variable
	      CMAKE_FIND_APPBUNDLE can be set to empty or one of the following:

		 "FIRST"  - Try to find application bundles before standard
			    programs. This is the default on Darwin.
		 "LAST"   - Try to find application bundles after standard
			    programs.
		 "ONLY"   - Only try to find application bundles.
		 "NEVER" - Never try to find application bundles.

	      The  CMake  variable  CMAKE_FIND_ROOT_PATH  specifies one or more directories to be
	      prepended to all other search directories. This effectively "re-roots"  the  entire
	      search  under given locations. By default it is empty. It is especially useful when
	      cross-compiling to point to the root directory of the target environment and  CMake
	      will   search   there   too.   By  default  at  first  the  directories  listed  in
	      CMAKE_FIND_ROOT_PATH and then the non-rooted  directories  will  be  searched.  The
	      default  behavior  can  be  adjusted  by setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE.
	      This  behavior  can  be  manually  overridden  on  a  per-call  basis.   By   using
	      CMAKE_FIND_ROOT_PATH_BOTH   the  search  order  will  be	as  described  above.  If
	      NO_CMAKE_FIND_ROOT_PATH is used then CMAKE_FIND_ROOT_PATH  will  not  be	used.  If
	      ONLY_CMAKE_FIND_ROOT_PATH  is  used  then  only  the  re-rooted directories will be
	      searched.

	      The default search order is designed to be most-specific to least-specific for com-
	      mon  use cases.  Projects may override the order by simply calling the command mul-
	      tiple times and using the NO_* options:

		 find_path(<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
		 find_path(<VAR> NAMES name)

	      Once one of the calls succeeds the result variable will be set and  stored  in  the
	      cache so that no call will search again.

	      When  searching  for frameworks, if the file is specified as A/b.h, then the frame-
	      work search will look for A.framework/Headers/b.h. If that is found the  path  will
	      be  set  to  the	path  to the framework. CMake will convert this to the correct -F
	      option to include the file.

       find_program
	      Find an executable program.

		 find_program(<VAR> name1 [path1 path2 ...])

	      This is the short-hand signature for the command that is sufficient in many  cases.
	      It is the same as find_program(<VAR> name1 [PATHS path1 path2 ...])

		 find_program(
			   <VAR>
			   name | NAMES name1 [name2 ...]
			   [HINTS path1 [path2 ... ENV var]]
			   [PATHS path1 [path2 ... ENV var]]
			   [PATH_SUFFIXES suffix1 [suffix2 ...]]
			   [DOC "cache documentation string"]
			   [NO_DEFAULT_PATH]
			   [NO_CMAKE_ENVIRONMENT_PATH]
			   [NO_CMAKE_PATH]
			   [NO_SYSTEM_ENVIRONMENT_PATH]
			   [NO_CMAKE_SYSTEM_PATH]
			   [CMAKE_FIND_ROOT_PATH_BOTH |
			    ONLY_CMAKE_FIND_ROOT_PATH |
			    NO_CMAKE_FIND_ROOT_PATH]
			  )

	      This  command is used to find a program. A cache entry named by <VAR> is created to
	      store the result of this command.  If the program is found the result is stored  in
	      the  variable  and  the search will not be repeated unless the variable is cleared.
	      If nothing is found, the result will be <VAR>-NOTFOUND,  and  the  search  will  be
	      attempted  again the next time find_program is invoked with the same variable.  The
	      name of the program that is searched for is specified by the names listed after the
	      NAMES  argument.	  Additional  search  locations  can be specified after the PATHS
	      argument.  If ENV var is found in the HINTS or PATHS section the environment  vari-
	      able  var  will be read and converted from a system environment variable to a cmake
	      style list of paths.  For example ENV PATH would be a way to list the  system  path
	      variable.  The  argument after DOC will be used for the documentation string in the
	      cache.  PATH_SUFFIXES specifies  additional  subdirectories  to  check  below  each
	      search path.

	      If  NO_DEFAULT_PATH is specified, then no additional paths are added to the search.
	      If NO_DEFAULT_PATH is not specified, the search process is as follows:

	      1. Search paths specified in cmake-specific cache variables.  These are intended to
	      be  used	on  the  command  line	with  a  -DVAR=value.	This  can  be  skipped if
	      NO_CMAKE_PATH is passed.

		 <prefix>/[s]bin for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_PROGRAM_PATH
		 CMAKE_APPBUNDLE_PATH

	      2. Search paths specified  in  cmake-specific  environment  variables.   These  are
	      intended	to  be	set  in  the  user's shell configuration.  This can be skipped if
	      NO_CMAKE_ENVIRONMENT_PATH is passed.

		 <prefix>/[s]bin for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_PROGRAM_PATH
		 CMAKE_APPBUNDLE_PATH

	      3. Search the paths specified by the HINTS option.  These should be paths  computed
	      by  system  introspection,  such as a hint provided by the location of another item
	      already found.  Hard-coded guesses should be specified with the PATHS option.

	      4. Search the standard system environment variables. This can be skipped if NO_SYS-
	      TEM_ENVIRONMENT_PATH is an argument.

		 PATH

	      5.  Search  cmake  variables  defined in the Platform files for the current system.
	      This can be skipped if NO_CMAKE_SYSTEM_PATH is passed.

		 <prefix>/[s]bin for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_PROGRAM_PATH
		 CMAKE_SYSTEM_APPBUNDLE_PATH

	      6. Search the paths specified by the PATHS option or in the short-hand  version  of
	      the command.  These are typically hard-coded guesses.

	      On   Darwin   or	 systems   supporting	OS   X	Frameworks,  the  cmake  variable
	      CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

		 "FIRST"  - Try to find frameworks before standard
			    libraries or headers. This is the default on Darwin.
		 "LAST"   - Try to find frameworks after standard
			    libraries or headers.
		 "ONLY"   - Only try to find frameworks.
		 "NEVER" - Never try to find frameworks.

	      On Darwin or systems supporting  OS  X  Application  Bundles,  the  cmake  variable
	      CMAKE_FIND_APPBUNDLE can be set to empty or one of the following:

		 "FIRST"  - Try to find application bundles before standard
			    programs. This is the default on Darwin.
		 "LAST"   - Try to find application bundles after standard
			    programs.
		 "ONLY"   - Only try to find application bundles.
		 "NEVER" - Never try to find application bundles.

	      The  CMake  variable  CMAKE_FIND_ROOT_PATH  specifies one or more directories to be
	      prepended to all other search directories. This effectively "re-roots"  the  entire
	      search  under given locations. By default it is empty. It is especially useful when
	      cross-compiling to point to the root directory of the target environment and  CMake
	      will   search   there   too.   By  default  at  first  the  directories  listed  in
	      CMAKE_FIND_ROOT_PATH and then the non-rooted  directories  will  be  searched.  The
	      default  behavior  can  be  adjusted  by setting CMAKE_FIND_ROOT_PATH_MODE_PROGRAM.
	      This  behavior  can  be  manually  overridden  on  a  per-call  basis.   By   using
	      CMAKE_FIND_ROOT_PATH_BOTH   the  search  order  will  be	as  described  above.  If
	      NO_CMAKE_FIND_ROOT_PATH is used then CMAKE_FIND_ROOT_PATH  will  not  be	used.  If
	      ONLY_CMAKE_FIND_ROOT_PATH  is  used  then  only  the  re-rooted directories will be
	      searched.

	      The default search order is designed to be most-specific to least-specific for com-
	      mon  use cases.  Projects may override the order by simply calling the command mul-
	      tiple times and using the NO_* options:

		 find_program(<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
		 find_program(<VAR> NAMES name)

	      Once one of the calls succeeds the result variable will be set and  stored  in  the
	      cache so that no call will search again.

       fltk_wrap_ui
	      Create FLTK user interfaces Wrappers.

		fltk_wrap_ui(resultingLibraryName source1
			     source2 ... sourceN )

	      Produce  .h and .cxx files for all the .fl and .fld files listed.  The resulting .h
	      and .cxx files will be added to a variable named	resultingLibraryName_FLTK_UI_SRCS
	      which should be added to your library.

       foreach
	      Evaluate a group of commands for each value in a list.

		foreach(loop_var arg1 arg2 ...)
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		endforeach(loop_var)

	      All commands between foreach and the matching endforeach are recorded without being
	      invoked.	Once the endforeach is	evaluated,  the  recorded  list  of  commands  is
	      invoked once for each argument listed in the original foreach command.  Before each
	      iteration of the loop "${loop_var}" will be set as  a  variable  with  the  current
	      value in the list.

		foreach(loop_var RANGE total)
		foreach(loop_var RANGE start stop [step])

	      Foreach  can  also iterate over a generated range of numbers. There are three types
	      of this iteration:

	      * When specifying single number, the range will have elements 0 to "total".

	      * When specifying two numbers, the range will have elements from the  first  number
	      to the second number.

	      *  The third optional number is the increment used to iterate from the first number
	      to the second number.

		foreach(loop_var IN [LISTS [list1 [...]]]
				    [ITEMS [item1 [...]]])

	      Iterates over a precise list of items.  The LISTS option	names  list-valued  vari-
	      ables  to  be traversed, including empty elements (an empty string is a zero-length
	      list).  The ITEMS option ends argument parsing and includes all arguments following
	      it in the iteration.

       function
	      Start recording a function for later invocation as a command.

		function(<name> [arg1 [arg2 [arg3 ...]]])
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		endfunction(<name>)

	      Define  a  function  named  <name> that takes arguments named arg1 arg2 arg3 (...).
	      Commands listed after function,  but  before  the  matching  endfunction,  are  not
	      invoked  until  the function is invoked.	When it is invoked, the commands recorded
	      in the function are first modified by replacing formal  parameters  (${arg1})  with
	      the arguments passed, and then invoked as normal commands. In addition to referenc-
	      ing the formal parameters you can reference the variable ARGC which will be set  to
	      the  number  of arguments passed into the function as well as ARGV0 ARGV1 ARGV2 ...
	      which will have the actual values of the arguments passed in. This facilitates cre-
	      ating  functions	with  optional arguments. Additionally ARGV holds the list of all
	      arguments given to the function and ARGN holds the list of arguments past the  last
	      expected argument.

	      A function opens a new scope: see set(var PARENT_SCOPE) for details.

	      See  the	cmake_policy()	command documentation for the behavior of policies inside
	      functions.

       get_cmake_property
	      Get a property of the CMake instance.

		get_cmake_property(VAR property)

	      Get a property from the CMake instance.  The value of the property is stored in the
	      variable	VAR.   If the property is not found, VAR will be set to "NOTFOUND".  Some
	      supported properties include: VARIABLES,	CACHE_VARIABLES,  COMMANDS,  MACROS,  and
	      COMPONENTS.

	      See also the more general get_property() command.

       get_directory_property
	      Get a property of DIRECTORY scope.

		get_directory_property(<variable> [DIRECTORY <dir>] <prop-name>)

	      Store  a property of directory scope in the named variable.  If the property is not
	      defined the empty-string is returned.  The  DIRECTORY  argument  specifies  another
	      directory  from which to retrieve the property value.  The specified directory must
	      have already been traversed by CMake.

		get_directory_property(<variable> [DIRECTORY <dir>]
				       DEFINITION <var-name>)

	      Get a variable definition from a directory.  This form is useful to get a  variable
	      definition from another directory.

	      See also the more general get_property() command.

       get_filename_component
	      Get a specific component of a full filename.

		get_filename_component(<VAR> <FileName> <COMP> [CACHE])

	      Set <VAR> to a component of <FileName>, where <COMP> is one of:

	       PATH	 = Directory without file name
	       NAME	 = File name without directory
	       EXT	 = File name longest extension (.b.c from d/a.b.c)
	       NAME_WE	 = File name without directory or longest extension
	       ABSOLUTE  = Full path to file
	       REALPATH  = Full path to existing file with symlinks resolved

	      Paths  are  returned  with forward slashes and have no trailing slahes. The longest
	      file extension is always considered. If the optional CACHE argument  is  specified,
	      the result variable is added to the cache.

		get_filename_component(<VAR> FileName
				       PROGRAM [PROGRAM_ARGS <ARG_VAR>]
				       [CACHE])

	      The  program  in FileName will be found in the system search path or left as a full
	      path.  If PROGRAM_ARGS is present with PROGRAM,  then  any  command-line	arguments
	      present  in  the	FileName  string  are  split  from the program name and stored in
	      <ARG_VAR>.  This is used to separate a program name from its arguments in a command
	      line string.

       get_property
	      Get a property.

		get_property(<variable>
			     <GLOBAL		 |
			      DIRECTORY [dir]	 |
			      TARGET	<target> |
			      SOURCE	<source> |
			      TEST	<test>	 |
			      CACHE	<entry>  |
			      VARIABLE>
			     PROPERTY <name>
			     [SET | DEFINED | BRIEF_DOCS | FULL_DOCS])

	      Get  one	property  from	one  object in a scope.  The first argument specifies the
	      variable in which to store the result.  The second argument  determines  the  scope
	      from which to get the property.  It must be one of the following:

	      GLOBAL scope is unique and does not accept a name.

	      DIRECTORY  scope	defaults  to the current directory but another directory (already
	      processed by CMake) may be named by full or relative path.

	      TARGET scope must name one existing target.

	      SOURCE scope must name one source file.

	      TEST scope must name one existing test.

	      CACHE scope must name one cache entry.

	      VARIABLE scope is unique and does not accept a name.

	      The required PROPERTY option is immediately followed by the name of the property to
	      get.   If the property is not set an empty value is returned.  If the SET option is
	      given the variable is set to a boolean value indicating whether  the  property  has
	      been  set.   If  the DEFINED option is given the variable is set to a boolean value
	      indicating whether the property has been defined such as with  define_property.  If
	      BRIEF_DOCS  or  FULL_DOCS  is given then the variable is set to a string containing
	      documentation for the requested property.  If  documentation  is	requested  for	a
	      property that has not been defined NOTFOUND is returned.

       get_source_file_property
	      Get a property for a source file.

		get_source_file_property(VAR file property)

	      Get  a  property	from  a  source file.  The value of the property is stored in the
	      variable VAR.  If the property is not found, VAR will be	set  to  "NOTFOUND".  Use
	      set_source_files_properties to set property values.  Source file properties usually
	      control how the file is built. One property that is always there is LOCATION

	      See also the more general get_property() command.

       get_target_property
	      Get a property from a target.

		get_target_property(VAR target property)

	      Get a property from a target.   The value of the property is stored in the variable
	      VAR.   If  the  property is not found, VAR will be set to "NOTFOUND".  Use set_tar-
	      get_properties to set property values.  Properties are usually used to control  how
	      a target is built, but some query the target instead.  This command can get proper-
	      ties for any target so far created. The targets do not need to be  in  the  current
	      CMakeLists.txt file.

	      See also the more general get_property() command.

       get_test_property
	      Get a property of the test.

		get_test_property(test property VAR)

	      Get  a property from the Test.  The value of the property is stored in the variable
	      VAR.  If the property is not found, VAR will be set to "NOTFOUND". For  a  list  of
	      standard properties you can type cmake --help-property-list

	      See also the more general get_property() command.

       if     Conditionally execute a group of commands.

		if(expression)
		  # then section.
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		elseif(expression2)
		  # elseif section.
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		else(expression)
		  # else section.
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		endif(expression)

	      Evaluates  the  given  expression.  If the result is true, the commands in the THEN
	      section are invoked.  Otherwise, the commands in the else section are invoked.  The
	      elseif  and  else sections are optional. You may have multiple elseif clauses. Note
	      that the expression in the else and endif clause is optional. Long expressions  can
	      be  used	and there is a traditional order of precedence. Parenthetical expressions
	      are evaluated first followed by  unary  operators  such  as  EXISTS,  COMMAND,  and
	      DEFINED. Then any EQUAL, LESS, GREATER, STRLESS, STRGREATER, STREQUAL, MATCHES will
	      be evaluated. Then NOT operators and finally AND, OR operators will  be  evaluated.
	      Possible expressions are:

		if(<constant>)

	      True  if	the  constant is 1, ON, YES, TRUE, Y, or a non-zero number.  False if the
	      constant is 0, OFF, NO, FALSE, N, IGNORE, NOTFOUND,  '',	or  ends  in  the  suffix
	      '-NOTFOUND'.  Named boolean constants are case-insensitive.  If the argument is not
	      one of these constants, it is treated as a variable:

		if(<variable>)

	      True if the variable is defined to a value that is not  a  false	constant.   False
	      otherwise.  (Note macro arguments are not variables.)

		if(NOT <expression>)

	      True if the expression is not true.

		if(<expr1> AND <expr2>)

	      True if both expressions would be considered true individually.

		if(<expr1> OR <expr2>)

	      True if either expression would be considered true individually.

		if(COMMAND command-name)

	      True if the given name is a command, macro or function that can be invoked.

		if(POLICY policy-id)

	      True if the given name is an existing policy (of the form CMP<NNNN>).

		if(TARGET target-name)

	      True if the given name is an existing target, built or imported.

		if(EXISTS file-name)
		if(EXISTS directory-name)

	      True if the named file or directory exists.  Behavior is well-defined only for full
	      paths.

		if(file1 IS_NEWER_THAN file2)

	      True if file1 is newer than file2 or if one of the two files doesn't exist.  Behav-
	      ior  is  well-defined  only for full paths. If the file time stamps are exactly the
	      same, an IS_NEWER_THAN comparison returns true, so that any dependent build  opera-
	      tions  will occur in the event of a tie. This includes the case of passing the same
	      file name for both file1 and file2.

		if(IS_DIRECTORY directory-name)

	      True if the given name is a directory.  Behavior	is  well-defined  only	for  full
	      paths.

		if(IS_SYMLINK file-name)

	      True  if the given name is a symbolic link.  Behavior is well-defined only for full
	      paths.

		if(IS_ABSOLUTE path)

	      True if the given path is an absolute path.

		if(<variable|string> MATCHES regex)

	      True if the given string or variable's value matches the given regular expression.

		if(<variable|string> LESS <variable|string>)
		if(<variable|string> GREATER <variable|string>)
		if(<variable|string> EQUAL <variable|string>)

	      True if the given string or variable's value is a valid number and  the  inequality
	      or equality is true.

		if(<variable|string> STRLESS <variable|string>)
		if(<variable|string> STRGREATER <variable|string>)
		if(<variable|string> STREQUAL <variable|string>)

	      True if the given string or variable's value is lexicographically less (or greater,
	      or equal) than the string or variable on the right.

		if(<variable|string> VERSION_LESS <variable|string>)
		if(<variable|string> VERSION_EQUAL <variable|string>)
		if(<variable|string> VERSION_GREATER <variable|string>)

	      Component-wise   integer	 version   number   comparison	 (version    format    is
	      major[.minor[.patch[.tweak]]]).

		if(DEFINED <variable>)

	      True  if	the given variable is defined. It does not matter if the variable is true
	      or false just if it has been set.

		if((expression) AND (expression OR (expression)))

	      The expressions inside the parenthesis are evaluated first and then  the	remaining
	      expression  is evaluated as in the previous examples. Where there are nested paren-
	      thesis the innermost are evaluated as part of evaluating the expression  that  con-
	      tains them.

	      The  if  command was written very early in CMake's history, predating the ${} vari-
	      able evaluation syntax, and for convenience evaluates variables named by its  argu-
	      ments  as shown in the above signatures.	Note that normal variable evaluation with
	      ${} applies before the if command even receives the arguments.  Therefore code like

		set(var1 OFF)
		set(var2 "var1")
		if(${var2})

	      appears to the if command as

		if(var1)

	      and is evaluated according to the if(<variable>) case documented above.  The result
	      is  OFF  which  is  false.  However, if we remove the ${} from the example then the
	      command sees

		if(var2)

	      which is true because var2 is defined to "var1" which is not a false constant.

	      Automatic evaluation applies in the other cases whenever the above-documented  sig-
	      nature accepts <variable|string>:

	      1)  The  left  hand  argument to MATCHES is first checked to see if it is a defined
	      variable, if so the variable's value is used, otherwise the original value is used.

	      2) If the left hand argument to MATCHES is missing it returns false without error

	      3) Both left and right hand arguments  to  LESS  GREATER	EQUAL  are  independently
	      tested  to  see  if they are defined variables, if so their defined values are used
	      otherwise the original value is used.

	      4) Both left and right hand arguments to STRLESS STREQUAL STRGREATER  are  indepen-
	      dently  tested to see if they are defined variables, if so their defined values are
	      used otherwise the original value is used.

	      5)  Both	left  and  right  hand	argumemnts  to	VERSION_LESS  VERSION_EQUAL  VER-
	      SION_GREATER  are  independently tested to see if they are defined variables, if so
	      their defined values are used otherwise the original value is used.

	      6) The right hand argument to NOT is tested to see if it is a boolean constant,  if
	      so  the  value is used, otherwise it is assumed to be a variable and it is derefer-
	      enced.

	      7) The left and right hand arguments to AND OR are independently tested to  see  if
	      they are boolean constants, if so they are used as such, otherwise they are assumed
	      to be variables and are dereferenced.

       include
	      Read CMake listfile code from the given file.

		include(<file|module> [OPTIONAL] [RESULT_VARIABLE <VAR>]
				      [NO_POLICY_SCOPE])

	      Reads CMake listfile code from the given file.  Commands in the file are	processed
	      immediately  as  if they were written in place of the include command.  If OPTIONAL
	      is present, then no error is raised if the file does not exist.  If RESULT_VARIABLE
	      is  given  the variable will be set to the full filename which has been included or
	      NOTFOUND if it failed.

	      If a module is specified instead of a file, the file with  name  <modulename>.cmake
	      is  searched  first in CMAKE_MODULE_PATH, then in the CMake module directory. There
	      is one exception to this: if the file which calls include() is  located  itself  in
	      the  CMake  module directory, then first the CMake module directory is searched and
	      CMAKE_MODULE_PATH afterwards. See also policy CMP0017.

	      See the cmake_policy() command documentation for discussion of the  NO_POLICY_SCOPE
	      option.

       include_directories
	      Add include directories to the build.

		include_directories([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)

	      Add  the	given directories to those the compiler uses to search for include files.
	      Relative paths are interpreted as relative to the current source directory.

	      The include directories are added to the directory property INCLUDE_DIRECTORIES for
	      the   current  CMakeLists  file.	They  are  also  added	to  the  target  property
	      INCLUDE_DIRECTORIES for each target in the  current  CMakeLists  file.  The  target
	      property values are the ones used by the generators.

	      By  default the directories are appended onto the current list of directories. This
	      default behavior can be changed by setting CMAKE_INCLUDE_DIRECTORIES_BEFORE to  ON.
	      By  using AFTER or BEFORE explicitly, you can select between appending and prepend-
	      ing, independent of the default.

	      If the SYSTEM option is given, the compiler will be told the directories are  meant
	      as  system  include  directories	on  some platforms (signalling this setting might
	      achieve effects such as the compiler skipping warnings, or these fixed-install sys-
	      tem files not being considered in dependency calculations - see compiler docs).

       include_external_msproject
	      Include an external Microsoft project file in a workspace.

		include_external_msproject(projectname location
					   [TYPE projectTypeGUID]
					   [GUID projectGUID]
					   [PLATFORM platformName]
					   dep1 dep2 ...)

	      Includes	an external Microsoft project in the generated workspace file.	Currently
	      does nothing on UNIX. This will create a target named [projectname].  This  can  be
	      used in the add_dependencies command to make things depend on the external project.

	      TYPE,  GUID and PLATFORM are optional parameters that allow one to specify the type
	      of project, id (GUID) of the project and the name of the target platform.  This  is
	      useful  for  projects  requiring values other than the default (e.g. WIX projects).
	      These options are not supported by the Visual Studio 6 generator.

       include_regular_expression
	      Set the regular expression used for dependency checking.

		include_regular_expression(regex_match [regex_complain])

	      Set the regular expressions used	in  dependency	checking.   Only  files  matching
	      regex_match  will  be  traced  as dependencies.  Only files matching regex_complain
	      will generate warnings if they cannot be	found  (standard  header  paths  are  not
	      searched).  The defaults are:

		regex_match    = "^.*$" (match everything)
		regex_complain = "^$" (match empty string only)

       install
	      Specify rules to run at install time.

	      This  command generates installation rules for a project.  Rules specified by calls
	      to this command within a source directory are executed in  order	during	installa-
	      tion.  The order across directories is not defined.

	      There  are  multiple signatures for this command.  Some of them define installation
	      properties for files and targets.  Properties common  to	multiple  signatures  are
	      covered here but they are valid only for signatures that specify them.

	      DESTINATION  arguments  specify  the  directory  on  disk  to  which a file will be
	      installed.  If a full path (with a leading slash or drive letter) is  given  it  is
	      used directly.  If a relative path is given it is interpreted relative to the value
	      of CMAKE_INSTALL_PREFIX. The prefix can be relocated at install time using  DESTDIR
	      mechanism explained in the CMAKE_INSTALL_PREFIX variable documentation.

	      PERMISSIONS  arguments  specify permissions for installed files.	Valid permissions
	      are OWNER_READ, OWNER_WRITE, OWNER_EXECUTE, GROUP_READ, GROUP_WRITE, GROUP_EXECUTE,
	      WORLD_READ,  WORLD_WRITE,  WORLD_EXECUTE,  SETUID, and SETGID.  Permissions that do
	      not make sense on certain platforms are ignored on those platforms.

	      The CONFIGURATIONS argument specifies a list of build configurations for which  the
	      install rule applies (Debug, Release, etc.).

	      The  COMPONENT  argument	specifies  an  installation component name with which the
	      install rule is associated, such as  "runtime"  or  "development".   During  compo-
	      nent-specific  installation  only install rules associated with the given component
	      name will be executed.  During a full installation all components are installed. If
	      COMPONENT is not provided a default component "Unspecified" is created. The default
	      component name may  be  controlled  with	the  CMAKE_INSTALL_DEFAULT_COMPONENT_NAME
	      variable.

	      The  RENAME  argument  specifies a name for an installed file that may be different
	      from the original file.  Renaming is allowed only when a single file  is	installed
	      by the command.

	      The OPTIONAL argument specifies that it is not an error if the file to be installed
	      does not exist.

	      The TARGETS signature:

		install(TARGETS targets... [EXPORT <export-name>]
			[[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
			  PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
			 [DESTINATION <dir>]
			 [PERMISSIONS permissions...]
			 [CONFIGURATIONS [Debug|Release|...]]
			 [COMPONENT <component>]
			 [OPTIONAL] [NAMELINK_ONLY|NAMELINK_SKIP]
			] [...])

	      The TARGETS form specifies rules for installing targets from a project.  There  are
	      five kinds of target files that may be installed: ARCHIVE, LIBRARY, RUNTIME, FRAME-
	      WORK, and BUNDLE.  Executables are treated as RUNTIME targets,  except  that  those
	      marked  with  the  MACOSX_BUNDLE	property  are  treated as BUNDLE targets on OS X.
	      Static libraries are always treated as ARCHIVE targets. Module libraries are always
	      treated  as  LIBRARY targets. For non-DLL platforms shared libraries are treated as
	      LIBRARY targets, except that those marked with the FRAMEWORK property  are  treated
	      as  FRAMEWORK  targets on OS X.  For DLL platforms the DLL part of a shared library
	      is treated as a RUNTIME target and the corresponding import library is  treated  as
	      an  ARCHIVE  target.  All Windows-based systems including Cygwin are DLL platforms.
	      The ARCHIVE, LIBRARY, RUNTIME, and FRAMEWORK arguments change the type of target to
	      which  the  subsequent properties apply.	If none is given the installation proper-
	      ties apply to all target types.  If only one is given then  only	targets  of  that
	      type  will  be installed (which can be used to install just a DLL or just an import
	      library).

	      The PRIVATE_HEADER, PUBLIC_HEADER, and RESOURCE arguments cause subsequent  proper-
	      ties  to	be  applied  to installing a FRAMEWORK shared library target's associated
	      files on non-Apple platforms.  Rules defined by  these  arguments  are  ignored  on
	      Apple  platforms	because  the  associated files are installed into the appropriate
	      locations inside the framework folder.  See documentation  of  the  PRIVATE_HEADER,
	      PUBLIC_HEADER, and RESOURCE target properties for details.

	      Either  NAMELINK_ONLY  or  NAMELINK_SKIP	may be specified as a LIBRARY option.  On
	      some platforms a versioned shared library has a symbolic link such as

		lib<name>.so -> lib<name>.so.1

	      where "lib<name>.so.1" is the  soname  of  the  library  and  "lib<name>.so"  is	a
	      "namelink"  allowing  linkers  to  find  the  library  when  given "-l<name>".  The
	      NAMELINK_ONLY option causes installation of only the namelink when a library target
	      is  installed.  The NAMELINK_SKIP option causes installation of library files other
	      than the namelink when a library target is installed.  When neither option is given
	      both  portions are installed.  On platforms where versioned shared libraries do not
	      have namelinks or when a library is not versioned the NAMELINK_SKIP option installs
	      the  library  and  the  NAMELINK_ONLY option installs nothing.  See the VERSION and
	      SOVERSION target properties for details on creating versioned shared libraries.

	      One or more groups of properties may be specified in a single call to  the  TARGETS
	      form  of this command.  A target may be installed more than once to different loca-
	      tions.  Consider hypothetical targets "myExe",  "mySharedLib",  and  "myStaticLib".
	      The code

		  install(TARGETS myExe mySharedLib myStaticLib
			  RUNTIME DESTINATION bin
			  LIBRARY DESTINATION lib
			  ARCHIVE DESTINATION lib/static)
		  install(TARGETS mySharedLib DESTINATION /some/full/path)

	      will  install  myExe  to	<prefix>/bin  and myStaticLib to <prefix>/lib/static.  On
	      non-DLL	platforms   mySharedLib   will	 be   installed   to   <prefix>/lib   and
	      /some/full/path.	 On  DLL platforms the mySharedLib DLL will be installed to <pre-
	      fix>/bin and /some/full/path and its import library  will  be  installed	to  <pre-
	      fix>/lib/static and /some/full/path.

	      The  EXPORT  option  associates  the  installed  target files with an export called
	      <export-name>.  It must appear before any RUNTIME, LIBRARY, or ARCHIVE options.  To
	      actually	install  the export file itself, call install(EXPORT).	See documentation
	      of the install(EXPORT ...) signature below for details.

	      Installing a target with EXCLUDE_FROM_ALL set to true has undefined behavior.

	      The FILES signature:

		install(FILES files... DESTINATION <dir>
			[PERMISSIONS permissions...]
			[CONFIGURATIONS [Debug|Release|...]]
			[COMPONENT <component>]
			[RENAME <name>] [OPTIONAL])

	      The FILES form specifies rules for installing files  for	a  project.   File  names
	      given  as  relative paths are interpreted with respect to the current source direc-
	      tory.  Files installed by this form are by default given	permissions  OWNER_WRITE,
	      OWNER_READ, GROUP_READ, and WORLD_READ if no PERMISSIONS argument is given.

	      The PROGRAMS signature:

		install(PROGRAMS files... DESTINATION <dir>
			[PERMISSIONS permissions...]
			[CONFIGURATIONS [Debug|Release|...]]
			[COMPONENT <component>]
			[RENAME <name>] [OPTIONAL])

	      The  PROGRAMS  form  is identical to the FILES form except that the default permis-
	      sions for  the  installed  file  also  include  OWNER_EXECUTE,  GROUP_EXECUTE,  and
	      WORLD_EXECUTE.   This  form  is  intended to install programs that are not targets,
	      such as shell scripts.  Use the TARGETS form to install targets  built  within  the
	      project.

	      The DIRECTORY signature:

		install(DIRECTORY dirs... DESTINATION <dir>
			[FILE_PERMISSIONS permissions...]
			[DIRECTORY_PERMISSIONS permissions...]
			[USE_SOURCE_PERMISSIONS] [OPTIONAL]
			[CONFIGURATIONS [Debug|Release|...]]
			[COMPONENT <component>] [FILES_MATCHING]
			[[PATTERN <pattern> | REGEX <regex>]
			 [EXCLUDE] [PERMISSIONS permissions...]] [...])

	      The DIRECTORY form installs contents of one or more directories to a given destina-
	      tion.  The directory structure is copied verbatim to  the  destination.	The  last
	      component  of  each  directory  name is appended to the destination directory but a
	      trailing slash may be used to avoid this	because  it  leaves  the  last	component
	      empty.  Directory names given as relative paths are interpreted with respect to the
	      current source directory.  If no input directory names are  given  the  destination
	      directory  will be created but nothing will be installed into it.  The FILE_PERMIS-
	      SIONS and DIRECTORY_PERMISSIONS options specify  permissions  given  to  files  and
	      directories  in  the  destination.   If  USE_SOURCE_PERMISSIONS  is  specified  and
	      FILE_PERMISSIONS is not, file permissions will be copied from the source	directory
	      structure.  If no permissions are specified files will be given the default permis-
	      sions specified in the FILES form of the command, and the directories will be given
	      the default permissions specified in the PROGRAMS form of the command.

	      Installation  of directories may be controlled with fine granularity using the PAT-
	      TERN or REGEX options.  These "match" options specify a globbing pattern or regular
	      expression  to  match  directories  or  files encountered within input directories.
	      They may be used to apply certain options (see below) to a subset of the files  and
	      directories  encountered.  The full path to each input file or directory (with for-
	      ward slashes) is matched against the expression.	A PATTERN will	match  only  com-
	      plete  file  names: the portion of the full path matching the pattern must occur at
	      the end of the file name and be preceded by a slash.  A REGEX will match	any  por-
	      tion  of the full path but it may use '/' and '$' to simulate the PATTERN behavior.
	      By default all files and directories are installed whether or not they are matched.
	      The  FILES_MATCHING  option  may	be given before the first match option to disable
	      installation of files (but not directories) not matched  by  any	expression.   For
	      example, the code

		install(DIRECTORY src/ DESTINATION include/myproj
			FILES_MATCHING PATTERN "*.h")

	      will extract and install header files from a source tree.

	      Some options may follow a PATTERN or REGEX expression and are applied only to files
	      or directories matching them.  The EXCLUDE option will skip  the	matched  file  or
	      directory.   The	PERMISSIONS  option  overrides	the  permissions  setting for the
	      matched file or directory.  For example the code

		install(DIRECTORY icons scripts/ DESTINATION share/myproj
			PATTERN "CVS" EXCLUDE
			PATTERN "scripts/*"
			PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ
				    GROUP_EXECUTE GROUP_READ)

	      will install the icons directory to share/myproj/icons and the scripts directory to
	      share/myproj.   The  icons  will	get default file permissions, the scripts will be
	      given specific permissions, and any CVS directories will be excluded.

	      The SCRIPT and CODE signature:

		install([[SCRIPT <file>] [CODE <code>]] [...])

	      The SCRIPT form will invoke the given CMake script files during  installation.   If
	      the  script file name is a relative path it will be interpreted with respect to the
	      current source directory.  The CODE form will invoke the given  CMake  code  during
	      installation.   Code  is	specified  as  a  single  argument inside a double-quoted
	      string. For example, the code

		install(CODE "MESSAGE(\"Sample install message.\")")

	      will print a message during installation.

	      The EXPORT signature:

		install(EXPORT <export-name> DESTINATION <dir>
			[NAMESPACE <namespace>] [FILE <name>.cmake]
			[PERMISSIONS permissions...]
			[CONFIGURATIONS [Debug|Release|...]]
			[COMPONENT <component>])

	      The EXPORT form generates and installs a CMake file containing code to import  tar-
	      gets  from  the  installation  tree into another project.  Target installations are
	      associated  with	the  export  <export-name>  using  the	EXPORT	option	 of   the
	      install(TARGETS ...) signature documented above.	The NAMESPACE option will prepend
	      <namespace> to the target names as they are written to the import file.  By default
	      the  generated  file  will be called <export-name>.cmake but the FILE option may be
	      used to specify a different name.  The value given to the FILE  option  must  be	a
	      file  name  with	the ".cmake" extension.  If a CONFIGURATIONS option is given then
	      the file will only be installed when one of the named configurations is  installed.
	      Additionally,  the  generated  import  file will reference only the matching target
	      configurations.  If a COMPONENT option is specified that does not match that  given
	      to  the  targets	associated  with  <export-name>  the behavior is undefined.  If a
	      library target is included in the export but a target to	which  it  links  is  not
	      included the behavior is unspecified.

	      The  EXPORT form is useful to help outside projects use targets built and installed
	      by the current project.  For example, the code

		install(TARGETS myexe EXPORT myproj DESTINATION bin)
		install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj)

	      will install the executable myexe to <prefix>/bin and code to import it in the file
	      "<prefix>/lib/myproj/myproj.cmake".  An outside project may load this file with the
	      include command and reference the myexe executable from the installation tree using
	      the imported target name mp_myexe as if the target were built in its own tree.

	      NOTE: This command supercedes the INSTALL_TARGETS command and the target properties
	      PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT.  It also replaces the  FILES	forms  of
	      the  INSTALL_FILES  and  INSTALL_PROGRAMS  commands.  The processing order of these
	      install rules relative to those generated by  INSTALL_TARGETS,  INSTALL_FILES,  and
	      INSTALL_PROGRAMS commands is not defined.

       link_directories
	      Specify directories in which the linker will look for libraries.

		link_directories(directory1 directory2 ...)

	      Specify the paths in which the linker should search for libraries. The command will
	      apply only to targets created after it is called. Relative paths given to this com-
	      mand are interpreted as relative to the current source directory, see CMP0015.

	      Note  that  this	command  is  rarely  necessary.   Library  locations  returned by
	      find_package() and find_library() are absolute paths.  Pass these absolute  library
	      file  paths directly to the target_link_libraries() command.  CMake will ensure the
	      linker finds them.

       list   List operations.

		list(LENGTH <list> <output variable>)
		list(GET <list> <element index> [<element index> ...]
		     <output variable>)
		list(APPEND <list> <element> [<element> ...])
		list(FIND <list> <value> <output variable>)
		list(INSERT <list> <element_index> <element> [<element> ...])
		list(REMOVE_ITEM <list> <value> [<value> ...])
		list(REMOVE_AT <list> <index> [<index> ...])
		list(REMOVE_DUPLICATES <list>)
		list(REVERSE <list>)
		list(SORT <list>)

	      LENGTH will return a given list's length.

	      GET will return list of elements specified by indices from the list.

	      APPEND will append elements to the list.

	      FIND will return the index of the element specified in the list or -1 if it  wasn't
	      found.

	      INSERT will insert elements to the list to the specified location.

	      REMOVE_AT  and  REMOVE_ITEM will remove items from the list. The difference is that
	      REMOVE_ITEM will remove the given items, while REMOVE_AT will remove the	items  at
	      the given indices.

	      REMOVE_DUPLICATES will remove duplicated items in the list.

	      REVERSE reverses the contents of the list in-place.

	      SORT sorts the list in-place alphabetically.

	      The  list  subcommands  APPEND,  INSERT, REMOVE_AT, REMOVE_ITEM, REMOVE_DUPLICATES,
	      REVERSE and SORT may create new values for the list within the current CMake  vari-
	      able  scope. Similar to the SET command, the LIST command creates new variable val-
	      ues in the current scope, even if the list itself is actually defined in	a  parent
	      scope.  To  propagate  the  results  of these operations upwards, use SET with PAR-
	      ENT_SCOPE, SET with CACHE INTERNAL, or some other means of value propagation.

	      NOTES: A list in cmake is a ; separated group of strings. To create a list the  set
	      command  can  be	used.  For  example,  set(var  a  b  c	d e)  creates a list with
	      a;b;c;d;e, and set(var "a b c d e") creates a string or a list with one item in it.

	      When specifying index values, if <element index> is 0 or	greater,  it  is  indexed
	      from  the  beginning  of	the  list, with 0 representing the first list element. If
	      <element index> is -1 or lesser, it is indexed from the end of the  list,  with  -1
	      representing the last list element. Be careful when counting with negative indices:
	      they do not start from 0. -0 is equivalent to 0, the first list element.

       load_cache
	      Load in the values from another project's CMake cache.

		load_cache(pathToCacheFile READ_WITH_PREFIX
			   prefix entry1...)

	      Read the cache and store the requested entries in variables with	their  name  pre-
	      fixed  with  the	given  prefix.	 This  only reads the values, and does not create
	      entries in the local project's cache.

		load_cache(pathToCacheFile [EXCLUDE entry1...]
			   [INCLUDE_INTERNALS entry1...])

	      Load in the values from another cache and store them in the local  project's  cache
	      as  internal entries.  This is useful for a project that depends on another project
	      built in a different tree.  EXCLUDE option can be used to provide a list of entries
	      to  be  excluded.   INCLUDE_INTERNALS  can  be  used  to provide a list of internal
	      entries to be included.  Normally, no internal entries are brought in.  Use of this
	      form  of	the command is strongly discouraged, but it is provided for backward com-
	      patibility.

       load_command
	      Load a command into a running CMake.

		load_command(COMMAND_NAME <loc1> [loc2 ...])

	      The given locations are searched for a library whose name  is  cmCOMMAND_NAME.   If
	      found,  it  is  loaded as a module and the command is added to the set of available
	      CMake commands.  Usually, TRY_COMPILE is used before this command  to  compile  the
	      module. If the command is successfully loaded a variable named

		CMAKE_LOADED_COMMAND_<COMMAND_NAME>

	      will be set to the full path of the module that was loaded.  Otherwise the variable
	      will not be set.

       macro  Start recording a macro for later invocation as a command.

		macro(<name> [arg1 [arg2 [arg3 ...]]])
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		endmacro(<name>)

	      Define a macro named <name> that takes arguments named arg1 arg2 arg3 (...).   Com-
	      mands  listed  after macro, but before the matching endmacro, are not invoked until
	      the macro is invoked.  When it is invoked, the commands recorded in the  macro  are
	      first  modified by replacing formal parameters (${arg1}) with the arguments passed,
	      and then invoked as normal commands. In addition to referencing the formal  parame-
	      ters  you can reference the values ${ARGC} which will be set to the number of argu-
	      ments passed into the function as well as ${ARGV0} ${ARGV1} ${ARGV2} ... which will
	      have the actual values of the arguments passed in. This facilitates creating macros
	      with optional arguments. Additionally ${ARGV} holds the list of all arguments given
	      to  the  macro and ${ARGN} holds the list of arguments past the last expected argu-
	      ment. Note that the parameters to a macro and values such as ARGN are not variables
	      in the usual CMake sense. They are string replacements much like the C preprocessor
	      would do with a macro. If you want true CMake variables and/or better  CMake  scope
	      control you should look at the function command.

	      See  the	cmake_policy()	command documentation for the behavior of policies inside
	      macros.

       mark_as_advanced
	      Mark cmake cached variables as advanced.

		mark_as_advanced([CLEAR|FORCE] VAR VAR2 VAR...)

	      Mark the named cached variables as advanced.  An advanced variable will not be dis-
	      played in any of the cmake GUIs unless the show advanced option is on.  If CLEAR is
	      the first argument advanced variables are changed back to unadvanced.  If FORCE  is
	      the first argument, then the variable is made advanced.  If neither FORCE nor CLEAR
	      is specified, new values will be marked as advanced, but if  the	variable  already
	      has an advanced/non-advanced state, it will not be changed.

	      It does nothing in script mode.

       math   Mathematical expressions.

		math(EXPR <output variable> <math expression>)

	      EXPR  evaluates  mathematical expression and returns result in the output variable.
	      Example mathematical expression is '5 * ( 10 + 13 )'.  Supported operators are +	-
	      * / % | & ^ ~ << >> * / %.  They have the same meaning  as they do in C code.

       message
	      Display a message to the user.

		message([STATUS|WARNING|AUTHOR_WARNING|FATAL_ERROR|SEND_ERROR]
			"message to display" ...)

	      The optional keyword determines the type of message:

		(none)	       = Important information
		STATUS	       = Incidental information
		WARNING        = CMake Warning, continue processing
		AUTHOR_WARNING = CMake Warning (dev), continue processing
		SEND_ERROR     = CMake Error, continue processing,
					      but skip generation
		FATAL_ERROR    = CMake Error, stop processing and generation

	      The  CMake  command-line tool displays STATUS messages on stdout and all other mes-
	      sage types on stderr.  The CMake GUI displays all messages in its  log  area.   The
	      interactive dialogs (ccmake and CMakeSetup) show STATUS messages one at a time on a
	      status line and other messages in interactive pop-up boxes.

	      CMake Warning and Error message text  displays  using  a	simple	markup	language.
	      Non-indented  text  is  formatted in line-wrapped paragraphs delimited by newlines.
	      Indented text is considered pre-formatted.

       option Provides an option that the user can optionally select.

		option(<option_variable> "help string describing option"
		       [initial value])

	      Provide an option for the user to select as ON or OFF.  If no initial value is pro-
	      vided, OFF is used.

	      If you have options that depend on the values of other options, see the module help
	      for CMakeDependentOption.

       project
	      Set a name for the entire project.

		project(<projectname> [languageName1 languageName2 ... ] )

	      Sets the name of the project.   Additionally  this  sets	the  variables	<project-
	      Name>_BINARY_DIR and <projectName>_SOURCE_DIR to the respective values.

	      Optionally  you  can  specify  which languages your project supports.  Example lan-
	      guages are CXX (i.e. C++), C, Fortran, etc. By default C and CXX are enabled.  E.g.
	      if  you  do not have a C++ compiler, you can disable the check for it by explicitly
	      listing the languages you want to support, e.g. C.  By using the	special  language
	      "NONE"  all  checks  for	any language can be disabled. If a variable exists called
	      CMAKE_PROJECT_<projectName>_INCLUDE, the file pointed to by that variable  will  be
	      included as the last step of the project command.

       qt_wrap_cpp
	      Create Qt Wrappers.

		qt_wrap_cpp(resultingLibraryName DestName
			    SourceLists ...)

	      Produce  moc  files  for all the .h files listed in the SourceLists.  The moc files
	      will be added to the library using the DestName source list.

       qt_wrap_ui
	      Create Qt user interfaces Wrappers.

		qt_wrap_ui(resultingLibraryName HeadersDestName
			   SourcesDestName SourceLists ...)

	      Produce .h and .cxx files for all the .ui files listed in the SourceLists.  The  .h
	      files  will be added to the library using the HeadersDestNamesource list.  The .cxx
	      files will be added to the library using the SourcesDestNamesource list.

       remove_definitions
	      Removes -D define flags added by add_definitions.

		remove_definitions(-DFOO -DBAR ...)

	      Removes flags (added by add_definitions) from the compiler command line for sources
	      in the current directory and below.

       return Return from a file, directory or function.

		return()

	      Returns  from a file, directory or function. When this command is encountered in an
	      included file (via include() or find_package()), it causes processing of	the  cur-
	      rent  file  to stop and control is returned to the including file. If it is encoun-
	      tered in a file which is not included by another file, e.g. a CMakeLists.txt,  con-
	      trol  is returned to the parent directory if there is one. If return is called in a
	      function, control is returned to the caller of the function. Note that a	macro  is
	      not a function and does not handle return like a function does.

       separate_arguments
	      Parse space-separated arguments into a semicolon-separated list.

		separate_arguments(<var> <UNIX|WINDOWS>_COMMAND "<args>")

	      Parses  a  unix-	or  windows-style command-line string "<args>" and stores a semi-
	      colon-separated list of the arguments in <var>.  The entire command  line  must  be
	      given in one "<args>" argument.

	      The  UNIX_COMMAND  mode  separates arguments by unquoted whitespace.  It recognizes
	      both single-quote and double-quote pairs.  A backslash  escapes  the  next  literal
	      character (\" is "); there are no special escapes (\n is just n).

	      The  WINDOWS_COMMAND  mode  parses a windows command-line using the same syntax the
	      runtime library uses to construct argv  at  startup.   It  separates  arguments  by
	      whitespace  that is not double-quoted.  Backslashes are literal unless they precede
	      double-quotes.  See  the	MSDN  article  "Parsing  C  Command-Line  Arguments"  for
	      details.

		separate_arguments(VARIABLE)

	      Convert  the  value  of  VARIABLE  to  a semi-colon separated list.  All spaces are
	      replaced with ';'.  This helps with generating command lines.

       set    Set a CMake, cache or environment variable to a given value.

		set(<variable> <value>
		    [[CACHE <type> <docstring> [FORCE]] | PARENT_SCOPE])

	      Within CMake sets <variable> to the value  <value>.   <value>  is  expanded  before
	      <variable> is set to it.	Normally, set will set a regular CMake variable. If CACHE
	      is present, then the <variable> is put in the cache instead, unless it  is  already
	      in  the  cache.  See section 'Variable types in CMake' below for details of regular
	      and cache variables and their interactions. If CACHE  is	used,  <type>  and  <doc-
	      string> are required. <type> is used by the CMake GUI to choose a widget with which
	      the user sets a value. The value for <type> may be one of

		FILEPATH = File chooser dialog.
		PATH	 = Directory chooser dialog.
		STRING	 = Arbitrary string.
		BOOL	 = Boolean ON/OFF checkbox.
		INTERNAL = No GUI entry (used for persistent variables).

	      If <type> is INTERNAL, the cache variable is marked as internal, and  will  not  be
	      shown  to the user in tools like cmake-gui. This is intended for values that should
	      be persisted in the cache, but which users should  not  normally	change.  INTERNAL
	      implies FORCE.

	      Normally,  set(...CACHE...)  creates  cache variables, but does not modify them. If
	      FORCE is specified, the value of the cache variable is set, even if the variable is
	      already  in  the	cache.	This  should  normally	be avoided, as it will remove any
	      changes to the cache variable's value by the user.

	      If PARENT_SCOPE is present, the variable will be set in the scope above the current
	      scope.  Each  new  directory or function creates a new scope. This command will set
	      the value of a variable into the parent directory or calling function (whichever is
	      applicable to the case at hand). PARENT_SCOPE cannot be combined with CACHE.

	      If <value> is not specified then the variable is removed instead of set.	See also:
	      the unset() command.

		set(<variable> <value1> ... <valueN>)

	      In this case <variable> is set to a semicolon separated list of values.

	      <variable> can be an environment variable such as:

		set( ENV{PATH} /home/martink )

	      in which case the environment variable will be set.

	      *** Variable types in CMake ***

	      In CMake there are two types of variables: normal variables  and	cache  variables.
	      Normal  variables are meant for the internal use of the script (just like variables
	      in most programming languages); they are not persisted  across  CMake  runs.  Cache
	      variables (unless set with INTERNAL) are mostly intended for configuration settings
	      where the first CMake run determines a suitable default value, which the	user  can
	      then  override,  by editing the cache with tools such as ccmake or cmake-gui. Cache
	      variables are stored in the CMake cache file, and are persisted across CMake runs.

	      Both types can exist at the same time with the same name but different values. When
	      ${FOO}  is  evaluated,  CMake  first looks for a normal variable 'FOO' in scope and
	      uses it if set. If and only if no normal variable exists then it falls back to  the
	      cache variable 'FOO'.

	      Some examples:

	      The  code  'set(FOO  "x")'  sets	the  normal variable 'FOO'. It does not touch the
	      cache, but it will hide any existing cache value 'FOO'.

	      The code 'set(FOO "x" CACHE ...)' checks for 'FOO' in the cache, ignoring any  nor-
	      mal  variable  of  the  same name. If 'FOO' is in the cache then nothing happens to
	      either the normal variable or the cache variable. If 'FOO' is  not  in  the  cache,
	      then it is added to the cache.

	      Finally,	whenever  a  cache variable is added or modified by a command, CMake also
	      *removes* the normal variable of the same name from the current scope  so  that  an
	      immediately following evaluation of it will expose the newly cached value.

	      Normally	projects  should avoid using normal and cache variables of the same name,
	      as this interaction can be hard to follow. However, in some situations  it  can  be
	      useful. One example (used by some projects):

	      A project has a subproject in its source tree. The child project has its own CMake-
	      Lists.txt, which is included from the  parent  CMakeLists.txt  using  add_subdirec-
	      tory(). Now, if the parent and the child project provide the same option (for exam-
	      ple a compiler option), the parent gets the first chance	to  add  a  user-editable
	      option  to  the  cache.  Normally, the child would then use the same value that the
	      parent uses. However, it may be necessary to hard-code  the  value  for  the  child
	      project's option while still allowing the user to edit the value used by the parent
	      project. The parent project can achieve this simply by setting  a  normal  variable
	      with  the  same name as the option in a scope sufficient to hide the option's cache
	      variable from the child completely. The parent has already set the cache	variable,
	      so the child's set(...CACHE...) will do nothing, and evaluating the option variable
	      will use the value from the normal variable, which hides the cache variable.

       set_directory_properties
	      Set a property of the directory.

		set_directory_properties(PROPERTIES prop1 value1 prop2 value2)

	      Set a property for the current directory and subdirectories. If the property is not
	      found,  CMake  will  report  an error. The properties include: INCLUDE_DIRECTORIES,
	      LINK_DIRECTORIES,  INCLUDE_REGULAR_EXPRESSION,   and   ADDITIONAL_MAKE_CLEAN_FILES.
	      ADDITIONAL_MAKE_CLEAN_FILES  is  a  list of files that will be cleaned as a part of
	      "make clean" stage.

       set_property
	      Set a named property in a given scope.

		set_property(<GLOBAL				|
			      DIRECTORY [dir]			|
			      TARGET	[target1 [target2 ...]] |
			      SOURCE	[src1 [src2 ...]]	|
			      TEST	[test1 [test2 ...]]	|
			      CACHE	[entry1 [entry2 ...]]>
			     [APPEND] [APPEND_STRING]
			     PROPERTY <name> [value1 [value2 ...]])

	      Set one property on zero or more objects of a scope.  The first argument determines
	      the scope in which the property is set.  It must be one of the following:

	      GLOBAL scope is unique and does not accept a name.

	      DIRECTORY  scope	defaults  to the current directory but another directory (already
	      processed by CMake) may be named by full or relative path.

	      TARGET scope may name zero or more existing targets.

	      SOURCE scope may name zero or more source files.	Note that source file  properties
	      are visible only to targets added in the same directory (CMakeLists.txt).

	      TEST scope may name zero or more existing tests.

	      CACHE scope must name zero or more cache existing entries.

	      The required PROPERTY option is immediately followed by the name of the property to
	      set.  Remaining arguments are used to compose the property value in the form  of	a
	      semicolon-separated  list.   If  the APPEND option is given the list is appended to
	      any existing property value.If the APPEND_STRING option  is  given  the  string  is
	      append to any existing property value as string, i.e. it results in a longer string
	      and not a list of strings.

       set_source_files_properties
	      Source files can have properties that affect how they are built.

		set_source_files_properties([file1 [file2 [...]]]
					    PROPERTIES prop1 value1
					    [prop2 value2 [...]])

	      Set properties associated with source files using a  key/value  paired  list.   See
	      properties  documentation  for  those  known to CMake.  Unrecognized properties are
	      ignored.	Source file properties are visible only to  targets  added  in	the  same
	      directory (CMakeLists.txt).

       set_target_properties
	      Targets can have properties that affect how they are built.

		set_target_properties(target1 target2 ...
				      PROPERTIES prop1 value1
				      prop2 value2 ...)

	      Set properties on a target. The syntax for the command is to list all the files you
	      want to change, and then provide the values you want to set next.  You can use  any
	      prop value pair you want and extract it later with the GET_TARGET_PROPERTY command.

	      Properties that affect the name of a target's output file are as follows.  The PRE-
	      FIX and SUFFIX properties override the default target name prefix (such  as  "lib")
	      and  suffix  (such  as  ".so").  IMPORT_PREFIX and IMPORT_SUFFIX are the equivalent
	      properties for the import library corresponding to a DLL (for SHARED  library  tar-
	      gets).  OUTPUT_NAME sets the real name of a target when it is built and can be used
	      to help create two targets of the same name even though CMake requires unique logi-
	      cal  target  names.   There  is also a <CONFIG>_OUTPUT_NAME that can set the output
	      name on a per-configuration basis.  <CONFIG>_POSTFIX sets a postfix  for	the  real
	      name  of	the target when it is built under the configuration named by <CONFIG> (in
	      upper-case, such as "DEBUG_POSTFIX").  The value of this	property  is  initialized
	      when  the  target  is  created  to the value of the variable CMAKE_<CONFIG>_POSTFIX
	      (except for executable targets because earlier CMake versions  which  did  not  use
	      this variable for executables).

	      The  LINK_FLAGS  property can be used to add extra flags to the link step of a tar-
	      get. LINK_FLAGS_<CONFIG> will add  to  the  configuration  <CONFIG>,  for  example,
	      DEBUG, RELEASE, MINSIZEREL, RELWITHDEBINFO. DEFINE_SYMBOL sets the name of the pre-
	      processor symbol defined when compiling sources in a shared  library.  If  not  set
	      here  then  it  is set to target_EXPORTS by default (with some substitutions if the
	      target is not a valid C identifier). This is useful for  headers	to  know  whether
	      they are being included from inside their library or outside to properly setup dll-
	      export/dllimport decorations. The COMPILE_FLAGS property sets  additional  compiler
	      flags  used  to build sources within the target.	It may also be used to pass addi-
	      tional preprocessor definitions.

	      The LINKER_LANGUAGE property is used to change the tool used to link an  executable
	      or  shared  library.  The  default  is  set  the language to match the files in the
	      library. CXX and C are common values for this property.

	      For shared libraries VERSION and SOVERSION can be used to specify the build version
	      and  api version respectively. When building or installing appropriate symlinks are
	      created if the platform supports symlinks and the linker supports so-names. If only
	      one  of  both  is specified the missing is assumed to have the same version number.
	      For executables VERSION can be used to specify the build version. When building  or
	      installing  appropriate symlinks are created if the platform supports symlinks. For
	      shared libraries and executables on Windows the  VERSION	attribute  is  parsed  to
	      extract a "major.minor" version number. These numbers are used as the image version
	      of the binary.

	      There are a few properties used to specify RPATH rules. INSTALL_RPATH  is  a  semi-
	      colon-separated  list  specifying  the rpath to use in installed targets (for plat-
	      forms that support it). INSTALL_RPATH_USE_LINK_PATH is a boolean	that  if  set  to
	      true  will  append directories in the linker search path and outside the project to
	      the INSTALL_RPATH. SKIP_BUILD_RPATH is a boolean specifying whether to  skip  auto-
	      matic  generation  of  an  rpath	allowing  the  target to run from the build tree.
	      BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link the target in  the
	      build tree with the INSTALL_RPATH.  This takes precedence over SKIP_BUILD_RPATH and
	      avoids the need for relinking before installation.  INSTALL_NAME_DIR  is	a  string
	      specifying the directory portion of the "install_name" field of shared libraries on
	      Mac OSX to use in the installed targets. When the target is created the  values  of
	      the      variables      CMAKE_INSTALL_RPATH,     CMAKE_INSTALL_RPATH_USE_LINK_PATH,
	      CMAKE_SKIP_BUILD_RPATH, CMAKE_BUILD_WITH_INSTALL_RPATH, and  CMAKE_INSTALL_NAME_DIR
	      are used to initialize these properties.

	      PROJECT_LABEL  can  be  used to change the name of the target in an IDE like visual
	      studio.  VS_KEYWORD can be set to change the visual studio keyword, for example  Qt
	      integration works better if this is set to Qt4VSv1.0.

	      VS_SCC_PROJECTNAME, VS_SCC_LOCALPATH, VS_SCC_PROVIDER and VS_SCC_AUXPATH can be set
	      to add support for source control bindings in a  Visual Studio project file.

	      VS_GLOBAL_<variable> can be set to add  a  Visual  Studio  project-specific  global
	      variable.  Qt integration works better if VS_GLOBAL_QtVersion is set to the Qt ver-
	      sion FindQt4.cmake found. For example, "4.7.3"

	      The PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT properties are the old way to  spec-
	      ify  CMake scripts to run before and after installing a target.  They are used only
	      when the old INSTALL_TARGETS command is  used  to  install  the  target.	 Use  the
	      INSTALL command instead.

	      The  EXCLUDE_FROM_DEFAULT_BUILD  property  is used by the visual studio generators.
	      If it is set to 1 the target will not be part of the default build when you  select
	      "Build  Solution".  This	can  also  be  set  on	a  per-configuration  basis using
	      EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>.

       set_tests_properties
	      Set a property of the tests.

		set_tests_properties(test1 [test2...] PROPERTIES prop1 value1 prop2 value2)

	      Set a property for the tests. If the property is not found, CMake  will  report  an
	      error. The properties include:

	      WILL_FAIL: If set to true, this will invert the pass/fail flag of the test.

	      PASS_REGULAR_EXPRESSION: If set, the test output will be checked against the speci-
	      fied regular expressions and at least one of the regular expressions has to  match,
	      otherwise the test will fail.

		Example: PASS_REGULAR_EXPRESSION "TestPassed;All ok"

	      FAIL_REGULAR_EXPRESSION: If set, if the output will match to one of specified regu-
	      lar expressions, the test will fail.

		Example: PASS_REGULAR_EXPRESSION "[^a-z]Error;ERROR;Failed"

	      Both PASS_REGULAR_EXPRESSION and FAIL_REGULAR_EXPRESSION expect a list  of  regular
	      expressions.

	      TIMEOUT:	Setting  this will limit the test runtime to the number of seconds speci-
	      fied.

       site_name
	      Set the given variable to the name of the computer.

		site_name(variable)

       source_group
	      Define a grouping for sources in the makefile.

		source_group(name [REGULAR_EXPRESSION regex] [FILES src1 src2 ...])

	      Defines a group into which sources will be placed in project files.  This is mainly
	      used to setup file tabs in Visual Studio.  Any file whose name is listed or matches
	      the regular expression will be placed in this group.  If a  file	matches  multiple
	      groups,  the LAST group that explicitly lists the file will be favored, if any.  If
	      no group explicitly lists the file, the LAST group whose regular expression matches
	      the file will be favored.

	      The name of the group may contain backslashes to specify subgroups:

		source_group(outer\\inner ...)

	      For backwards compatibility, this command also supports the format:

		source_group(name regex)

       string String operations.

		string(REGEX MATCH <regular_expression>
		       <output variable> <input> [<input>...])
		string(REGEX MATCHALL <regular_expression>
		       <output variable> <input> [<input>...])
		string(REGEX REPLACE <regular_expression>
		       <replace_expression> <output variable>
		       <input> [<input>...])
		string(REPLACE <match_string>
		       <replace_string> <output variable>
		       <input> [<input>...])
		string(<MD5|SHA1|SHA224|SHA256|SHA384|SHA512>
		       <output variable> <input>)
		string(COMPARE EQUAL <string1> <string2> <output variable>)
		string(COMPARE NOTEQUAL <string1> <string2> <output variable>)
		string(COMPARE LESS <string1> <string2> <output variable>)
		string(COMPARE GREATER <string1> <string2> <output variable>)
		string(ASCII <number> [<number> ...] <output variable>)
		string(CONFIGURE <string1> <output variable>
		       [@ONLY] [ESCAPE_QUOTES])
		string(TOUPPER <string1> <output variable>)
		string(TOLOWER <string1> <output variable>)
		string(LENGTH <string> <output variable>)
		string(SUBSTRING <string> <begin> <length> <output variable>)
		string(STRIP <string> <output variable>)
		string(RANDOM [LENGTH <length>] [ALPHABET <alphabet>]
		       [RANDOM_SEED <seed>] <output variable>)
		string(FIND <string> <substring> <output variable> [REVERSE])
		string(TIMESTAMP <output variable> [<format string>] [UTC])

	      REGEX  MATCH will match the regular expression once and store the match in the out-
	      put variable.

	      REGEX MATCHALL will match the regular expression as  many  times	as  possible  and
	      store the matches in the output variable as a list.

	      REGEX  REPLACE will match the regular expression as many times as possible and sub-
	      stitute the replacement expression for  the  match  in  the  output.   The  replace
	      expression  may  refer to paren-delimited subexpressions of the match using \1, \2,
	      ..., \9.	Note that two backslashes (\\1) are required in CMake code to get a back-
	      slash through argument parsing.

	      REPLACE	will   replace	 all  occurrences  of  match_string  in  the  input  with
	      replace_string and store the result in the output.

	      MD5, SHA1, SHA224, SHA256, SHA384, and SHA512 will compute a cryptographic hash  of
	      the input string.

	      COMPARE  EQUAL/NOTEQUAL/LESS/GREATER  will  compare  the	strings and store true or
	      false in the output variable.

	      ASCII will convert all numbers into corresponding ASCII characters.

	      CONFIGURE will transform a string like CONFIGURE_FILE transforms a file.

	      TOUPPER/TOLOWER will convert string to upper/lower characters.

	      LENGTH will return a given string's length.

	      SUBSTRING will return a substring of a given string. If length is -1 the	remainder
	      of the string starting at begin will be returned.

	      STRIP  will  return  a substring of a given string with leading and trailing spaces
	      removed.

	      RANDOM will return a random string of given length consisting  of  characters  from
	      the given alphabet. Default length is 5 characters and default alphabet is all num-
	      bers and upper and lower case letters.  If an integer  RANDOM_SEED  is  given,  its
	      value will be used to seed the random number generator.

	      FIND  will  return the position where the given substring was found in the supplied
	      string. If the REVERSE flag was used, the command will search for the  position  of
	      the last occurrence of the specified substring.

	      The following characters have special meaning in regular expressions:

		 ^	   Matches at beginning of input
		 $	   Matches at end of input
		 .	   Matches any single character
		 [ ]	   Matches any character(s) inside the brackets
		 [^ ]	   Matches any character(s) not inside the brackets
		  -	   Inside brackets, specifies an inclusive range between
			   characters on either side e.g. [a-f] is [abcdef]
			   To match a literal - using brackets, make it the first
			   or the last character e.g. [+*/-] matches basic
			   mathematical operators.
		 *	   Matches preceding pattern zero or more times
		 +	   Matches preceding pattern one or more times
		 ?	   Matches preceding pattern zero or once only
		 |	   Matches a pattern on either side of the |
		 ()	   Saves a matched subexpression, which can be referenced
			   in the REGEX REPLACE operation. Additionally it is saved
			   by all regular expression-related commands, including
			   e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).

	      *,  +  and ? have higher precedence than concatenation. | has lower precedence than
	      concatenation. This means that the regular expression "^ab+d$" matches  "abbd"  but
	      not "ababd", and the regular expression "^(ab|cd)$" matches "ab" but not "abd".

	      TIMESTAMP will write a string representation of the current date and/or time to the
	      output variable.

	      Should the command be unable to obtain a timestamp the output variable will be  set
	      to the empty string "".

	      The  optional UTC flag requests the current date/time representation to be in Coor-
	      dinated Universal Time (UTC) rather than local time.

	      The optional <format string> may contain the following format specifiers:

		 %d	   The day of the current month (01-31).
		 %H	   The hour on a 24-hour clock (00-23).
		 %I	   The hour on a 12-hour clock (01-12).
		 %j	   The day of the current year (001-366).
		 %m	   The month of the current year (01-12).
		 %M	   The minute of the current hour (00-59).
		 %S	   The second of the current minute.
			   60 represents a leap second. (00-60)
		 %U	   The week number of the current year (00-53).
		 %w	   The day of the current week. 0 is Sunday. (0-6)
		 %y	   The last two digits of the current year (00-99)
		 %Y	   The current year.

	      Unknown format specifiers will be ignored and copied to the output as-is.

	      If no explicit <format string> is given it will default to:

		 %Y-%m-%dT%H:%M:%S    for local time.
		 %Y-%m-%dT%H:%M:%SZ   for UTC.

       target_compile_definitions
	      Add compile definitions to a target.

		target_compile_definitions(<target> <INTERFACE|PUBLIC|PRIVATE> [items1...]
		  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

	      Specify compile definitions to use when compiling a given target.  The named  <tar-
	      get>  must have been created by a command such as add_executable or add_library and
	      must not be an IMPORTED target.  The INTERFACE, PUBLIC  and  PRIVATE  keywords  are
	      required to specify the scope of the following arguments.  PRIVATE and PUBLIC items
	      will populate the COMPILE_DEFINITIONS property of <target>.  PUBLIC  and	INTERFACE
	      items  will  populate the INTERFACE_COMPILE_DEFINITIONS property of <target>.   The
	      following arguments specify compile definitions.	Repeated calls for the same <tar-
	      get> append items in the order called.

	      Arguments  to  target_compile_definitions  may use "generator expressions" with the
	      syntax "$<...>".	Generator expressions are evaluted during build system generation
	      to  produce  information	specific  to each build configuration.	Valid expressions
	      are:

		$<0:...>		  = empty string (ignores "...")
		$<1:...>		  = content of "..."
		$<CONFIG:cfg>		  = '1' if config is "cfg", else '0'
		$<CONFIGURATION>	  = configuration name
		$<BOOL:...>		  = '1' if the '...' is true, else '0'
		$<STREQUAL:a,b> 	  = '1' if a is STREQUAL b, else '0'
		$<ANGLE-R>		  = A literal '>'. Used to compare strings which contain a '>' for example.
		$<COMMA>		  = A literal ','. Used to compare strings which contain a ',' for example.
		$<SEMICOLON>		  = A literal ';'. Used to prevent list expansion on an argument with ';'.
		$<TARGET_NAME:...>	  = Marks ... as being the name of a target.  This is required if exporting targets to multiple dependent export sets.	The '...' must be a literal name of a target- it may not contain generator expressions.
		$<INSTALL_INTERFACE:...>  = content of "..." when the property is exported using install(EXPORT), and empty otherwise.
		$<BUILD_INTERFACE:...>	  = content of "..." when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
		$<TARGET_FILE:tgt>	  = main file (.exe, .so.1.2, .a)
		$<TARGET_LINKER_FILE:tgt> = file used to link (.a, .lib, .so)
		$<TARGET_SONAME_FILE:tgt> = file with soname (.so.3)

	      where "tgt" is the name of a target.  Target file expressions produce a full  path,
	      but _DIR and _NAME versions can produce the directory and file name components:

		$<TARGET_FILE_DIR:tgt>/$<TARGET_FILE_NAME:tgt>
		$<TARGET_LINKER_FILE_DIR:tgt>/$<TARGET_LINKER_FILE_NAME:tgt>
		$<TARGET_SONAME_FILE_DIR:tgt>/$<TARGET_SONAME_FILE_NAME:tgt>

		$<TARGET_PROPERTY:tgt,prop>   = The value of the property prop on the target tgt.

	      Note  that tgt is not added as a dependency of the target this expression is evalu-
	      ated on.

		$<TARGET_POLICY:pol>	      = '1' if the policy was NEW when the 'head' target was created, else '0'.  If the policy was not set, the warning message for the policy will be emitted.  This generator expression only works for a subset of policies.
		$<INSTALL_PREFIX>	  = Content of the install prefix when the target is exported via INSTALL(EXPORT) and empty otherwise.

	      Boolean expressions:

		$<AND:?[,?]...> 	  = '1' if all '?' are '1', else '0'
		$<OR:?[,?]...>		  = '0' if all '?' are '0', else '1'
		$<NOT:?>		  = '0' if '?' is '1', else '1'

	      where '?' is always either '0' or '1'.

	      Expressions with an implicit 'this' target:

		$<TARGET_PROPERTY:prop>   = The value of the property prop on the target on which the generator expression is evaluated.

       target_include_directories
	      Add include directories to a target.

		target_include_directories(<target> [BEFORE] <INTERFACE|PUBLIC|PRIVATE> [items1...]
		  [<INTERFACE|PUBLIC|PRIVATE> [items2...] ...])

	      Specify include directories or targets to use when compiling a given  target.   The
	      named  <target>  must  have  been  created  by  a command such as add_executable or
	      add_library and must not be an IMPORTED target.

	      If BEFORE is specified, the content will be prepended to the  property  instead  of
	      being appended.

	      The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the
	      following arguments.  PRIVATE and PUBLIC items will populate  the  INCLUDE_DIRECTO-
	      RIES  property  of  <target>.   PUBLIC and INTERFACE items will populate the INTER-
	      FACE_INCLUDE_DIRECTORIES property of <target>.   The  following  arguments  specify
	      include  directories.  Specified include directories may be absolute paths or rela-
	      tive paths.  Repeated calls for the same <target> append items in the order called.

	      Arguments to target_include_directories may use "generator  expressions"	with  the
	      syntax "$<...>".	Generator expressions are evaluted during build system generation
	      to produce information specific to each  build  configuration.   Valid  expressions
	      are:

		$<0:...>		  = empty string (ignores "...")
		$<1:...>		  = content of "..."
		$<CONFIG:cfg>		  = '1' if config is "cfg", else '0'
		$<CONFIGURATION>	  = configuration name
		$<BOOL:...>		  = '1' if the '...' is true, else '0'
		$<STREQUAL:a,b> 	  = '1' if a is STREQUAL b, else '0'
		$<ANGLE-R>		  = A literal '>'. Used to compare strings which contain a '>' for example.
		$<COMMA>		  = A literal ','. Used to compare strings which contain a ',' for example.
		$<SEMICOLON>		  = A literal ';'. Used to prevent list expansion on an argument with ';'.
		$<TARGET_NAME:...>	  = Marks ... as being the name of a target.  This is required if exporting targets to multiple dependent export sets.	The '...' must be a literal name of a target- it may not contain generator expressions.
		$<INSTALL_INTERFACE:...>  = content of "..." when the property is exported using install(EXPORT), and empty otherwise.
		$<BUILD_INTERFACE:...>	  = content of "..." when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
		$<TARGET_FILE:tgt>	  = main file (.exe, .so.1.2, .a)
		$<TARGET_LINKER_FILE:tgt> = file used to link (.a, .lib, .so)
		$<TARGET_SONAME_FILE:tgt> = file with soname (.so.3)

	      where  "tgt" is the name of a target.  Target file expressions produce a full path,
	      but _DIR and _NAME versions can produce the directory and file name components:

		$<TARGET_FILE_DIR:tgt>/$<TARGET_FILE_NAME:tgt>
		$<TARGET_LINKER_FILE_DIR:tgt>/$<TARGET_LINKER_FILE_NAME:tgt>
		$<TARGET_SONAME_FILE_DIR:tgt>/$<TARGET_SONAME_FILE_NAME:tgt>

		$<TARGET_PROPERTY:tgt,prop>   = The value of the property prop on the target tgt.

	      Note that tgt is not added as a dependency of the target this expression is  evalu-
	      ated on.

		$<TARGET_POLICY:pol>	      = '1' if the policy was NEW when the 'head' target was created, else '0'.  If the policy was not set, the warning message for the policy will be emitted.  This generator expression only works for a subset of policies.
		$<INSTALL_PREFIX>	  = Content of the install prefix when the target is exported via INSTALL(EXPORT) and empty otherwise.

	      Boolean expressions:

		$<AND:?[,?]...> 	  = '1' if all '?' are '1', else '0'
		$<OR:?[,?]...>		  = '0' if all '?' are '0', else '1'
		$<NOT:?>		  = '0' if '?' is '1', else '1'

	      where '?' is always either '0' or '1'.

	      Expressions with an implicit 'this' target:

		$<TARGET_PROPERTY:prop>   = The value of the property prop on the target on which the generator expression is evaluated.

       target_link_libraries
	      Link a target to given libraries.

		target_link_libraries(<target> [item1 [item2 [...]]]
				      [[debug|optimized|general] <item>] ...)

	      Specify  libraries or flags to use when linking a given target.  The named <target>
	      must have been created in the current directory by a command such as add_executable
	      or  add_library.	The remaining arguments specify library names or flags.  Repeated
	      calls for the same <target> append items in the order called.

	      If a library name matches that of another target in the project a  dependency  will
	      automatically be added in the build system to make sure the library being linked is
	      up-to-date before the target links.  Item names starting with '-', but not '-l'  or
	      '-framework', are treated as linker flags.

	      A "debug", "optimized", or "general" keyword indicates that the library immediately
	      following it is to be used only for the  corresponding  build  configuration.   The
	      "debug"  keyword corresponds to the Debug configuration (or to configurations named
	      in the DEBUG_CONFIGURATIONS global property if it is set).  The "optimized" keyword
	      corresponds  to all other configurations.  The "general" keyword corresponds to all
	      configurations, and is purely optional (assumed if  omitted).   Higher  granularity
	      may  be  achieved  for  per-configuration rules by creating and linking to IMPORTED
	      library targets.	See the IMPORTED mode of the add_library command for more  infor-
	      mation.

	      Library  dependencies  are  transitive by default.  When this target is linked into
	      another target then the libraries linked to this target will  appear  on	the  link
	      line for the other target too.  See the LINK_INTERFACE_LIBRARIES target property to
	      override the set of transitive link dependencies for a target.  Calls to other sig-
	      natures  of  this  command  may set the property making any libraries linked exclu-
	      sively by this signature private.

	      CMake will also propagate "usage requirements" from linked library targets.   Usage
	      requirements  affect compilation of sources in the <target>.  They are specified by
	      properties defined on linked targets.  During generation of the build system, CMake
	      integrates  usage  requirement property values with the corresponding build proper-
	      ties for <target>:

	       INTERFACE_COMPILE_DEFINITONS: Appends to COMPILE_DEFINITONS
	       INTERFACE_INCLUDE_DIRECTORIES: Appends to INCLUDE_DIRECTORIES
	       INTERFACE_POSITION_INDEPENDENT_CODE: Sets POSITION_INDEPENDENT_CODE
		 or checked for consistency with existing value

		target_link_libraries(<target> LINK_INTERFACE_LIBRARIES
				      [[debug|optimized|general] <lib>] ...)

	      The  LINK_INTERFACE_LIBRARIES  mode  appends  the  libraries  to	the   LINK_INTER-
	      FACE_LIBRARIES  and  its	per-configuration equivalent target properties instead of
	      using them for linking.	Libraries  specified  as  "debug"  are	appended  to  the
	      LINK_INTERFACE_LIBRARIES_DEBUG property (or to the properties corresponding to con-
	      figurations listed in the DEBUG_CONFIGURATIONS  global  property	if  it	is  set).
	      Libraries  specified  as	"optimized"  are appended to the LINK_INTERFACE_LIBRARIES
	      property.  Libraries specified as "general" (or without any keyword) are treated as
	      if specified for both "debug" and "optimized".

		target_link_libraries(<target>
				      <LINK_PRIVATE|LINK_PUBLIC>
					[[debug|optimized|general] <lib>] ...
				      [<LINK_PRIVATE|LINK_PUBLIC>
					[[debug|optimized|general] <lib>] ...])

	      The  LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the link depen-
	      dencies and the link interface in one command.   Libraries  and  targets	following
	      LINK_PUBLIC  are	linked	to,  and  are  made part of the LINK_INTERFACE_LIBRARIES.
	      Libraries and targets following LINK_PRIVATE are linked to, but are not  made  part
	      of the LINK_INTERFACE_LIBRARIES.

	      The  library dependency graph is normally acyclic (a DAG), but in the case of mutu-
	      ally-dependent STATIC libraries CMake allows the graph to contain cycles	(strongly
	      connected  components).	When  another  target links to one of the libraries CMake
	      repeats the entire connected component.  For example, the code

		add_library(A STATIC a.c)
		add_library(B STATIC b.c)
		target_link_libraries(A B)
		target_link_libraries(B A)
		add_executable(main main.c)
		target_link_libraries(main A)

	      links 'main' to 'A B A B'.  (While one repetition is usually sufficient, pathologi-
	      cal  object  file  and  symbol  arrangements can require more.  One may handle such
	      cases by manually repeating the component in the last  target_link_libraries  call.
	      However,	if two archives are really so interdependent they should probably be com-
	      bined into a single archive.)

	      Arguments to target_link_libraries may use "generator expressions" with the  syntax
	      "$<...>".   Note	however,  that generator expressions will not be used in OLD han-
	      dling of CMP0003 or CMP0004.

	      Generator expressions are evaluted during build system generation to produce infor-
	      mation specific to each build configuration.  Valid expressions are:

		$<0:...>		  = empty string (ignores "...")
		$<1:...>		  = content of "..."
		$<CONFIG:cfg>		  = '1' if config is "cfg", else '0'
		$<CONFIGURATION>	  = configuration name
		$<BOOL:...>		  = '1' if the '...' is true, else '0'
		$<STREQUAL:a,b> 	  = '1' if a is STREQUAL b, else '0'
		$<ANGLE-R>		  = A literal '>'. Used to compare strings which contain a '>' for example.
		$<COMMA>		  = A literal ','. Used to compare strings which contain a ',' for example.
		$<SEMICOLON>		  = A literal ';'. Used to prevent list expansion on an argument with ';'.
		$<TARGET_NAME:...>	  = Marks ... as being the name of a target.  This is required if exporting targets to multiple dependent export sets.	The '...' must be a literal name of a target- it may not contain generator expressions.
		$<INSTALL_INTERFACE:...>  = content of "..." when the property is exported using install(EXPORT), and empty otherwise.
		$<BUILD_INTERFACE:...>	  = content of "..." when the property is exported using export(), or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.
		$<TARGET_FILE:tgt>	  = main file (.exe, .so.1.2, .a)
		$<TARGET_LINKER_FILE:tgt> = file used to link (.a, .lib, .so)
		$<TARGET_SONAME_FILE:tgt> = file with soname (.so.3)

	      where  "tgt" is the name of a target.  Target file expressions produce a full path,
	      but _DIR and _NAME versions can produce the directory and file name components:

		$<TARGET_FILE_DIR:tgt>/$<TARGET_FILE_NAME:tgt>
		$<TARGET_LINKER_FILE_DIR:tgt>/$<TARGET_LINKER_FILE_NAME:tgt>
		$<TARGET_SONAME_FILE_DIR:tgt>/$<TARGET_SONAME_FILE_NAME:tgt>

		$<TARGET_PROPERTY:tgt,prop>   = The value of the property prop on the target tgt.

	      Note that tgt is not added as a dependency of the target this expression is  evalu-
	      ated on.

		$<TARGET_POLICY:pol>	      = '1' if the policy was NEW when the 'head' target was created, else '0'.  If the policy was not set, the warning message for the policy will be emitted.  This generator expression only works for a subset of policies.
		$<INSTALL_PREFIX>	  = Content of the install prefix when the target is exported via INSTALL(EXPORT) and empty otherwise.

	      Boolean expressions:

		$<AND:?[,?]...> 	  = '1' if all '?' are '1', else '0'
		$<OR:?[,?]...>		  = '0' if all '?' are '0', else '1'
		$<NOT:?>		  = '0' if '?' is '1', else '1'

	      where '?' is always either '0' or '1'.

	      Expressions with an implicit 'this' target:

		$<TARGET_PROPERTY:prop>   = The value of the property prop on the target on which the generator expression is evaluated.

       try_compile
	      Try building some code.

		try_compile(RESULT_VAR <bindir> <srcdir>
			    <projectName> [targetName] [CMAKE_FLAGS flags...]
			    [OUTPUT_VARIABLE <var>])

	      Try  building  a	project.   In  this  form, srcdir should contain a complete CMake
	      project with a CMakeLists.txt file and all sources. The bindir and srcdir will  not
	      be deleted after this command is run. Specify targetName to build a specific target
	      instead of the 'all' or 'ALL_BUILD' target.

		try_compile(RESULT_VAR <bindir> <srcfile>
			    [CMAKE_FLAGS flags...]
			    [COMPILE_DEFINITIONS flags...]
			    [LINK_LIBRARIES libs...]
			    [OUTPUT_VARIABLE <var>]
			    [COPY_FILE <fileName>])

	      Try building a source file into an executable.  In this form  the  user  need  only
	      supply  a  source  file  that defines a 'main'.  CMake will create a CMakeLists.txt
	      file to build the source as an executable.  Specify COPY_FILE to get a copy of  the
	      linked executable at the given fileName.

	      In  this	version all files in bindir/CMakeFiles/CMakeTmp will be cleaned automati-
	      cally. For debugging, --debug-trycompile can be  passed  to  cmake  to  avoid  this
	      clean. However, multiple sequential try_compile operations reuse this single output
	      directory. If you use --debug-trycompile, you can only debug one	try_compile  call
	      at a time. The recommended procedure is to configure with cmake all the way through
	      once, then delete the cache entry associated with the try_compile call of interest,
	      and then re-run cmake again with --debug-trycompile.

	      Some  extra flags that can be included are,  INCLUDE_DIRECTORIES, LINK_DIRECTORIES,
	      and LINK_LIBRARIES.  COMPILE_DEFINITIONS are -Ddefinition that will  be  passed  to
	      the compile line.

	      The  srcfile  signature  also accepts a LINK_LIBRARIES argument which may contain a
	      list of libraries or IMPORTED targets which will be  linked  to  in  the	generated
	      project.	 If  LINK_LIBRARIES  is specified as a parameter to try_compile, then any
	      LINK_LIBRARIES passed as CMAKE_FLAGS will be ignored.

	      try_compile creates a CMakeList.txt file on the fly that looks like this:

		add_definitions( <expanded COMPILE_DEFINITIONS from calling cmake>)
		include_directories(${INCLUDE_DIRECTORIES})
		link_directories(${LINK_DIRECTORIES})
		add_executable(cmTryCompileExec sources)
		target_link_libraries(cmTryCompileExec ${LINK_LIBRARIES})

	      In both versions of the command, if OUTPUT_VARIABLE is specified, then  the  output
	      from  the  build process is stored in the given variable. The success or failure of
	      the try_compile, i.e. TRUE  or  FALSE  respectively,  is	returned  in  RESULT_VAR.
	      CMAKE_FLAGS  can	be  used  to pass -DVAR:TYPE=VALUE flags to the cmake that is run
	      during the build. Set variable CMAKE_TRY_COMPILE_CONFIGURATION to  choose  a  build
	      configuration.

       try_run
	      Try compiling and then running some code.

		try_run(RUN_RESULT_VAR COMPILE_RESULT_VAR
			bindir srcfile [CMAKE_FLAGS <Flags>]
			[COMPILE_DEFINITIONS <flags>]
			[COMPILE_OUTPUT_VARIABLE comp]
			[RUN_OUTPUT_VARIABLE run]
			[OUTPUT_VARIABLE var]
			[ARGS <arg1> <arg2>...])

	      Try  compiling  a  srcfile.   Return  TRUE  or FALSE for success or failure in COM-
	      PILE_RESULT_VAR.	Then if the compile succeeded, run the executable and return  its
	      exit  code  in RUN_RESULT_VAR. If the executable was built, but failed to run, then
	      RUN_RESULT_VAR will be set to FAILED_TO_RUN. COMPILE_OUTPUT_VARIABLE specifies  the
	      variable where the output from the compile step goes. RUN_OUTPUT_VARIABLE specifies
	      the variable where the output from the running executable goes.

	      For compatibility reasons OUTPUT_VARIABLE is still supported, which gives  you  the
	      output from the compile and run step combined.

	      Cross compiling issues

	      When  cross  compiling, the executable compiled in the first step usually cannot be
	      run on the build host. try_run() checks the CMAKE_CROSSCOMPILING variable to detect
	      whether  CMake  is in crosscompiling mode. If that's the case, it will still try to
	      compile the executable, but it will not try to run the executable. Instead it  will
	      create  cache  variables	which must be filled by the user or by presetting them in
	      some CMake script file to the values the executable would have produced if  it  had
	      been  run on its actual target platform. These variables are RUN_RESULT_VAR (expla-
	      nation see above) and if RUN_OUTPUT_VARIABLE  (or  OUTPUT_VARIABLE)  was	used,  an
	      additional cache variable RUN_RESULT_VAR__COMPILE_RESULT_VAR__TRYRUN_OUTPUT.This is
	      intended to hold stdout and stderr from the executable.

	      In order to make cross compiling your project easier, use try_run  only  if  really
	      required.  If you use try_run, use RUN_OUTPUT_VARIABLE (or OUTPUT_VARIABLE) only if
	      really required. Using them will require that when crosscompiling, the cache  vari-
	      ables  will  have  to be set manually to the output of the executable. You can also
	      "guard"  the  calls  to  try_run	with  if(CMAKE_CROSSCOMPILING)	and  provide   an
	      easy-to-preset alternative for this case.

	      Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build configuration.

       unset  Unset a variable, cache variable, or environment variable.

		unset(<variable> [CACHE])

	      Removes the specified variable causing it to become undefined.  If CACHE is present
	      then the variable is removed from the cache instead of the current scope.

	      <variable> can be an environment variable such as:

		unset(ENV{LD_LIBRARY_PATH})

	      in which case the variable will be removed from the current environment.

       variable_watch
	      Watch the CMake variable for change.

		variable_watch(<variable name> [<command to execute>])

	      If the specified variable changes, the message will be printed about  the  variable
	      being  changed. If the command is specified, the command will be executed. The com-
	      mand will receive the  following	arguments:  COMMAND(<variable>	<access>  <value>
	      <current list file> <stack>)

       while  Evaluate a group of commands while a condition is true

		while(condition)
		  COMMAND1(ARGS ...)
		  COMMAND2(ARGS ...)
		  ...
		endwhile(condition)

	      All  commands  between  while  and the matching endwhile are recorded without being
	      invoked.	Once the endwhile is evaluated, the recorded list of commands is  invoked
	      as  long	as the condition is true. The condition is evaluated using the same logic
	      as the if command.

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

       Redistribution and use in source and binary forms, with or without modification, are  per-
       mitted provided that the following conditions are met:

       Redistributions of source code must retain the above copyright notice, this list of condi-
       tions 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 pro-
       vided 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 permission.

       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 PARTICULAR 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 SUBSTI-
       TUTE  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
       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 questions.

       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 post-
	      ing questions to the list.

cmake 2.8.11				  June 10, 2014 			 cmakecommands(1)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 08:04 AM.