ccmake man page on Oracle

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

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 config‐
       uration settings may  be	 specified  interactively  through  this  GUI.
       Brief  instructions are provided at the bottom 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 sup‐
	      ported.  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 plat‐
	      forms.   A  makefile  generator  is responsible for generating a
	      particular build system.	Possible generator 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 CMake‐
	      Lists.txt files.

       -Wdev  Enable developer warnings.

	      Enable warnings that are meant for  the  author  of  the	CMake‐
	      Lists.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 specified, 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 ver‐
	      sions  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	direc‐
	      tory  and	 in every subdirectory which features a CMakeLists.txt
	      file containing a PROJECT() call. Additionally  a	 hierarchy  of
	      makefiles	 is  generated	into  the build tree.  The appropriate
	      make program can build the project through the default make tar‐
	      get.  A "make install" target is also provided.

       CodeBlocks - Unix Makefiles
	      Generates CodeBlocks project files.

	      Project  files  for CodeBlocks will be created in the top direc‐
	      tory and in every subdirectory which features  a	CMakeLists.txt
	      file  containing	a  PROJECT() call. Additionally a hierarchy of
	      makefiles is generated into the  build  tree.   The  appropriate
	      make program can build the project through the default make tar‐
	      get.  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.Additionally  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.Additionally 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	direc‐
	      tory  and	 in every subdirectory 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 direc‐
	      tory and in every subdirectory 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 CMake‐
	      Lists.txt file containing a PROJECT() call.  Additionally	 Make‐
	      files  (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	CMake‐
	      Lists.txt	 file  containing a PROJECT() call. Additionally Make‐
	      files (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.	 Prop‐
       erties  can  have  different  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 cus‐
       tomized.

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 tar‐
	      get 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	direc‐
	      tory.  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  executable. This is useful for performing an opera‐
	      tion before or after building the target.	 The  command  becomes
	      part  of the target and will only execute when the target 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 target. When the command will happen is determined
	      by which of the following is specified:

		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 Stu‐
	      dio 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, WORK‐
	      ING_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 specific because there is no pro‐
	      tection 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 depen‐
	      dencies of an input file.	 The language given specifies the pro‐
	      gramming language whose corresponding dependency scanner	should
	      be  used.	  Currently  only C and CXX language scanners are sup‐
	      ported. 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 supported only for
	      Makefile generators and will be ignored by other generators.

	      If COMMAND specifies an executable target (created  by  ADD_EXE‐
	      CUTABLE)	it  will  automatically be replaced by the location of
	      the executable created  at  build	 time.	 Additionally  a  tar‐
	      get-level dependency will be added so that the executable target
	      will be built before any target using this custom command.  How‐
	      ever  this does NOT add a file-level dependency that would cause
	      the custom command to re-run whenever the executable  is	recom‐
	      piled.

	      Arguments	 to  COMMAND  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 evaluated 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 tar‐
	      get-level dependencies, 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  tar‐
	      get-level dependency is created to make sure the target is built
	      before any target 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 com‐
	      mands. 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 tar‐
	      get. 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 cor‐
	      responding 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. Dependencies  listed  with  the  DEPENDS
	      argument may reference files and outputs of custom commands cre‐
	      ated with add_custom_command() in	 the  same  directory  (CMake‐
	      Lists.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 specific because there is no pro‐
	      tection 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 cur‐
	      rent directory and below.	 This command can be used to  add  any
	      flags,  but it was originally intended to add preprocessor defi‐
	      nitions.	Flags beginning in -D or /D that look like  preproces‐
	      sor  definitions	are automatically added to the COMPILE_DEFINI‐
	      TIONS 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 COM‐
	      PILE_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 dependencies with this command can
	      be used to make sure one target is built before another  target.
	      Dependencies  added  to  an IMPORTED target are followed transi‐
	      tively in its place since the target itself does not build.  See
	      the  DEPENDS  option of ADD_CUSTOM_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>  cor‐
	      responds	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	 corresponding	to  the source tree directory in which
	      the command was invoked.	See documentation of the  RUNTIME_OUT‐
	      PUT_DIRECTORY target property to change this location.  See doc‐
	      umentation 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 visibility.  It
	      may be referenced like any  target  built	 within	 the  project.
	      IMPORTED	executables  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 con‐
	      structed 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 created.  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 POSITION_INDEPEN‐
	      DENT_CODE target property is set to TRUE automatically.

	      By default the library file will be created in  the  build  tree
	      directory	 corresponding	to  the source tree directory in which
	      the command was invoked.	See documentation of the  ARCHIVE_OUT‐
	      PUT_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 signature:

		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_LOCA‐
	      TION (and its per-configuration version  IMPORTED_LOCATION_<CON‐
	      FIG>)  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  targets  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  exe‐
	      cutable  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 gen‐
	      erating 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	$<TAR‐
	      GET_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 speci‐
	      fied,  the  value	 of  source_dir, before expanding any relative
	      path, will be used (the typical usage). The CMakeLists.txt  file
	      in  the specified source directory 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  par‐
	      ent  directory by default, and will be excluded from IDE project
	      files.  Users must explicitly build targets in the subdirectory.
	      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 dependency.

       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	 argu‐
	      ments.   Exename	can  be	 either	 an  executable	 built by this
	      project or an arbitrary 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_exe‐
	      cutable) it will automatically 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 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 evaluated 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 configuration 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_GENERA‐
	      TOR.

	      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 compatibility. Use the first signature instead.

	      Sets the given <cachevariable> to a string containing  the  com‐
	      mand to build this project from the root of the build tree using
	      the build tool given by <makecommand>.  <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 speci‐
	      fied.  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 mechanism 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.	 Documentation 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	speci‐
	      fied  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 versions 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
	      features 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 automatically for each sub‐
	      directory to protect its parents and siblings.  CMake also  man‐
	      ages  a new entry for scripts loaded by include() and find_pack‐
	      age() commands except  when  invoked  with  the  NO_POLICY_SCOPE
	      option (see also policy CMP0011).	 The cmake_policy command pro‐
	      vides 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 cre‐
	      ated 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 direc‐
	      tory.  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 speci‐
	      fied, 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  con‐
	      sidered 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 executable.  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  program.	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 FUNC‐
	      TION 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	 vari‐
	      able  CMAKE_TESTDRIVER_BEFORE_TESTMAIN  can  be set to have code
	      that will be placed directly before calling the test main	 func‐
	      tion.    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 commands.  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 following:

		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 command.  DIRECTORY	 scope	chains
	      to GLOBAL.  TARGET, SOURCE, and TEST chain to DIRECTORY.

	      The  BRIEF_DOCS and FULL_DOCS options are followed by strings to
	      be associated with the property as its brief and full documenta‐
	      tion.   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 func‐
	      tion) 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 stan‐
	      dard 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 TIME‐
	      OUT is given the child processes will be terminated if  they  do
	      not  finish  in  the  specified number 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
	      integer 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 stan‐
	      dard  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
	      precedence 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 compatibil‐
	      ity.

       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 <names‐
	      pace> 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|ARCHIVE)_OUTPUT_(NAME|DIREC‐
	      TORY)(_<CONFIG>)?", "(IMPLIB_)?(PREFIX|SUFFIX)", or "LINKER_LAN‐
	      GUAGE".  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 reg‐
	      istry 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  current
	      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 config‐
	      ure_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 vari‐
	      able. 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  maximum 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. Typical 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 expressions, but much simpler.  If	 RELA‐
	      TIVE  flag  is  specified for an expression, the results will be
	      returned as a relative path to the given path.  (We do not  rec‐
	      ommend  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	traverse all the subdirectories of the matched
	      directory and match the files. Subdirectories 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 information.

	      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 directories

	      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 win‐
	      dows 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 speci‐
	      fied, the operation will timeout after time seconds, time should
	      be specified as an integer. The INACTIVITY_TIMEOUT specifies  an
	      integer  number  of seconds of inactivity after which the opera‐
	      tion should terminate. If EXPECTED_HASH ALGO=value is specified,
	      the operation will verify that the downloaded 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 speci‐
	      fied  as an integer. The INACTIVITY_TIMEOUT specifies an integer
	      number 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  com‐
	      plete.

	      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 destina‐
	      tion  is	evaluated with respect to the current build directory.
	      Copying preserves input file timestamps,	and  optimizes	out  a
	      file  if	it  exists at the destination with the same timestamp.
	      Copying preserves input permissions unless explicit  permissions
	      or  NO_SOURCE_PERMISSIONS	 are given (default is USE_SOURCE_PER‐
	      MISSIONS).  See the install(DIRECTORY) command for documentation
	      of permissions, PATTERN, REGEX, and EXCLUDE options.

	      The INSTALL signature differs slightly from COPY: it prints sta‐
	      tus messages, and NO_SOURCE_PERMISSIONS is  default.   Installa‐
	      tion  scripts generated by the install() command use this signa‐
	      ture (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	suffi‐
	      cient  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 com‐
	      mand.  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>-NOTFOUND,  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 loca‐
	      tions  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	 vari‐
	      ables.  These are intended to be set in the user's shell config‐
	      uration.	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  pro‐
	      vided 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_SYSTEM_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 vari‐
	      able    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 loca‐
	      tions. 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 direc‐
	      tories will be searched.

	      The  default  search  order  is  designed to be most-specific to
	      least-specific for common use cases.  Projects may override  the
	      order by simply calling the command multiple 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 suffi‐
	      cient 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 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 docu‐
	      mentation	 string	 in  the cache.	 PATH_SUFFIXES specifies addi‐
	      tional 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	 vari‐
	      ables.  These are intended to be set in the user's shell config‐
	      uration.	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  pro‐
	      vided 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_SYSTEM_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 vari‐
	      able    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 loca‐
	      tions. 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 direc‐
	      tories will be searched.

	      The  default  search  order  is  designed to be most-specific to
	      least-specific for common use cases.  Projects may override  the
	      order by simply calling the command multiple 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 com‐
	      mand 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 com‐
	      mand 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.	<pack‐
	      age>_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  process‐
	      ing 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 compo‐
	      nent list is given to a recursive invocation inside a  find-mod‐
	      ule,  the	 corresponding	arguments  are forwarded automatically
	      from the outer call (including the EXACT	flag  for  [version]).
	      Version support is currently provided only on a package-by-pack‐
	      age 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 respon‐
	      sible for finding the package, checking the version, and produc‐
	      ing  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 com‐
	      mand 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 containing 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  configura‐
	      tion  file  names	 may  be  given using the CONFIGS option.  The
	      search procedure is specified below.  Once found, the configura‐
	      tion  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	<pack‐
	      age>_CONSIDERED_CONFIGS,	 the  associated  versions  in	<pack‐
	      age>_CONSIDERED_VERSIONS.

	      If the package configuration file cannot	be  found  CMake  will
	      generate	an error describing the problem unless the QUIET argu‐
	      ment 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 "<con‐
	      fig-file>-version.cmake" or "<config-file>Version.cmake".	 If no
	      such  version  file  is available then the configuration 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
	      variables 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  ver‐
	      sion 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  variables
	      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 proce‐
	      dure.  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  configuration  files are encouraged to name and install
	      them such that the procedure outlined below will find them with‐
	      out 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 directories 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 cor‐
	      responds 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	speci‐
	      fied  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 provide 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 conven‐
	      tion,  so	 all (W) and (U) directories are still searched on all
	      platforms.  Directories marked with (A) are intended for instal‐
	      lations	 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 fol‐
	      lowing 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 vari‐
	      ables.  These are intended to be set in the user's shell config‐
	      uration.	 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_SYSTEM_ENVIRONMENT_PATH is passed.	 Path  entries
	      ending in "/bin" or "/sbin" are automatically 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 depen‐
	      dent 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  Win‐
	      dows a <package> may appear under registry 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	 typi‐
	      cally hard-coded guesses.

	      On Darwin or systems supporting OS X Frameworks, the cmake vari‐
	      able    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 loca‐
	      tions. 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 direc‐
	      tories will be searched.

	      The  default  search  order  is  designed to be most-specific to
	      least-specific for common use cases.  Projects may override  the
	      order by simply calling the command multiple 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 set‐
	      ting the variable CMAKE_DISABLE_FIND_PACKAGE_<package> to	 TRUE.
	      See  the documentation for the CMAKE_DISABLE_FIND_PACKAGE_<pack‐
	      age> variable for more information.

	      When  loading  a	find  module  or  package  configuration  file
	      find_package  defines variables to provide information about the
	      call arguments (and restores their original state before return‐
	      ing):

	       <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 suffi‐
	      cient 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.
	      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  sys‐
	      tem  environment	variable  to a cmake style list of paths.  For
	      example ENV PATH would be a way to list the  system  path	 vari‐
	      able.  The argument after DOC will be used for the documentation
	      string in the cache.  PATH_SUFFIXES specifies additional	subdi‐
	      rectories 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 vari‐
	      ables.  These are intended to be set in the user's shell config‐
	      uration.	 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 pro‐
	      vided 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_SYSTEM_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 vari‐
	      able     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	 loca‐
	      tions.  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 direc‐
	      tories will be searched.

	      The default search order is  designed  to	 be  most-specific  to
	      least-specific  for common use cases.  Projects may override the
	      order by simply calling the command multiple 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 framework search will look for A.framework/Head‐
	      ers/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	suffi‐
	      cient 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 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 docu‐
	      mentation string in the cache.   PATH_SUFFIXES  specifies	 addi‐
	      tional 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 vari‐
	      ables.  These are intended to be set in the user's shell config‐
	      uration.	 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 pro‐
	      vided 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_SYSTEM_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 vari‐
	      able     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	 loca‐
	      tions.  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 direc‐
	      tories will be searched.

	      The default search order is  designed  to	 be  most-specific  to
	      least-specific  for common use cases.  Projects may override the
	      order by simply calling the command multiple 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	evalu‐
	      ated,  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  variables 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 func‐
	      tion are first modified by replacing formal parameters (${arg1})
	      with  the arguments passed, and then invoked as normal commands.
	      In addition to referencing the formal parameters you can	refer‐
	      ence  the variable 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	 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 prop‐
	      erty 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  COM‐
	      PONENTS.

	      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  PRO‐
	      GRAM,  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 documenta‐
	      tion  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_target_properties  to  set
	      property	values.	  Properties are usually used to control how a
	      target is built, but some query the target instead.   This  com‐
	      mand  can get properties for any target so far created. The tar‐
	      gets 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 com‐
	      mands 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 fol‐
	      lowed 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 num‐
	      ber.  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 vari‐
	      ables.)

		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. Behavior is well-defined only for full paths. If
	      the file time stamps are exactly the same, an IS_NEWER_THAN com‐
	      parison  returns	true,  so  that any dependent build operations
	      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 lexicographi‐
	      cally 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 parenthesis the innermost are
	      evaluated as part of evaluating  the  expression	that  contains
	      them.

	      The  if  command was written very early in CMake's history, pre‐
	      dating the ${} variable evaluation syntax, and  for  convenience
	      evaluates variables named by its arguments 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 signature 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  STR‐
	      GREATER  are  independently  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 VER‐
	      SION_EQUAL VERSION_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 dereferenced.

	      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  val‐
	      ues 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  prepending,
	      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	system
	      files not being considered in dependency calculations - see com‐
	      piler 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 cre‐
	      ate 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  genera‐
	      tor.

       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 installation.  The order across direc‐
	      tories is not defined.

	      There are multiple signatures for this command.	Some  of  them
	      define  installation  properties for files and targets.  Proper‐
	      ties 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_PRE‐
	      FIX 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 configura‐
	      tions 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  component-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 con‐
	      trolled 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,  FRAMEWORK,  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 tar‐
	      get. All Windows-based systems including Cygwin  are  DLL	 plat‐
	      forms.  The  ARCHIVE,  LIBRARY, RUNTIME, and FRAMEWORK arguments
	      change the type of target to  which  the	subsequent  properties
	      apply.   If  none	 is given the installation properties 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  properties  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 locations.	Consider hypo‐
	      thetical 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	 <pre‐
	      fix>/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  <prefix>/bin and
	      /some/full/path and its import  library  will  be	 installed  to
	      <prefix>/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 unde‐
	      fined 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 directory.   Files  installed
	      by  this	form  are  by  default	given permissions OWNER_WRITE,
	      OWNER_READ, GROUP_READ, and WORLD_READ if no  PERMISSIONS	 argu‐
	      ment 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  permissions  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 destination.	The directory structure is copied ver‐
	      batim 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  com‐
	      ponent  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_PER‐
	      MISSIONS	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 struc‐
	      ture.   If  no permissions are specified files will be given the
	      default permissions specified in the FILES form of the  command,
	      and the directories will be given the default permissions speci‐
	      fied in the PROGRAMS form of the command.

	      Installation of directories may be controlled with  fine	granu‐
	      larity  using  the  PATTERN  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  sub‐
	      set  of the files and directories encountered.  The full path to
	      each input file or directory (with forward slashes)  is  matched
	      against the expression.  A PATTERN will match only complete 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 portion 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 permis‐
	      sions, 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	direc‐
	      tory.   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 targets 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 gener‐
	      ated import file will reference only the matching target config‐
	      urations.	 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 command are inter‐
	      preted 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	 loca‐
	      tion.

	      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 variable scope. Similar to the
	      SET command, the LIST command creates new variable values 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 PARENT_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	repre‐
	      senting  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 prefixed 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 compati‐
	      bility.

       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 com‐
	      mand 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 (...).  Commands listed after macro, but before the	match‐
	      ing  endmacro, are not invoked until the macro is invoked.  When
	      it is invoked, the commands recorded in the macro are first mod‐
	      ified  by	 replacing  formal parameters (${arg1}) with the argu‐
	      ments passed, and then invoked as normal commands.  In  addition
	      to  referencing the formal parameters you can reference the val‐
	      ues ${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 creating macros with optional arguments. Addi‐
	      tionally ${ARGV} holds the list of all arguments	given  to  the
	      macro  and  ${ARGN}  holds  the  list of arguments past the last
	      expected argument. Note that the parameters to a macro and  val‐
	      ues  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 vari‐
	      able will not be displayed 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 nei‐
	      ther 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 message 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 provided, 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	 vari‐
	      ables  <projectName>_BINARY_DIR  and <projectName>_SOURCE_DIR to
	      the respective values.

	      Optionally you can specify which	languages  your	 project  sup‐
	      ports.   Example	languages 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 com‐
	      mand 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_pack‐
	      age()), it causes processing of the current  file	 to  stop  and
	      control  is returned to the including file. If it is encountered
	      in a file which is not included by another file, e.g.  a	CMake‐
	      Lists.txt,  control 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 func‐
	      tion 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	 semicolon-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	white‐
	      space.   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 dou‐
	      ble-quoted.  Backslashes are literal unless  they	 precede  dou‐
	      ble-quotes.   See the MSDN article "Parsing C Command-Line Argu‐
	      ments" 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	<vari‐
	      able>  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 <docstring> 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 vari‐
	      able 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	 vari‐
	      able 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 lan‐
	      guages); they are not persisted across CMake runs.  Cache	 vari‐
	      ables (unless set with INTERNAL) are mostly intended for config‐
	      uration 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  normal  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  CMakeLists.txt, which is included from the parent
	      CMakeLists.txt using add_subdirectory(). Now, if the parent  and
	      the  child  project  provide the same option (for example a com‐
	      piler 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 par‐
	      ent  project. The parent project can achieve this simply by set‐
	      ting 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 prop‐
	      erties	 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 exist‐
	      ing 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	 prop‐
	      erties  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 val‐
	      ues 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 PREFIX 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 targets).	 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  logical	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  exe‐
	      cutables).

	      The  LINK_FLAGS  property	 can be used to add extra flags to the
	      link step of a target. LINK_FLAGS_<CONFIG> will add to the  con‐
	      figuration  <CONFIG>,  for  example, DEBUG, RELEASE, MINSIZEREL,
	      RELWITHDEBINFO. DEFINE_SYMBOL sets the name of the  preprocessor
	      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
	      dllexport/dllimport decorations. The COMPILE_FLAGS property sets
	      additional  compiler flags used to build sources within the tar‐
	      get.  It may also be used to pass additional preprocessor	 defi‐
	      nitions.

	      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	 spec‐
	      ify  the build version and api version respectively. When build‐
	      ing or installing appropriate symlinks are created if the	 plat‐
	      form 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  sym‐
	      links  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 semicolon-separated list specifying the rpath
	      to use in installed targets (for	platforms  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  automatic  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 relink‐
	      ing  before installation.	 INSTALL_NAME_DIR is a string specify‐
	      ing 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	version	 FindQt4.cmake
	      found. For example, "4.7.3"

	      The  PRE_INSTALL_SCRIPT  and  POST_INSTALL_SCRIPT properties are
	      the old way to specify 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 specified 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 regular 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 specified.

       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  sub‐
	      groups:

		source_group(outer\\inner ...)

	      For backwards compatibility, this command also supports the for‐
	      mat:

		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 output 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 substitute the replacement expression for the match
	      in the output.  The replace expression may refer to paren-delim‐
	      ited subexpressions of the match using \1, \2,  ...,  \9.	  Note
	      that  two	 backslashes (\\1) are required in CMake code to get a
	      backslash 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 charac‐
	      ters.

	      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 charac‐
	      ters and default alphabet is all numbers	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 expres‐
	      sions:

		 ^	   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 reg‐
	      ular 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 representa‐
	      tion to be in Coordinated 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 out‐
	      put 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 tar‐
	      get.  The named <target> 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.  PRI‐
	      VATE 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 <target> 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  informa‐
	      tion  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 evaluated 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 spec‐
	      ify the scope of the following arguments.	  PRIVATE  and	PUBLIC
	      items  will  populate  the INCLUDE_DIRECTORIES property of <tar‐
	      get>.  PUBLIC and	 INTERFACE  items  will	 populate  the	INTER‐
	      FACE_INCLUDE_DIRECTORIES	property  of <target>.	 The following
	      arguments specify include directories.  Specified include direc‐
	      tories  may be absolute paths or relative 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  informa‐
	      tion  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 evaluated 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	direc‐
	      tory  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 tar‐
	      get 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 cor‐
	      responding 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 "opti‐
	      mized" 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 information.

	      Library  dependencies are transitive by default.	When this tar‐
	      get 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	 over‐
	      ride  the	 set  of  transitive  link  dependencies for a target.
	      Calls to other signatures of this command may set	 the  property
	      making  any  libraries linked exclusively by this signature pri‐
	      vate.

	      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 sys‐
	      tem, CMake integrates usage requirement property values with the
	      corresponding build properties 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_INTERFACE_LIBRARIES and  its	 per-configuration  equivalent
	      target  properties instead of using them for linking.  Libraries
	      specified	 as  "debug"   are   appended	to   the   LINK_INTER‐
	      FACE_LIBRARIES_DEBUG  property (or to the properties correspond‐
	      ing to configurations 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  dependencies and the link interface in one com‐
	      mand.  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 mutually-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, pathological 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 proba‐
	      bly be combined into a single archive.)

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

	      Generator	 expressions  are evaluted during build system genera‐
	      tion to produce information specific to  each  build  configura‐
	      tion.  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 evaluated 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  automatically. For debugging, --debug-trycompile can be
	      passed to cmake to avoid this clean. However,  multiple  sequen‐
	      tial  try_compile operations reuse this single output directory.
	      If you use --debug-trycompile, you can only debug	 one  try_com‐
	      pile  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 speci‐
	      fied, 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_COM‐
	      PILE_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 COMPILE_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_OUT‐
	      PUT_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 com‐
	      bined.

	      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  exe‐
	      cutable.	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  (explanation  see above) and if RUN_OUTPUT_VARI‐
	      ABLE (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 variables 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  alterna‐
	      tive 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 command will receive the fol‐
	      lowing 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 condi‐
	      tion 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	 plat‐
	      form  and	 compiler  settings.   These  values are now available
	      through the CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables.

       exec_program
	      Deprecated.  Use the execute_process() command instead.

	      Run an executable program during the processing  of  the	CMake‐
	      List.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 argu‐
	      ments 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  out‐
	      put.  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  com‐
	      mand.   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-configuration names of libraries or the  LINK_INTER‐
	      FACE_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 num‐
	      ber  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 compatibility with older  CMake  code.   The	 FILES
	      form  is directly replaced by the FILES form of the install com‐
	      mand.  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 exten‐
	      sion into the given directory.  Only files existing in the  cur‐
	      rent  source  tree  or  its corresponding location in the binary
	      tree may be listed.  If a file specified already has  an	exten‐
	      sion,  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  compatibility  with  older CMake code.  The FILES
	      form is directly replaced by the PROGRAMS 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 compatibility with older CMake code.

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

	      Create rules to install the listed targets into the given direc‐
	      tory.  The directory <dir> is relative to the installation  pre‐
	      fix,  which  is  stored in the variable CMAKE_INSTALL_PREFIX. If
	      RUNTIME_DIRECTORY is specified, then  on	systems	 with  special
	      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 tar‐
	      gets  (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 directories 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  automati‐
	      cally 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 dependencies 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 directories after the
	      PREORDER	flag  are traversed first by makefile builds, the PRE‐
	      ORDER 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 useful 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 distribu‐
	      tion,  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	 util‐
	      ity_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 manually 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 mod‐
       ification, are permitted provided that  the  following  conditions  are
       met:

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

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

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

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

SEE ALSO
       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 ques‐
	      tions.

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

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

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

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

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

ccmake 2.8.11			April 30, 2014			     ccmake(1)
[top]

List of man pages available for Oracle

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

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

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