Unix/Linux Go Back    


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

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


ccmake(1)										ccmake(1)

NAME
	 ccmake - Curses Interface for CMake.

USAGE
	 ccmake <path-to-source>
	 ccmake <path-to-existing-build>

DESCRIPTION
       The "ccmake" executable is the CMake curses interface.  Project configuration settings may
       be specified interactively through this GUI.  Brief instructions are provided at the  bot-
       tom of the terminal when the program is running.

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

OPTIONS
       -C <initial-cache>
	      Pre-load a script to populate the cache.

	      When cmake is first run in an empty build tree, it creates  a  CMakeCache.txt  file
	      and  populates  it  with customizable settings for the project.  This option may be
	      used to specify a file from which to load  cache	entries  before  the  first  pass
	      through  the  project's cmake listfiles.	The loaded entries take priority over the
	      project's default values.  The given file should be a CMake script  containing  SET
	      commands that use the CACHE option, not a cache-format file.

       -D <var>:<type>=<value>
	      Create a cmake cache entry.

	      When  cmake  is  first run in an empty build tree, it creates a CMakeCache.txt file
	      and populates it with customizable settings for the project.  This  option  may  be
	      used  to	specify  a  setting that takes priority over the project's default value.
	      The option may be repeated for as many cache entries as desired.

       -U <globbing_expr>
	      Remove matching entries from CMake cache.

	      This option may be used to remove one or more  variables	from  the  CMakeCache.txt
	      file,  globbing expressions using * and ? are supported. The option may be repeated
	      for as many cache entries as desired.

	      Use with care, you can make your CMakeCache.txt non-working.

       -G <generator-name>
	      Specify a makefile generator.

	      CMake may support multiple native build systems on certain platforms.   A  makefile
	      generator is responsible for generating a particular build system.  Possible gener-
	      ator names are specified in the Generators section.

       -T <toolset-name>
	      Specify toolset name if supported by generator.

	      Some CMake generators support a toolset name to be given to the native build system
	      to choose a compiler.  This is supported only on specific generators:

		Visual Studio >= 10
		Xcode >= 3.0

	      See native build system documentation for allowed toolset names.

       -Wno-dev
	      Suppress developer warnings.

	      Suppress warnings that are meant for the author of the CMakeLists.txt files.

       -Wdev  Enable developer warnings.

	      Enable warnings that are meant for the author of the CMakeLists.txt files.

       --copyright [file]
	      Print the CMake copyright and exit.

	      If a file is specified, the copyright is written into it.

       --help,-help,-usage,-h,-H,/?
	      Print usage information and exit.

	      Usage describes the basic command line interface and its options.

       --help-full [file]
	      Print full help and exit.

	      Full  help displays most of the documentation provided by the UNIX man page.  It is
	      provided for use on non-UNIX platforms, but is also convenient if the man  page  is
	      not installed.  If a file is specified, the help is written into it.

       --help-html [file]
	      Print full help in HTML format.

	      This option is used by CMake authors to help produce web pages.  If a file is spec-
	      ified, the help is written into it.

       --help-man [file]
	      Print full help as a UNIX man page and exit.

	      This option is used by the cmake build to generate the UNIX man page.  If a file is
	      specified, the help is written into it.

       --version,-version,/V [file]
	      Show program name/version banner and exit.

	      If a file is specified, the version is written into it.

