cmakecommands man page on Darwin

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

cmakecommands(1)					      cmakecommands(1)

NAME
       cmakecommands - Reference of available CMake commands.

COMMANDS
       add_compile_options
	      Adds options to the compilation of source files.

		add_compile_options(<option> ...)

	      Adds  options  to	 the  compiler command line for sources in the
	      current directory and below.  This command can be	 used  to  add
	      any  options, but alternative commands exist to add preprocessor
	      definitions or include directories.  See	documentation  of  the
	      directory	 and  target  COMPILE_OPTIONS  properties for details.
	      Arguments to add_compile_options may use "generator expressions"
	      with  the	 syntax "$<...>".  Generator expressions are evaluated
	      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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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.

       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  evaluated	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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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-trivial  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.

	      The signature

		add_executable(<name> ALIAS <target>)

	      creates an alias, such that <name> can be used to refer to <tar‐
	      get>  in subsequent commands.  The <name> does not appear in the
	      generated buildsystem as a make target.  The <target> may not be
	      an  IMPORTED  target  or an ALIAS.  Alias targets can be used as
	      linkable targets, targets to read properties  from,  executables
	      for custom commands and custom targets.  They can also be tested
	      for existance  with  the	regular	 if(TARGET)  subcommand.   The
	      <name>  may  not	be used to modify properties of <target>, that
	      is, it may not be used as the operand of set_property,  set_tar‐
	      get_properties,  target_link_libraries etc.  An ALIAS target may
	      not be installed of exported.

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

	      The signature

		add_library(<name> ALIAS <target>)

	      creates an alias, such that <name> can be used to refer to <tar‐
	      get> in subsequent commands.  The <name> does not appear in  the
	      generated buildsystem as a make target.  The <target> may not be
	      an IMPORTED target or an ALIAS.  Alias targets can  be  used  as
	      linkable	targets,  targets  to  read properties from.  They can
	      also be tested for existance with the regular if(TARGET) subcom‐
	      mand.   The <name> may not be used to modify properties of <tar‐
	      get>, that is, it may not be used as the	operand	 of  set_prop‐
	      erty,   set_target_properties,  target_link_libraries  etc.   An
	      ALIAS target may not be installed of exported.

       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 ...]])

	      Add a test called <name>.	 The test name may not contain spaces,
	      quotes, or other characters special in CMake syntax.  If COMMAND
	      specifies an executable target (created  by  add_executable)  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  evaluated	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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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_host_system_information
	      Query host system specific information.

		cmake_host_system_information(RESULT <variable> QUERY <key> ...)

	      Queries system information of the host  system  on  which	 cmake
	      runs.  One  or more <key> can be provided to select the informa‐
	      tion to be queried. The list of  queried	values	is  stored  in
	      <variable>.

	      <key> can be one of the following values:

		NUMBER_OF_LOGICAL_CORES	  = Number of logical cores.
		NUMBER_OF_PHYSICAL_CORES  = Number of physical cores.
		HOSTNAME		  = Hostname.
		FQDN			  = Fully qualified domain name.
		TOTAL_VIRTUAL_MEMORY	  = Total virtual memory in megabytes.
		AVAILABLE_VIRTUAL_MEMORY  = Available virtual memory in megabytes.
		TOTAL_PHYSICAL_MEMORY	  = Total physical memory in megabytes.
		AVAILABLE_PHYSICAL_MEMORY = Available physical memory in megabytes.

       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(<lang> [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.

	      This command must be called in file scope,  not  in  a  function
	      call.   Furthermore,  it must be called in the highest directory
	      common to all targets using the named language directly for com‐
	      piling  sources  or indirectly through link dependencies.	 It is
	      simplest to enable all needed languages in the top-level	direc‐
	      tory of a project.

	      The  OPTIONAL keyword is a placeholder for future implementation
	      and does not currently 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> [EXPORT_LINK_INTERFACE_LIBRARIES])

	      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.   The
	      EXPORT_LINK_INTERFACE_LIBRARIES  keyword, if present, causes the
	      contents	of  the	 properties  matching  (IMPORTED_)?LINK_INTER‐
	      FACE_LIBRARIES(_<CONFIG>)?  to  be exported, when policy CMP0022
	      is NEW.  If a library target is included in  the	export	but  a
	      target to which it links is not included the behavior is unspec‐
	      ified.

	      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])
		file(GENERATE OUTPUT output_file
		     <INPUT input_file|CONTENT input_content>
		     [CONDITION expression])

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

	      GENERATE will  write  an	<output_file>  with  content  from  an
	      <input_file>,  or from <input_content>.  The output is generated
	      conditionally based on the content of the <condition>.  The file
	      is written at CMake generate-time and the input may contain gen‐
	      erator  expressions.    The   <condition>,   <output_file>   and
	      <input_file>  may also contain generator expressions.  The <con‐
	      dition> must evaluate to either '0' or '1'.   The	 <output_file>
	      must  evaluate  to  a  unique  name among all configurations and
	      among all invocations of file(GENERATE).

       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:

	       DIRECTORY = 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
	       PATH	 = Legacy alias for DIRECTORY (use for CMake <= 2.8.11)

	      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
	      Load and run CMake code from a file or module.

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

	      Load and run CMake code from the file given.  Variable reads and
	      writes access the scope of the  caller  (dynamic	scoping).   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>]
			 [INCLUDES 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 INCLUDES  DESTINATION	speci‐
	      fies  a  list  of	 directories which will be added to the INTER‐
	      FACE_INCLUDE_DIRECTORIES	of  the	 <targets>  when  exported  by
	      install(EXPORT).	If a relative path is specified, it is treated
	      as relative to the $<INSTALL_PREFIX>.

	      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|...]]
			[EXPORT_LINK_INTERFACE_LIBRARIES]
			[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.	  The  EXPORT_LINK_INTERFACE_LIBRARIES	 keyword,   if
	      present,	 causes	  the  contents	 of  the  properties  matching
	      (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)? to be exported,
	      when  policy CMP0022 is NEW.  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.

	      The  top-level  CMakeLists.txt file for a project must contain a
	      literal, direct call  to	the  project()	command;  loading  one
	      through  the  include()  command	is not sufficient.  If no such
	      call exists CMake will  implicitly  add  one  to	the  top  that
	      enables the default languages (C and CXX).

       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])
		string(MAKE_C_IDENTIFIER <input string> <output variable>)

	      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.

	      MAKE_C_IDENTIFIER will write a string which can be  used	as  an
	      identifier in C.

       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 evaluated 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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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_compile_options
	      Add compile options to a target.

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

	      Specify  compile	options	 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 tar‐
	      get.  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 COMPILE_OPTIONS property of <target>.
	      PUBLIC and INTERFACE  items  will	 populate  the	INTERFACE_COM‐
	      PILE_OPTIONS  property  of  <target>.    The following arguments
	      specify compile opitions.	 Repeated calls for the same  <target>
	      append items in the order called.

	      Arguments	 to  target_compile_options may use "generator expres‐
	      sions" with the  syntax  "$<...>".   Generator  expressions  are
	      evaluated	 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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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> [SYSTEM] [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.If SYSTEM
	      is  specified,  the  compiler  will  be told the directories are
	      meant as system include  directories  on	some  platforms	 (sig‐
	      nalling  this setting might achieve effects such as the compiler
	      skipping warnings, or these fixed-install system files not being
	      considered  in dependency calculations - see compiler docs).  If
	      SYSTEM is used together with PUBLIC  or  INTERFACE,  the	INTER‐
	      FACE_SYSTEM_INCLUDE_DIRECTORIES  target  property	 will be popu‐
	      lated with the specified directories.

	      Arguments	 to  target_include_directories	 may  use   "generator
	      expressions"  with  the  syntax "$<...>".	 Generator expressions
	      are evaluated 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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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 INTERFACE_LINK_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

	      If  an  <item>  is  a library in a Mac OX framework, the Headers
	      directory of the framework will also be processed	 as  a	"usage
	      requirement".  This has the same effect as passing the framework
	      directory as an include directory.   target_link_libraries(<tar‐
	      get>

				    <PRIVATE|PUBLIC|INTERFACE> <lib> ...
				    [<PRIVATE|PUBLIC|INTERFACE> <lib> ... ] ...])

	      The  PUBLIC, PRIVATE and INTERFACE keywords can be used to spec‐
	      ify both the link dependencies and the  link  interface  in  one
	      command.	 Libraries and targets following PUBLIC are linked to,
	      and are made part of the link interface.	Libraries and  targets
	      following	 PRIVATE  are  linked to, but are not made part of the
	      link interface.  Libraries following INTERFACE are  appended  to
	      the link interface and are not used for linking <target>.

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

	      The  LINK_INTERFACE_LIBRARIES  mode appends the libraries to the
	      INTERFACE_LINK_LIBRARIES target property instead of  using  them
	      for  linking.  If policy CMP0022 is not NEW, then this mode also
	      appends  libraries  to  the  LINK_INTERFACE_LIBRARIES  and   its
	      per-configuration equivalent.  This signature is for compatibil‐
	      ity only. Prefer the INTERFACE mode instead.   Libraries	speci‐
	      fied  as "debug" are wrapped in a generator expression to corre‐
	      spond to debug builds.   If  policy  CMP0022  is	not  NEW,  the
	      libraries	   are	  also	  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	 INTERFACE_LINK_LIBRARIES property.  If policy
	      CMP0022 is not NEW, they are also appended  to  the  LINK_INTER‐
	      FACE_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.  This signature is for compatibility only. Prefer the PUB‐
	      LIC or PRIVATE keywords instead.	Libraries and targets  follow‐
	      ing  LINK_PUBLIC	are linked to, and are made part of the INTER‐
	      FACE_LINK_LIBRARIES.  If policy CMP0022 is  not  NEW,  they  are
	      also  made  part of the LINK_INTERFACE_LIBRARIES.	 Libraries and
	      targets following LINK_PRIVATE are linked to, but are  not  made
	      part    of    the	  INTERFACE_LINK_LIBRARIES   (or   LINK_INTER‐
	      FACE_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 evaluated 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 ';'.
		$<JOIN:list,...>	  = joins the list with the content of "..."
		$<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.
		$<C_COMPILER_ID>	  = The CMake-id of the C compiler used.
		$<C_COMPILER_ID:comp>	  = '1' if the CMake-id of the C compiler matches comp, otherwise '0'.
		$<CXX_COMPILER_ID>	  = The CMake-id of the CXX compiler used.
		$<CXX_COMPILER_ID:comp>	  = '1' if the CMake-id of the CXX compiler matches comp, otherwise '0'.
		$<VERSION_GREATER:v1,v2>  = '1' if v1 is a version greater than v2, else '0'.
		$<VERSION_LESS:v1,v2>	  = '1' if v1 is a version less than v2, else '0'.
		$<VERSION_EQUAL:v1,v2>	  = '1' if v1 is the same version as v2, else '0'.
		$<C_COMPILER_VERSION>	  = The version of the C compiler used.
		$<C_COMPILER_VERSION:ver> = '1' if the version of the C compiler matches ver, otherwise '0'.
		$<CXX_COMPILER_VERSION>	  = The version of the CXX compiler used.
		$<CXX_COMPILER_VERSION:ver> = '1' if the version of the CXX compiler matches ver, otherwise '0'.
		$<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|SOURCES srcfile...>
			    [CMAKE_FLAGS flags...]
			    [COMPILE_DEFINITIONS flags...]
			    [LINK_LIBRARIES libs...]
			    [OUTPUT_VARIABLE <var>]
			    [COPY_FILE <fileName> [COPY_FILE_ERROR <var>]])

	      Try  building  an	 executable from one or more source files.  In
	      this form the user need only supply one  or  more	 source	 files
	      that  include  a	definition  for	 'main'.   CMake will create a
	      CMakeLists.txt file to build the	source(s)  as  an  executable.
	      Specify  COPY_FILE to get a copy of the linked executable at the
	      given fileName and optionally  COPY_FILE_ERROR  to  capture  any
	      error.

	      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.

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
       The following resources are available to get help using CMake:

       Home Page
	      http://www.cmake.org

	      The primary starting point for learning about CMake.

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

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

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

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

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

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

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

List of man pages available for Darwin

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

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

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