Provided by: cmake-data_2.8.12.2-0ubuntu3_all bug

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 target that may
              build in parallel or the two instances  of  the  rule  may  conflict  (instead  use
              add_custom_target  to  drive  the command and make the other targets depend on that
              one).  If an output name is a relative path it will be interpreted relative to  the
              build  tree  directory  corresponding  to  the  current source directory. Note that
              MAIN_DEPENDENCY is completely optional and is used as a suggestion to visual studio
              about where to hang the custom command. In makefile terms this creates a new target
              in the following form:

                OUTPUT: MAIN_DEPENDENCY DEPENDS
                        COMMAND

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

              The  second  signature  adds  a  custom  command  to  a target such as a library or
              executable. This is useful for performing an operation before or after building the
              target.  The  command  becomes  part  of  the target and will only execute when the
              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 Studio 7 or later. For
              all other generators PRE_BUILD will be treated as PRE_LINK.

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

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

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

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

              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.
              Additionally a target-level dependency will be added so that the executable  target
              will  be  built before any target using this custom command.  However this does NOT
              add a file-level dependency that would cause the custom command to re-run  whenever
              the executable is recompiled.

              Arguments  to  COMMAND  may  use  "generator expressions" with the syntax "$<...>".
              Generator expressions are 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  target-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
              target-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 commands. The target  has
              no  output  file  and  is ALWAYS CONSIDERED OUT OF DATE even if the commands try to
              create a file with the name of the target. Use  ADD_CUSTOM_COMMAND  to  generate  a
              file  with  dependencies.  By  default  nothing  depends  on the custom target. Use
              ADD_DEPENDENCIES to add dependencies to or from other targets. If the ALL option is
              specified it indicates that this target should be added to the default build target
              so that it will be run every time (the command cannot be called ALL).  The  command
              and arguments are optional and if not specified an empty target will be created. If
              WORKING_DIRECTORY is set, then the command will be run in that directory. If it  is
              a  relative  path  it  will  be  interpreted  relative  to the build tree directory
              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. Dependencies
              listed with the DEPENDS argument may reference files and outputs of custom commands
              created with add_custom_command() in the same directory (CMakeLists.txt file).

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

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

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

                add_definitions(-DFOO -DBAR ...)

              Adds flags to the compiler command line for sources in the  current  directory  and
              below.   This  command can be used to add any flags, but it was originally intended
              to add preprocessor definitions.  Flags beginning  in  -D  or  /D  that  look  like
              preprocessor   definitions  are  automatically  added  to  the  COMPILE_DEFINITIONS
              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
              COMPILE_DEFINITIONS  properties  for  details on adding preprocessor definitions to
              specific scopes and configurations.

       add_dependencies
              Add a dependency between top-level targets.

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

              Make a top-level target depend on other top-level targets.  A top-level  target  is
              one   created   by   ADD_EXECUTABLE,  ADD_LIBRARY,  or  ADD_CUSTOM_TARGET.   Adding
              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 transitively
              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> corresponds to the logical target name and must
              be  globally unique within a project.  The actual file name of the executable built
              is constructed based on conventions of the native platform (such as  <name>.exe  or
              just <name>).

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

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

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

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

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

                add_executable(<name> IMPORTED [GLOBAL])

              An  IMPORTED  executable  target  references an executable file located outside the
              project.  No rules are generated to build it.  The target name  has  scope  in  the
              directory  in  which  it  is  created  and  below,  but  the  GLOBAL option extends
              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 <target>  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_target_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
              constructed  based  on  conventions  of the native platform (such as lib<name>.a or
              <name>.lib).

              STATIC, SHARED, or MODULE may be given  to  specify  the  type  of  library  to  be
              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_INDEPENDENT_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_OUTPUT_DIRECTORY,  LIBRARY_OUTPUT_DIRECTORY,  and
              RUNTIME_OUTPUT_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_LOCATION  (and  its
              per-configuration  version IMPORTED_LOCATION_<CONFIG>) which specifies the location
              of the main library file on disk.  See documentation of the  IMPORTED_*  properties
              for more information.

              The signature

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

              creates a special "object library" target.  An object library compiles source files
              but does not archive or link their object files  into  a  library.   Instead  other
              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 executable along with those
              compiled from their own sources.  Object libraries may contain  only  sources  (and
              headers) that compile to object files.  They may contain custom commands generating
              such  sources,  but  not  PRE_BUILD,  PRE_LINK,  or  POST_BUILD  commands.   Object
              libraries  cannot  be  imported, exported, installed, or linked.  Some native build
              systems may not like targets that have only object files,  so  consider  adding  at
              least one real source file to any target that references $<TARGET_OBJECTS:objlib>.

              The signature

                add_library(<name> ALIAS <target>)

              creates  an  alias, such that <name> can be used to refer to <target> 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) 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_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 specified, the value of source_dir, before expanding any relative path, will
              be  used  (the  typical  usage).  The  CMakeLists.txt  file in the specified source
              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 parent 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
              arguments.  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.
              Normally the generated build system knows when it needs to rerun CMake because  the
              CMakeLists.txt file is modified to add a new source.  When the source is just added
              to the directory without modifying this file, one  would  have  to  manually  rerun
              CMake to generate a build system incorporating the new file.

       break  Break from an enclosing foreach or while loop.

                break()

              Breaks from an enclosing foreach loop or while loop

       build_command
              Get the command line to build this project.

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

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

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

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

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

                build_command(<cachevariable> <makecommand>)

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

              Sets the given <cachevariable> to a string containing the  command  to  build  this
              project   from  the  root  of  the  build  tree  using  the  build  tool  given  by
              <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 information 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 specified.  When version
              2.4 or lower is given the command implicitly invokes

                cmake_policy(VERSION 2.4)

              which enables compatibility features for CMake 2.4 and lower.

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

       cmake_policy
              Manage CMake Policy settings.

              As CMake evolves it is sometimes necessary to change existing behavior in order  to
              fix  bugs  or  improve  implementations  of  existing  features.   The CMake Policy
              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 specified version or earlier will be set to use  NEW
              behavior.   All  policies  introduced  after  the  specified  version will be unset
              (unless variable CMAKE_POLICY_DEFAULT_CMP<NNNN> sets a default).  This  effectively
              requests  behavior  preferred  as  of  a  given CMake version and tells newer CMake
              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 subdirectory to protect its  parents  and  siblings.   CMake
              also  manages  a  new  entry  for  scripts  loaded  by include() and find_package()
              commands except when invoked with  the  NO_POLICY_SCOPE  option  (see  also  policy
              CMP0011).   The cmake_policy command provides an interface to manage custom entries
              on the policy stack:

                cmake_policy(PUSH)
                cmake_policy(POP)

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

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

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

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

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

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

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

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

              With NEWLINE_STYLE the line ending could be adjusted:

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

              COPYONLY must not be used with NEWLINE_STYLE.

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

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

              A  test  driver  is  a  program  that links together many small tests into a single
              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 FUNCTION is specified, then the next  argument  is  taken  as  a
              function name that is passed a pointer to ac and av.  This can be used to add extra
              command    line    processing    to    each    test.     The     cmake     variable
              CMAKE_TESTDRIVER_BEFORE_TESTMAIN  can  be  set  to  have  code  that will be placed
              directly before calling the test main  function.    CMAKE_TESTDRIVER_AFTER_TESTMAIN
              can  be  set  to  have code that will be placed directly after the call to the test
              main function.

       define_property
              Define and document custom properties.

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

              Define one property in a scope for  use  with  the  set_property  and  get_property
              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 documentation.   Corresponding  options  to  the
              get_property command will retrieve the documentation.

       else   Starts the else portion of an if block.

                else(expression)

              See the if command.

       elseif Starts the elseif portion of an if block.

                elseif(expression)

              See the if command.

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

                enable_language(<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  compiling sources or indirectly through link dependencies.
              It is simplest to enable all needed languages  in  the  top-level  directory  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 standard  output  of  each
              process  piped  to the standard input of the next.  A single standard error pipe is
              used for all processes.  If WORKING_DIRECTORY is given the named directory will  be
              set  as  the current working directory of the child processes.  If TIMEOUT is given
              the child processes will be terminated if they  do  not  finish  in  the  specified
              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  standard  input  of  the  first  process,
              standard   output  of  the  last  process,  or  standard  error  of  all  processes
              respectively.  If OUTPUT_QUIET or ERROR_QUIET is given then the standard output  or
              standard  error  results  will  be  quietly  ignored.  If more than one OUTPUT_* or
              ERROR_* option is given for the same pipe the 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 compatibility.

       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 <namespace> string will be prepended to all target
              names written to the file.  If the APPEND option is given the generated  code  will
              be     appended    to    the    file    instead    of    overwriting    it.     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  library  target  is  included  in  the
              export but a target to which it links is not included the behavior is unspecified.

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

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

                export(PACKAGE <name>)

              Store  the  current  build directory in the CMake user package registry for package
              <name>.  The find_package command may consider the directory  while  searching  for
              package  <name>.   This  helps  dependent  projects find and use a package from the
              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 configure_file to update the file only when its content changes.)

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

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

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

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

              LIMIT_COUNT sets the maximum number of strings  to  return.  LIMIT_INPUT  sets  the
              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 RELATIVE flag is specified for an expression, the
              results  will  be  returned  as  a  relative  path  to  the given path.  (We do not
              recommend 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 windows and / for UNIX.

              DOWNLOAD  will  download the given URL to the given file. If LOG var is specified a
              log of the download will be put in var. If STATUS var is specified  the  status  of
              the operation will be put in var. The status is returned in a list of length 2. The
              first element is the numeric return value for the operation, and the second element
              is a string value for the error. A 0 numeric error means no error in the operation.
              If TIMEOUT time is specified, the operation will timeout after time  seconds,  time
              should  be  specified  as  an  integer. The INACTIVITY_TIMEOUT specifies an integer
              number of seconds of inactivity after which  the  operation  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 specified 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 complete.

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

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

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

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

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

              The COPY signature copies files, directories, and symlinks to a destination folder.
              Relative input paths are evaluated with respect to the  current  source  directory,
              and  a  relative  destination  is  evaluated  with  respect  to  the  current build
              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_PERMISSIONS).   See the install(DIRECTORY) command for documentation
              of permissions, PATTERN, REGEX, and EXCLUDE options.

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

              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
              generator  expressions.   The  <condition>, <output_file> and <input_file> may also
              contain generator expressions.  The <condition> 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 sufficient in many  cases.
              It is the same as find_file(<VAR> name1 [PATHS path1 path2 ...])

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

              This  command  is  used  to  find a full path to named file. A cache entry named by
              <VAR> is created to store the result of this command.  If the full path to  a  file
              is  found  the result is stored in the variable and the search will not be repeated
              unless the  variable  is  cleared.   If  nothing  is  found,  the  result  will  be
              <VAR>-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 locations can be specified after the PATHS argument.  If ENV  var
              is  found  in  the HINTS or PATHS section the environment variable var will be read
              and converted from a system environment variable to a cmake style  list  of  paths.
              For  example ENV PATH would be a way to list the system path variable. The argument
              after DOC will be used for the documentation string in  the  cache.   PATH_SUFFIXES
              specifies additional subdirectories to check below each search path.

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

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

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

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

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

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

              4. Search the standard  system  environment  variables.  This  can  be  skipped  if
              NO_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  variable
              CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

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

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

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

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

              The default search order is designed to  be  most-specific  to  least-specific  for
              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 sufficient in many cases.
              It is the same as find_library(<VAR> name1 [PATHS path1 path2 ...])

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

              This command is used to find a library. A cache entry named by <VAR> is created  to
              store  the result of this command.  If the library is found the result is stored in
              the variable and the search will not be repeated unless the  variable  is  cleared.
              If  nothing  is  found,  the  result will be <VAR>-NOTFOUND, and the search will be
              attempted again the next time find_library is invoked with the same variable.   The
              name of the library that is searched for is specified by the names listed after the
              NAMES argument.   Additional search locations can  be  specified  after  the  PATHS
              argument.   If  ENV  var  is  found  in  the HINTS or PATHS section the environment
              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>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
                 <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
                 CMAKE_LIBRARY_PATH
                 CMAKE_FRAMEWORK_PATH

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

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

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

              4.  Search  the  standard  system  environment  variables.  This  can be skipped if
              NO_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   variable
              CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

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

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

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

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

              The  default  search  order  is  designed to be most-specific to least-specific for
              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 command by default  will
              consider  one  name at a time and search every directory for it.  The NAMES_PER_DIR
              option tells this command to consider one directory at a time and  search  for  all
              names in it.

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

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

       find_package
              Load settings for an external project.

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

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

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

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

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

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

              The complete Config mode command signature is:

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

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

              Config mode attempts to locate a configuration file provided by the package  to  be
              found.   A  cache  entry  called  <package>_DIR  is  created  to hold the directory
              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 configuration file names may be  given  using  the  CONFIGS  option.   The
              search  procedure  is  specified below.  Once found, the configuration file is read
              and processed by CMake.  Since the file is provided by the package it already knows
              the  location  of  package  contents.   The  full path to the configuration file is
              stored in the cmake variable <package>_CONFIG.

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

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

              When  the  [version]  argument is given Config mode will only find a version of the
              package  that  claims  compatibility  with  the  requested   version   (format   is
              major[.minor[.patch[.tweak]]]).  If the EXACT option is given only a version of the
              package claiming an exact match of the requested version may be found.  CMake  does
              not  establish  any convention for the meaning of version numbers.  Package version
              numbers are checked by "version" files provided by the packages themselves.  For  a
              candidate   package  configuration  file  "<config-file>.cmake"  the  corresponding
              version file is located next to it and named  either  "<config-file>-version.cmake"
              or  "<config-file>Version.cmake".   If  no  such version file is available then the
              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 version and sets these
              variables:

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

              These variables are checked by the find_package command to  determine  whether  the
              configuration  file  provides  an acceptable version.  They are not available after
              the find_package  call  returns.   If  the  version  is  acceptable  the  following
              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  procedure.   Much  of  the
              interface  is  provided  for  completeness  and  for use internally by find-modules
              loaded by Module mode.  Most user code should simply call

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

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

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

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

              On  systems  supporting  OS  X  Frameworks  and  Application  Bundles the following
              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 corresponds  to  any  of
              the names specified (<package> or names given by NAMES).  Paths with lib/<arch> are
              enabled if CMAKE_LIBRARY_ARCHITECTURE is set.  If PATH_SUFFIXES  is  specified  the
              suffixes are appended to each (W) or (U) directory entry one-by-one.

              This  set  of  directories  is  intended  to work in cooperation with projects that
              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 convention, so all (W) and (U)  directories  are  still
              searched   on  all  platforms.   Directories  marked  with  (A)  are  intended  for
              installations on Apple platforms.  The  cmake  variables  CMAKE_FIND_FRAMEWORK  and
              CMAKE_FIND_APPBUNDLE determine the order of preference as specified below.

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

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

                 CMAKE_PREFIX_PATH
                 CMAKE_FRAMEWORK_PATH
                 CMAKE_APPBUNDLE_PATH

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

                 <package>_DIR
                 CMAKE_PREFIX_PATH
                 CMAKE_FRAMEWORK_PATH
                 CMAKE_APPBUNDLE_PATH

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

              4. Search the standard  system  environment  variables.  This  can  be  skipped  if
              NO_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 dependent projects one after another.

              6. Search paths stored in the CMake user package registry.  This can be skipped  if
              NO_CMAKE_PACKAGE_REGISTRY  is  passed.   On  Windows  a  <package> may appear under
              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 typically hard-coded
              guesses.

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

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

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

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

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

              The  default  search  order  is  designed to be most-specific to least-specific for
              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  setting  the  variable
              CMAKE_DISABLE_FIND_PACKAGE_<package>   to  TRUE.  See  the  documentation  for  the
              CMAKE_DISABLE_FIND_PACKAGE_<package> variable for more information.

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

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

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

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

       find_path
              Find the directory containing a file.

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

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

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

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

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

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

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

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

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

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

              4. Search the standard  system  environment  variables.  This  can  be  skipped  if
              NO_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  variable
              CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

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

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

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

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

              The default search order is designed to  be  most-specific  to  least-specific  for
              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/Headers/b.h. If that is found  the  path
              will be set to the path to the framework. CMake will convert this to the correct -F
              option to include the file.

       find_program
              Find an executable program.

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

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

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

              This  command is used to find a program. A cache entry named by <VAR> is created to
              store the result of this command.  If the program is found the result is stored  in
              the  variable  and  the search will not be repeated unless the variable is cleared.
              If nothing is found, the result will be <VAR>-NOTFOUND,  and  the  search  will  be
              attempted  again the next time find_program is invoked with the same variable.  The
              name of the program that is searched for is specified by the names listed after the
              NAMES  argument.    Additional  search  locations  can be specified after the PATHS
              argument.  If ENV var is found in  the  HINTS  or  PATHS  section  the  environment
              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>/[s]bin for each <prefix> in CMAKE_PREFIX_PATH
                 CMAKE_PROGRAM_PATH
                 CMAKE_APPBUNDLE_PATH

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

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

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

              4. Search the standard  system  environment  variables.  This  can  be  skipped  if
              NO_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  variable
              CMAKE_FIND_FRAMEWORK can be set to empty or one of the following:

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

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

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

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

              The default search order is designed to  be  most-specific  to  least-specific  for
              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  evaluated,  the  recorded  list  of  commands  is
              invoked once for each argument listed in the original foreach command.  Before each
              iteration of the loop "${loop_var}" will be set as  a  variable  with  the  current
              value in the list.

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

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

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

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

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

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

              Iterates over a  precise  list  of  items.   The  LISTS  option  names  list-valued
              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 function 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 reference the variable ARGC which will be
              set  to  the  number  of  arguments passed into the function as well as ARGV0 ARGV1
              ARGV2 ... which will have the actual  values  of  the  arguments  passed  in.  This
              facilitates 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 property is stored in the
              variable  VAR.   If the property is not found, VAR will be set to "NOTFOUND".  Some
              supported properties include: VARIABLES,  CACHE_VARIABLES,  COMMANDS,  MACROS,  and
              COMPONENTS.

              See also the more general get_property() command.

       get_directory_property
              Get a property of DIRECTORY scope.

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

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

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

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

              See also the more general get_property() command.

       get_filename_component
              Get a specific component of a full filename.

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

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

               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 PROGRAM,  then  any  command-line  arguments
              present  in  the  FileName  string  are  split  from the program name and stored in
              <ARG_VAR>.  This is used to separate a program name from its arguments in a command
              line string.

       get_property
              Get a property.

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

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

              GLOBAL scope is unique and does not accept a name.

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

              TARGET scope must name one existing target.

              SOURCE scope must name one source file.

              TEST scope must name one existing test.

              CACHE scope must name one cache entry.

              VARIABLE scope is unique and does not accept a name.

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

       get_source_file_property
              Get a property for a source file.

                get_source_file_property(VAR file property)

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

              See also the more general get_property() command.

       get_target_property
              Get a property from a target.

                get_target_property(VAR target property)

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

              See also the more general get_property() command.

       get_test_property
              Get a property of the test.

                get_test_property(test property VAR)

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

              See also the more general get_property() command.

       if     Conditionally execute a group of commands.

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

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

                if(<constant>)

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

                if(<variable>)

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

                if(NOT <expression>)

              True if the expression is not true.

                if(<expr1> AND <expr2>)

              True if both expressions would be considered true individually.

                if(<expr1> OR <expr2>)

              True if either expression would be considered true individually.

                if(COMMAND command-name)

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

                if(POLICY policy-id)

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

                if(TARGET target-name)

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

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

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

                if(file1 IS_NEWER_THAN file2)

              True if file1 is newer than file2 or  if  one  of  the  two  files  doesn't  exist.
              Behavior  is  well-defined only for full paths. If the file time stamps are exactly
              the same, an IS_NEWER_THAN comparison returns true, so  that  any  dependent  build
              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 lexicographically less (or greater,
              or equal) than the string or variable on the right.

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

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

                if(DEFINED <variable>)

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

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

              The expressions inside the parenthesis are evaluated first and then  the  remaining
              expression  is  evaluated  as  in  the  previous  examples.  Where there are nested
              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, predating 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  STRGREATER  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  VERSION_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 values are the ones used by the generators.

              By  default the directories are appended onto the current list of directories. This
              default behavior can be changed by setting CMAKE_INCLUDE_DIRECTORIES_BEFORE to  ON.
              By  using  AFTER  or  BEFORE  explicitly,  you  can  select  between  appending and
              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 compiler docs).

       include_external_msproject
              Include an external Microsoft project file in a workspace.

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

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

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

       include_regular_expression
              Set the regular expression used for dependency checking.

                include_regular_expression(regex_match [regex_complain])

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

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

       install
              Specify rules to run at install time.

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

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

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

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

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

              The  COMPONENT  argument  specifies  an  installation component name with which the
              install  rule  is  associated,  such  as  "runtime"   or   "development".    During
              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    controlled    with    the
              CMAKE_INSTALL_DEFAULT_COMPONENT_NAME variable.

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

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

              The TARGETS signature:

                install(TARGETS targets... [EXPORT <export-name>]
                        [[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
                          PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
                         [DESTINATION <dir>]
                         [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  target.  All Windows-based systems including Cygwin are DLL platforms.
              The ARCHIVE, LIBRARY, RUNTIME, and FRAMEWORK arguments change the type of target to
              which  the  subsequent  properties  apply.   If  none  is  given  the  installation
              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 specifies a list of directories which will
              be  added  to  the  INTERFACE_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    hypothetical   targets   "myExe",   "mySharedLib",   and
              "myStaticLib".  The code

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

              will install myExe to <prefix>/bin  and  myStaticLib  to  <prefix>/lib/static.   On
              non-DLL   platforms   mySharedLib   will   be   installed   to   <prefix>/lib   and
              /some/full/path.  On DLL  platforms  the  mySharedLib  DLL  will  be  installed  to
              <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 undefined behavior.

              The FILES signature:

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

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

              The PROGRAMS signature:

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

              The  PROGRAMS  form  is  identical  to  the  FILES  form  except  that  the default
              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 verbatim to the  destination.   The
              last  component of each directory name is appended to the destination directory but
              a trailing slash may be used to avoid this because it  leaves  the  last  component
              empty.  Directory names given as relative paths are interpreted with respect to the
              current source directory.  If no input directory names are  given  the  destination
              directory   will   be   created  but  nothing  will  be  installed  into  it.   The
              FILE_PERMISSIONS and DIRECTORY_PERMISSIONS options  specify  permissions  given  to
              files  and  directories in the destination.  If USE_SOURCE_PERMISSIONS is specified
              and FILE_PERMISSIONS is not, file  permissions  will  be  copied  from  the  source
              directory  structure.   If  no  permissions  are  specified files will be given the
              default permissions specified in the FILES form of the command, and the directories
              will  be  given  the  default  permissions  specified  in  the PROGRAMS form of the
              command.

              Installation of directories may be  controlled  with  fine  granularity  using  the
              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 subset 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 permissions, and any CVS directories will be excluded.

              The SCRIPT and CODE signature:

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

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

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

              will print a message during installation.

              The EXPORT signature:

                install(EXPORT <export-name> DESTINATION <dir>
                        [NAMESPACE <namespace>] [FILE <name>.cmake]
                        [PERMISSIONS permissions...]
                        [CONFIGURATIONS [Debug|Release|...]]
                        [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 generated import file will reference  only  the  matching  target
              configurations.   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 interpreted as relative to the current source directory, see CMP0015.

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

       list   List operations.

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

              LENGTH will return a given list's length.

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

              APPEND will append elements to the list.

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

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

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

              REMOVE_DUPLICATES will remove duplicated items in the list.

              REVERSE reverses the contents of the list in-place.

              SORT sorts the list in-place alphabetically.

              The  list  subcommands  APPEND,  INSERT, REMOVE_AT, REMOVE_ITEM, REMOVE_DUPLICATES,
              REVERSE and SORT may create new values  for  the  list  within  the  current  CMake
              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
              representing the last list element. Be careful when counting with negative indices:
              they do not start from 0. -0 is equivalent to 0, the first list element.

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

                load_cache(pathToCacheFile READ_WITH_PREFIX
                           prefix entry1...)

              Read the cache and store  the  requested  entries  in  variables  with  their  name
              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
              compatibility.

       load_command
              Load a command into a running CMake.

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

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

                CMAKE_LOADED_COMMAND_<COMMAND_NAME>

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

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

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

              Define a macro named <name> that  takes  arguments  named  arg1  arg2  arg3  (...).
              Commands  listed  after  macro,  but  before the matching endmacro, are not invoked
              until the macro is invoked.  When it is invoked, the commands recorded in the macro
              are  first  modified  by  replacing  formal parameters (${arg1}) with the arguments
              passed, and then invoked as normal commands. In addition to referencing the  formal
              parameters  you can reference the values ${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.  Additionally  ${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 values such as ARGN  are
              not  variables in the usual CMake sense. They are string replacements much like the
              C preprocessor would do with a macro. If  you  want  true  CMake  variables  and/or
              better CMake scope control you should look at the function command.

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

       mark_as_advanced
              Mark cmake cached variables as advanced.

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

              Mark the named cached variables as advanced.  An  advanced  variable  will  not  be
              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 neither FORCE nor
              CLEAR is specified, new values will be marked as  advanced,  but  if  the  variable
              already has an advanced/non-advanced state, it will not be changed.

              It does nothing in script mode.

       math   Mathematical expressions.

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

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

       message
              Display a message to the user.

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

              The optional keyword determines the type of message:

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

              The  CMake  command-line  tool  displays  STATUS  messages  on stdout and all other
              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   variables
              <projectName>_BINARY_DIR and <projectName>_SOURCE_DIR to the respective values.

              Optionally  you  can  specify  which  languages  your  project  supports.   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 command line for sources
              in the current directory and below.

       return Return from a file, directory or function.

                return()

              Returns from a file, directory or function. When this command is encountered in  an
              included  file  (via  include()  or  find_package()),  it  causes processing of the
              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 CMakeLists.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 function and does not handle return like a function does.

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

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

              Parses  a  unix-  or  windows-style  command-line  string  "<args>"  and  stores  a
              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  whitespace.   It  recognizes
              both  single-quote  and  double-quote  pairs.  A backslash escapes the next literal
              character (\" is "); there are no special escapes (\n is just n).

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

                separate_arguments(VARIABLE)

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

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

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

              Within  CMake  sets  <variable>  to  the value <value>.  <value> is expanded before
              <variable> is set to it.  Normally, set will set a regular CMake variable. If CACHE
              is  present,  then the <variable> is put in the cache instead, unless it is already
              in the cache. See section 'Variable types in CMake' below for  details  of  regular
              and  cache  variables  and  their  interactions.  If  CACHE  is  used,  <type>  and
              <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 variable is set, even if the variable is
              already in the cache. This should normally  be  avoided,  as  it  will  remove  any
              changes to the cache variable's value by the user.

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

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

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

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

              <variable> can be an environment variable such as:

                set( ENV{PATH} /home/martink )

              in which case the environment variable will be set.

              *** Variable types in CMake ***

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

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

              Some examples:

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

              The  code  'set(FOO  "x"  CACHE  ...)'  checks for 'FOO' in the cache, ignoring any
              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 compiler option), the parent gets the first chance to add a
              user-editable option to the cache. Normally, the child  would  then  use  the  same
              value that the parent uses. However, it may be necessary to hard-code the value for
              the child project's option while still allowing the user to edit the value used  by
              the  parent project. The parent project can achieve this simply by setting a normal
              variable with the same name as the  option  in  a  scope  sufficient  to  hide  the
              option's  cache  variable from the child completely. The parent has already set the
              cache variable,  so the child's set(...CACHE...) will do  nothing,  and  evaluating
              the  option  variable  will use the value from the normal variable, which hides the
              cache variable.

       set_directory_properties
              Set a property of the directory.

                set_directory_properties(PROPERTIES prop1 value1 prop2 value2)

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

       set_property
              Set a named property in a given scope.

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

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

              GLOBAL scope is unique and does not accept a name.

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

              TARGET scope may name zero or more existing targets.

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

              TEST scope may name zero or more existing tests.

              CACHE scope must name zero or more cache existing entries.

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

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

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

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

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

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

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

              Properties  that  affect  the  name  of a target's output file are as follows.  The
              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 executables).

              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 configuration  <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 target.  It may also be used to
              pass additional preprocessor definitions.

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

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

              There are a few  properties  used  to  specify  RPATH  rules.  INSTALL_RPATH  is  a
              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 relinking before installation.  INSTALL_NAME_DIR  is  a  string
              specifying the directory portion of the "install_name" field of shared libraries on
              Mac OSX to use in the installed targets. When the target is created the  values  of
              the      variables      CMAKE_INSTALL_RPATH,     CMAKE_INSTALL_RPATH_USE_LINK_PATH,
              CMAKE_SKIP_BUILD_RPATH, CMAKE_BUILD_WITH_INSTALL_RPATH, and  CMAKE_INSTALL_NAME_DIR
              are used to initialize these properties.

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

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

              VS_GLOBAL_<variable> can be set to add  a  Visual  Studio  project-specific  global
              variable.  Qt  integration  works  better  if  VS_GLOBAL_QtVersion is set to the Qt
              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 subgroups:

                source_group(outer\\inner ...)

              For backwards compatibility, this command also supports the format:

                source_group(name regex)

       string String operations.

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

              CONFIGURE will transform a string like CONFIGURE_FILE transforms a file.

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

              LENGTH will return a given string's length.

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

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

              RANDOM will return a random string of given length consisting  of  characters  from
              the  given  alphabet.  Default  length  is 5 characters and default alphabet is all
              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 expressions:

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

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

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

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

              The  optional  UTC  flag  requests  the  current  date/time representation to be in
              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 output as-is.

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

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

              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  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.  The INTERFACE, PUBLIC and PRIVATE keywords are
              required to specify the scope of the following arguments.  PRIVATE and PUBLIC items
              will populate the COMPILE_DEFINITIONS property of <target>.  PUBLIC  and  INTERFACE
              items  will  populate the INTERFACE_COMPILE_DEFINITIONS property of <target>.   The
              following arguments specify compile  definitions.   Repeated  calls  for  the  same
              <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  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_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 target.  If BEFORE is specified, the content will  be  prepended
              to the property instead of being appended.

              The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the
              following arguments.  PRIVATE and PUBLIC items will  populate  the  COMPILE_OPTIONS
              property   of   <target>.    PUBLIC   and   INTERFACE   items   will  populate  the
              INTERFACE_COMPILE_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 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.

       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 specify the scope of the
              following   arguments.    PRIVATE   and   PUBLIC   items    will    populate    the
              INCLUDE_DIRECTORIES property of <target>.  PUBLIC and INTERFACE items will populate
              the INTERFACE_INCLUDE_DIRECTORIES property of <target>.   The  following  arguments
              specify  include  directories.  Specified include directories 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  (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 compiler  docs).
              If    SYSTEM    is    used    together    with    PUBLIC    or    INTERFACE,    the
              INTERFACE_SYSTEM_INCLUDE_DIRECTORIES target property will  be  populated  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  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_link_libraries
              Link a target to given libraries.

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

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

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

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

              Library dependencies are transitive by default  with  this  signature.   When  this
              target  is linked into another target then the libraries linked to this target will
              appear on the link line for the other target too.  This transitive "link interface"
              is  stored  in  the INTERFACE_LINK_LIBRARIES target property when policy CMP0022 is
              set to NEW and may be overridden by setting the property directly. (When CMP0022 is
              not  set  to  NEW,  transitive  linking  is  builtin  but  may be overridden by the
              LINK_INTERFACE_LIBRARIES property.  Calls to other signatures of this  command  may
              set  the  property  making  any  libraries  linked  exclusively  by  this signature
              private.)

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

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

              The  PUBLIC,  PRIVATE  and  INTERFACE keywords can be used to specify 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 compatibility only. Prefer the INTERFACE mode instead.  Libraries specified  as
              "debug"  are  wrapped  in a generator expression to correspond to debug builds.  If
              policy  CMP0022  is  not  NEW,   the   libraries   are   also   appended   to   the
              LINK_INTERFACE_LIBRARIES_DEBUG  property  (or  to  the  properties corresponding 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_INTERFACE_LIBRARIES  property.   Libraries  specified as "general" (or without
              any keyword) are treated as if specified for both "debug" and "optimized".

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

              The LINK_PUBLIC and LINK_PRIVATE modes  can  be  used  to  specify  both  the  link
              dependencies  and  the  link  interface  in  one  command.   This  signature is for
              compatibility only. Prefer the PUBLIC or PRIVATE keywords instead.   Libraries  and
              targets   following   LINK_PUBLIC   are  linked  to,  and  are  made  part  of  the
              INTERFACE_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_INTERFACE_LIBRARIES).

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

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

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

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

              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.

       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 sequential try_compile operations reuse  this  single
              output directory. If you use --debug-trycompile, you can only debug one try_compile
              call at a time. The recommended procedure is to configure with cmake  all  the  way
              through  once,  then delete the cache entry associated with the try_compile call of
              interest, and then re-run cmake again with --debug-trycompile.

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

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

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

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

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

       try_run
              Try compiling and then running some code.

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

              Try compiling  a  srcfile.   Return  TRUE  or  FALSE  for  success  or  failure  in
              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_OUTPUT_VARIABLE specifies
              the variable where the output  from  the  compile  step  goes.  RUN_OUTPUT_VARIABLE
              specifies the variable where the output from the running executable goes.

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

              Cross compiling issues

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

              In  order  to  make cross compiling your project easier, use try_run only if really
              required. If you use try_run, use RUN_OUTPUT_VARIABLE (or OUTPUT_VARIABLE) only  if
              really  required.  Using  them  will  require  that  when crosscompiling, the cache
              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 alternative for this case.

              Set variable CMAKE_TRY_COMPILE_CONFIGURATION to choose a build configuration.

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

                unset(<variable> [CACHE])

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

              <variable> can be an environment variable such as:

                unset(ENV{LD_LIBRARY_PATH})

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

       variable_watch
              Watch the CMake variable for change.

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

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

       while  Evaluate a group of commands while a condition is true

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

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

COPYRIGHT

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

       Redistribution  and  use  in  source  and  binary forms, with or without modification, are
       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 permission.

       THIS  SOFTWARE  IS  PROVIDED  BY  THE  COPYRIGHT  HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
       EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE  IMPLIED  WARRANTIES  OF
       MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
       COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,  SPECIAL,
       EXEMPLARY,  OR  CONSEQUENTIAL  DAMAGES  (INCLUDING,  BUT  NOT  LIMITED  TO, PROCUREMENT OF
       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 questions.

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

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

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

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