GENERATORS
       Unix Makefiles
	      Generates standard UNIX makefiles.

	      A  hierarchy  of	UNIX  makefiles  is  generated into the build tree.  Any standard
	      UNIX-style make program can build the project through the default make  target.	A
	      "make install" target is also provided.

       Ninja  Generates build.ninja files (experimental).

	      A  build.ninja  file is generated into the build tree. Recent versions of the ninja
	      program can build the project through the "all" target.	An  "install"  target  is
	      also provided.

       CodeBlocks - Ninja
	      Generates CodeBlocks project files.

	      Project files for CodeBlocks will be created in the top directory and in every sub-
	      directory which features a CMakeLists.txt file containing a PROJECT()  call.  Addi-
	      tionally	a hierarchy of makefiles is generated into the build tree.  The appropri-
	      ate make program can build the project through the default make  target.	 A  "make
	      install" target is also provided.

       CodeBlocks - Unix Makefiles
	      Generates CodeBlocks project files.

	      Project files for CodeBlocks will be created in the top directory and in every sub-
	      directory which features a CMakeLists.txt file containing a PROJECT()  call.  Addi-
	      tionally	a hierarchy of makefiles is generated into the build tree.  The appropri-
	      ate make program can build the project through the default make  target.	 A  "make
	      install" target is also provided.

       Eclipse CDT4 - Ninja
	      Generates Eclipse CDT 4.0 project files.

	      Project  files  for  Eclipse will be created in the top directory. In out of source
	      builds, a linked resource to the top level source directory will	be  created.Addi-
	      tionally a hierarchy of makefiles is generated into the build tree. The appropriate
	      make program can build the  project  through  the  default  make	target.  A  "make
	      install" target is also provided.

       Eclipse CDT4 - Unix Makefiles
	      Generates Eclipse CDT 4.0 project files.

	      Project  files  for  Eclipse will be created in the top directory. In out of source
	      builds, a linked resource to the top level source directory will	be  created.Addi-
	      tionally a hierarchy of makefiles is generated into the build tree. The appropriate
	      make program can build the  project  through  the  default  make	target.  A  "make
	      install" target is also provided.

       KDevelop3
	      Generates KDevelop 3 project files.

	      Project files for KDevelop 3 will be created in the top directory and in every sub-
	      directory which features a CMakeLists.txt file containing a PROJECT() call. If  you
	      change  the  settings  using  KDevelop cmake will try its best to keep your changes
	      when regenerating the project files. Additionally a hierarchy of UNIX makefiles  is
	      generated  into the build tree.  Any standard UNIX-style make program can build the
	      project through the default make target.	A "make install" target is also provided.

       KDevelop3 - Unix Makefiles
	      Generates KDevelop 3 project files.

	      Project files for KDevelop 3 will be created in the top directory and in every sub-
	      directory  which features a CMakeLists.txt file containing a PROJECT() call. If you
	      change the settings using KDevelop cmake will try its best  to  keep  your  changes
	      when  regenerating the project files. Additionally a hierarchy of UNIX makefiles is
	      generated into the build tree.  Any standard UNIX-style make program can build  the
	      project through the default make target.	A "make install" target is also provided.

       Sublime Text 2 - Ninja
	      Generates Sublime Text 2 project files.

	      Project  files for Sublime Text 2 will be created in the top directory and in every
	      subdirectory which features a CMakeLists.txt  file  containing  a  PROJECT()  call.
	      Additionally  Makefiles  (or  build.ninja files) are generated into the build tree.
	      The appropriate make program can build the project through the default make target.
	      A "make install" target is also provided.

       Sublime Text 2 - Unix Makefiles
	      Generates Sublime Text 2 project files.

	      Project  files for Sublime Text 2 will be created in the top directory and in every
	      subdirectory which features a CMakeLists.txt  file  containing  a  PROJECT()  call.
	      Additionally  Makefiles  (or  build.ninja files) are generated into the build tree.
	      The appropriate make program can build the project through the default make target.
	      A "make install" target is also provided.

PROPERTIES
	 CMake Properties - Properties supported by CMake, the Cross-Platform Makefile Generator.

       This  is the documentation for the properties supported by CMake. Properties can have dif-
       ferent scopes. They can either be assigned to a source file,  a	directory,  a  target  or
       globally to CMake. By modifying the values of properties the behaviour of the build system
       can be customized.

COMMAND
       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.

COMPATIBILITY COMMANDS
       build_name
	      Deprecated.  Use ${CMAKE_SYSTEM} and ${CMAKE_CXX_COMPILER} instead.

		build_name(variable)

	      Sets the specified variable to a string representing the platform and compiler set-
	      tings.  These values are now available through the CMAKE_SYSTEM and  CMAKE_CXX_COM-
	      PILER variables.

       exec_program
	      Deprecated.  Use the execute_process() command instead.

	      Run an executable program during the processing of the CMakeList.txt file.

		exec_program(Executable [directory in which to run]
			     [ARGS <arguments to executable>]
			     [OUTPUT_VARIABLE <var>]
			     [RETURN_VALUE <var>])

	      The  executable  is  run in the optionally specified directory.  The executable can
	      include arguments if it is double quoted, but it is better to use the optional ARGS
	      argument	to specify arguments to the program.   This is because cmake will then be
	      able to escape spaces in the executable path.  An optional argument OUTPUT_VARIABLE
	      specifies  a  variable in which to store the output. To capture the return value of
	      the execution, provide a RETURN_VALUE. If OUTPUT_VARIABLE  is  specified,  then  no
	      output will go to the stdout/stderr of the console running cmake.

       export_library_dependencies
	      Deprecated.  Use INSTALL(EXPORT) or EXPORT command.

	      This  command generates an old-style library dependencies file.  Projects requiring
	      CMake 2.6 or later should not use the command.   Use  instead  the  install(EXPORT)
	      command  to  help export targets from an installation tree and the export() command
	      to export targets from a build tree.

	      The old-style library dependencies file does not take into  account  per-configura-
	      tion names of libraries or the LINK_INTERFACE_LIBRARIES target property.

		export_library_dependencies(<file> [APPEND])

	      Create  a  file  named  <file>  that can be included into a CMake listfile with the
	      INCLUDE command.	The file will contain a number of SET commands that will set  all
	      the  variables  needed for library dependency information.  This should be the last
	      command in the top level CMakeLists.txt file of the project.  If the APPEND  option
	      is  specified,  the  SET	commands  will	be  appended to the given file instead of
	      replacing it.

       install_files
	      Deprecated.  Use the install(FILES ) command instead.

	      This command has been superceded by the install command.	It is provided	for  com-
	      patibility with older CMake code.  The FILES form is directly replaced by the FILES
	      form of the install command.  The regexp form can be expressed more  clearly  using
	      the GLOB form of the file command.

		install_files(<dir> extension file file ...)

	      Create  rules  to  install the listed files with the given extension into the given
	      directory.  Only files existing in the current source  tree  or  its  corresponding
	      location	in  the  binary  tree  may be listed.  If a file specified already has an
	      extension, that extension will be removed first.	 This  is  useful  for	providing
	      lists  of  source files such as foo.cxx when you want the corresponding foo.h to be
	      installed. A typical extension is '.h'.

		install_files(<dir> regexp)

	      Any files in the current source directory that match the regular expression will be
	      installed.

		install_files(<dir> FILES file file ...)

	      Any  files  listed  after  the  FILES keyword will be installed explicitly from the
	      names given.  Full paths are allowed in this form.

	      The directory <dir> is relative to the installation prefix, which is stored in  the
	      variable CMAKE_INSTALL_PREFIX.

       install_programs
	      Deprecated. Use the install(PROGRAMS ) command instead.

	      This  command  has been superceded by the install command.  It is provided for com-
	      patibility with older CMake code.  The FILES form is directly replaced by the  PRO-
	      GRAMS  form  of the INSTALL command.  The regexp form can be expressed more clearly
	      using the GLOB form of the FILE command.

		install_programs(<dir> file1 file2 [file3 ...])
		install_programs(<dir> FILES file1 [file2 ...])

	      Create rules to install the listed programs into the given directory. Use the FILES
	      argument	to  guarantee that the file list version of the command will be used even
	      when there is only one argument.

		install_programs(<dir> regexp)

	      In the second form any program in the current source  directory  that  matches  the
	      regular expression will be installed.

	      This  command  is intended to install programs that are not built by cmake, such as
	      shell scripts.  See the TARGETS form of the INSTALL command to create  installation
	      rules for targets built by cmake.

	      The  directory <dir> is relative to the installation prefix, which is stored in the
	      variable CMAKE_INSTALL_PREFIX.

       install_targets
	      Deprecated. Use the install(TARGETS )  command instead.

	      This command has been superceded by the install command.	It is provided	for  com-
	      patibility with older CMake code.

		install_targets(<dir> [RUNTIME_DIRECTORY dir] target target)

	      Create rules to install the listed targets into the given directory.  The directory
	      <dir> is relative to the installation prefix,  which  is	stored	in  the  variable
	      CMAKE_INSTALL_PREFIX.  If RUNTIME_DIRECTORY is specified, then on systems with spe-
	      cial runtime files (Windows DLL), the files will be copied to that directory.

       link_libraries
	      Deprecated. Use the target_link_libraries() command instead.

	      Link libraries to all targets added later.

		link_libraries(library1 <debug | optimized> library2 ...)

	      Specify a list of libraries to be linked	into  any  following  targets  (typically
	      added  with  the add_executable or add_library calls).  This command is passed down
	      to all subdirectories.  The debug and optimized strings may  be  used  to  indicate
	      that the next library listed is to be used only for that specific type of build.

       make_directory
	      Deprecated. Use the file(MAKE_DIRECTORY ) command instead.

		make_directory(directory)

	      Creates  the specified directory.  Full paths should be given.  Any parent directo-
	      ries that do not exist will also be created.  Use with care.

       output_required_files
	      Deprecated.  Approximate C preprocessor dependency scanning.

	      This command exists only because ancient CMake versions provided it.  CMake handles
	      preprocessor dependency scanning automatically using a more advanced scanner.

		output_required_files(srcfile outputfile)

	      Outputs  a list of all the source files that are required by the specified srcfile.
	      This list is written into outputfile. This is similar to writing out the	dependen-
	      cies for srcfile except that it jumps from .h files into .cxx, .c and .cpp files if
	      possible.

       remove Deprecated. Use the list(REMOVE_ITEM ) command instead.

		remove(VAR VALUE VALUE ...)

	      Removes VALUE from the variable VAR.  This is typically used to remove entries from
	      a vector (e.g. semicolon separated list).  VALUE is expanded.

       subdir_depends
	      Deprecated.  Does nothing.

		subdir_depends(subdir dep1 dep2 ...)

	      Does  not  do  anything.	 This command used to help projects order parallel builds
	      correctly.  This functionality is now automatic.

       subdirs
	      Deprecated. Use the add_subdirectory() command instead.

	      Add a list of subdirectories to the build.

		subdirs(dir1 dir2 ...[EXCLUDE_FROM_ALL exclude_dir1 exclude_dir2 ...]
			[PREORDER] )

	      Add a list of subdirectories to the build. The add_subdirectory command  should  be
	      used  instead  of  subdirs  although  subdirs  will still work. This will cause any
	      CMakeLists.txt files in the sub directories to be processed by CMake.  Any directo-
	      ries  after  the PREORDER flag are traversed first by makefile builds, the PREORDER
	      flag has no effect on IDE projects.  Any	directories  after  the  EXCLUDE_FROM_ALL
	      marker will not be included in the top level makefile or project file. This is use-
	      ful for having CMake create makefiles or projects  for  a  set  of  examples  in	a
	      project.	You  would  want CMake to generate makefiles or project files for all the
	      examples at the same time, but you would not want them to show up in the top  level
	      project or be built each time make is run from the top.

       use_mangled_mesa
	      Copy mesa headers for use in combination with system GL.

		use_mangled_mesa(PATH_TO_MESA OUTPUT_DIRECTORY)

	      The path to mesa includes, should contain gl_mangle.h.  The mesa headers are copied
	      to the specified output directory.  This allows mangled mesa  headers  to  override
	      other GL headers by being added to the include directory path earlier.

       utility_source
	      Specify the source tree of a third-party utility.

		utility_source(cache_entry executable_name
			       path_to_source [file1 file2 ...])

	      When  a  third-party utility's source is included in the distribution, this command
	      specifies its location and name.	The cache  entry  will	not  be  set  unless  the
	      path_to_source  and  all listed files exist.  It is assumed that the source tree of
	      the utility will have been built before it is needed.

	      When cross compiling CMake will print a warning if a  utility_source()  command  is
	      executed, because in many cases it is used to build an executable which is executed
	      later on. This doesn't work when cross compiling, since the executable can run only
	      on  their target platform. So in this case the cache entry has to be adjusted manu-
	      ally so it points to an executable which is runnable on the build host.

       variable_requires
	      Deprecated. Use the if() command instead.

	      Assert satisfaction of an option's required variables.

		variable_requires(TEST_VARIABLE RESULT_VARIABLE
				  REQUIRED_VARIABLE1
				  REQUIRED_VARIABLE2 ...)

	      The first argument (TEST_VARIABLE) is the name of the variable  to  be  tested,  if
	      that  variable  is  false  nothing else is done. If TEST_VARIABLE is true, then the
	      next argument (RESULT_VARIABLE) is a variable that  is  set  to  true  if  all  the
	      required	variables  are	set. The rest of the arguments are variables that must be
	      true or not set to NOTFOUND to avoid an error.  If any are not true,  an	error  is
	      reported.

       write_file
	      Deprecated. Use the file(WRITE ) command instead.

		write_file(filename "message to write"... [APPEND])

	      The  first  argument  is	the  file name, the rest of the arguments are messages to
	      write. If the argument APPEND is specified, then the message will be appended.

	      NOTE 1: file(WRITE ... and file(APPEND ... do exactly the same as this one but  add
	      some more functionality.

	      NOTE 2: When using write_file the produced file cannot be used as an input to CMake
	      (CONFIGURE_FILE, source file ...) because it will lead to  an  infinite  loop.  Use
	      configure_file if you want to generate input files to CMake.

MODULES
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
       cmake(1), ctest(1)

       The following resources are available to get help using CMake:

       Home Page
	      http://www.cmake.org

	      The primary starting point for learning about CMake.

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

	      A Wiki is provided containing answers to frequently asked 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.

AUTHOR
       This manual page was generated by the "--help-man" option.

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


All times are GMT -4. The time now is 06:01 PM.