ctest man page on Mandriva

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

ctest(1)							      ctest(1)

NAME
	 ctest - Testing driver provided by CMake.

USAGE
	 ctest [options]

DESCRIPTION
       The  "ctest" executable is the CMake test driver program.  CMake-gener‐
       ated build trees created for projects that use the  ENABLE_TESTING  and
       ADD_TEST	 commands  have	 testing  support.   This program will run the
       tests and report results.

OPTIONS
       -C <cfg>, --build-config <cfg>
	      Choose configuration to test.

	      Some CMake-generated build trees can have multiple build config‐
	      urations	in  the same tree.  This option can be used to specify
	      which one should be tested.  Example configurations are  "Debug"
	      and "Release".

       -V,--verbose
	      Enable verbose output from tests.

	      Test  output is normally suppressed and only summary information
	      is displayed.  This option will show all test output.

       -VV,--extra-verbose
	      Enable more verbose output from tests.

	      Test output is normally suppressed and only summary  information
	      is displayed.  This option will show even more test output.

       --debug
	      Displaying more verbose internals of CTest.

	      This  feature  will  result  in  large  number of output that is
	      mostly useful for debugging dashboard problems.

       --output-on-failure
	      Output anything outputted by the test program if the test should
	      fail.   This  option can also be enabled by setting the environ‐
	      ment variable CTEST_OUTPUT_ON_FAILURE

       -F     Enable failover.

	      This option allows ctest to resume a test set execution that was
	      previously  interrupted.	 If  no	 interruption occurred, the -F
	      option will have no effect.

       -Q,--quiet
	      Make ctest quiet.

	      This option will suppress all the output. The  output  log  file
	      will  still  be  generated  if  the  --output-log	 is specified.
	      Options such as  --verbose,  --extra-verbose,  and  --debug  are
	      ignored if --quiet is specified.

       -O <file>, --output-log <file>
	      Output to log file

	      This option tells ctest to write all its output to a log file.

       -N,--show-only
	      Disable actual execution of tests.

	      This  option tells ctest to list the tests that would be run but
	      not actually run them.  Useful in conjunction with the -R and -E
	      options.

       -L <regex>, --label-regex <regex>
	      Run tests with labels matching regular expression.

	      This option tells ctest to run only the tests whose labels match
	      the given regular expression.

       -R <regex>, --tests-regex <regex>
	      Run tests matching regular expression.

	      This option tells ctest to run only the tests whose names	 match
	      the given regular expression.

       -E <regex>, --exclude-regex <regex>
	      Exclude tests matching regular expression.

	      This  option  tells ctest to NOT run the tests whose names match
	      the given regular expression.

       -LE <regex>, --label-exclude <regex>
	      Exclude tests with labels matching regular expression.

	      This option tells ctest to NOT run the tests whose labels	 match
	      the given regular expression.

       -D <dashboard>, --dashboard <dashboard>
	      Execute dashboard test

	      This option tells ctest to perform act as a Dart client and per‐
	      form a dashboard test. All tests are  <Mode><Test>,  where  Mode
	      can  be  Experimental,  Nightly, and Continuous, and Test can be
	      Start, Update, Configure, Build, Test, Coverage, and Submit.

       -M <model>, --test-model <model>
	      Sets the model for a dashboard

	      This option tells ctest to act as a Dart client where the	 Test‐
	      Model can be Experimental, Nightly, and Continuous. Combining -M
	      and -T is similar to -D

       -T <action>, --test-action <action>
	      Sets the dashboard action to perform

	      This option tells ctest to act as a Dart client and perform some
	      action  such  as	start, build, test etc. Combining -M and -T is
	      similar to -D

       --track <track>
	      Specify the track to submit dashboard to

	      Submit dashboard to specified track instead of default  one.  By
	      default, the dashboard is submitted to Nightly, Experimental, or
	      Continuous track, but by specifying this option, the  track  can
	      be arbitrary.

       -S <script>, --script <script>
	      Execute a dashboard for a configuration

	      This  option tells ctest to load in a configuration script which
	      sets a number of parameters such as the binary and source direc‐
	      tories.  Then ctest will do what is required to create and run a
	      dashboard. This option basically sets up a  dashboard  and  then
	      runs ctest -D with the appropriate options.

       -SP <script>, --script-new-process <script>
	      Execute a dashboard for a configuration

	      This  option  does the same operations as -S but it will do them
	      in a separate process. This is primarily useful in  cases	 where
	      the  script  may	modify the environment and you do not want the
	      modified environment to impact other -S scripts.

       -A <file>, --add-notes <file>
	      Add a notes file with submission

	      This option tells ctest to include a notes file when  submitting
	      dashboard.

       -I [Start,End,Stride,test#,test#|Test file], --tests-information
	      Run a specific number of tests by number.

	      This  option causes ctest to run tests starting at number Start,
	      ending at number End, and incrementing by Stride. Any additional
	      numbers  after  Stride  are  considered individual test numbers.
	      Start, End,or stride can be empty.  Optionally  a	 file  can  be
	      given that contains the same syntax as the command line.

       -U, --union
	      Take the Union of -I and -R

	      When both -R and -I are specified by default the intersection of
	      tests are run. By specifying  -U	the  union  of	tests  is  run
	      instead.

       --max-width <width>
	      Set the max width for a test name to output

	      Set  the maximum width for each test name to show in the output.
	      This allows the user to widen the output to avoid	 clipping  the
	      test name which can be very annoying.

       --interactive-debug-mode [0|1]
	      Set the interactive mode to 0 or 1.

	      This  option  causes ctest to run tests in either an interactive
	      mode or a non-interactive mode. On Windows this  means  that  in
	      non-interactive  mode,  all  system  debug  pop  up  windows are
	      blocked. In dashboard mode (Experimental, Nightly,  Continuous),
	      the default is non-interactive.  When just running tests not for
	      a dashboard the default  is  to  allow  popups  and  interactive
	      debugging.

       --no-label-summary
	      Disable timing summary information for labels.

	      This  option  tells  ctest  to not print summary information for
	      each label associated with the tests run. If there are no labels
	      on the tests, nothing extra is printed.

       --build-and-test
	      Configure, build and run a test.

	      This option tells ctest to configure (i.e. run cmake on), build,
	      and or  execute  a  test.	 The  configure	 and  test  steps  are
	      optional.	 The arguments to this command line are the source and
	      binary directories. By  default  this  will  run	CMake  on  the
	      Source/Bin directories specified unless --build-nocmake is spec‐
	      ified. Both --build-makeprogram and  --build-generator  MUST  be
	      provided to use --built-and-test. If --test-command is specified
	      then that will be run after the build is complete. Other options
	      that   affect  this  mode	 are  --build-target  --build-nocmake,
	      --build-run-dir,	    --build-two-config,	      --build-exe-dir,
	      --build-project,--build-noclean, --build-options

       --build-target
	      Specify a specific target to build.

	      This  option  goes with the --build-and-test option, if left out
	      the all target is built.

       --build-nocmake
	      Run the build without running cmake first.

	      Skip the cmake step.

       --build-run-dir
	      Specify directory to run programs from.

	      Directory where programs will be after it has been compiled.

       --build-two-config
	      Run CMake twice

       --build-exe-dir
	      Specify the directory for the executable.

       --build-generator
	      Specify the generator to use.

       --build-project
	      Specify the name of the project to build.

       --build-makeprogram
	      Specify the make program to use.

       --build-noclean
	      Skip the make clean step.

       --build-config-sample
	      A sample executable to use to determine the configuration

	      A sample executable to use to determine the  configuration  that
	      should be used. e.g. Debug/Release/etc

       --build-options
	      Add extra options to the build step.

	      This  option  must  be  the  last	 option	 with the exception of
	      --test-command

       --test-command
	      The test to run with the --build-and-test option.

       --test-timeout
	      The time limit in seconds, internal use only.

       --tomorrow-tag
	      Nightly or experimental starts with next day tag.

	      This is useful if the build will not finish in one day.

       --ctest-config
	      The configuration file used to initialize CTest state when  sub‐
	      mitting dashboards.

	      This  option  tells  CTest  to use different initialization file
	      instead of CTestConfiguration.tcl. This way multiple initializa‐
	      tion  files  can be used for example to submit to multiple dash‐
	      boards.

       --overwrite
	      Overwrite CTest configuration option.

	      By default ctest uses configuration options  from	 configuration
	      file. This option will overwrite the configuration option.

       --extra-submit <file>[;<file>]
	      Submit extra files to the dashboard.

	      This option will submit extra files to the dashboard.

       --force-new-ctest-process
	      Run child CTest instances as new processes

	      By  default CTest will run child CTest instances within the same
	      process. If this behavior is not	desired,  this	argument  will
	      enforce new processes for child CTest processes.

       --schedule-random
	      Use a random order for scheduling tests

	      This option will run the tests in a random order. It is commonly
	      used to detect implicit dependencies in a test suite.

       --submit-index
	      Submit individual dashboard tests with specific index

	      This option allows performing the same  CTest  action  (such  as
	      test) multiple times and submit all stages to the same dashboard
	      (Dart2 required). Each execution requires different index.

       --timeout <seconds>
	      Set a global timeout on all tests.

	      This option will set a global timeout on all tests that  do  not
	      already have a timeout set on them.

       --http1.0
	      Submit using HTTP 1.0.

	      This  option will force CTest to use HTTP 1.0 to submit files to
	      the dashboard, instead of HTTP 1.1.

       --no-compress-output
	      Do not compress test output when submitting.

	      This flag will turn off automatic compression  of	 test  output.
	      Use  this	 to  maintain  compatibility  with an older version of
	      CDash which doesn't support compressed test output.

       --help-command <cmd> [<file>]
	      Show help for a single command and exit.

	      Prints the help for the command to stdout or  to	the  specified
	      file.

       --help-command-list [<file>]
	      List available commands and exit.

	      Prints  the list of all available listfile commands to stdout or
	      the specified file.

       --help-commands [<file>]
	      Print help for all commands and exit.

	      Prints the help for all commands to stdout or to	the  specified
	      file.

GENERATORS
       The following generators are available on this platform:

COMMANDS
       break  Break from an enclosing foreach or while loop.

		break()

	      Breaks from an enclosing foreach loop or while loop

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

		build_name(variable)

	      Sets the specified variable to a string representing  the	 plat‐
	      form  and	 compiler  settings.   These  values are now available
	      through the CMAKE_SYSTEM and CMAKE_CXX_COMPILER variables.

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

		cmake_minimum_required(VERSION major[.minor[.patch]]
				       [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]])

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

		cmake_policy(VERSION 2.4)

	      which enables compatibility features for CMake 2.4 and lower.

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

       cmake_policy
	      Manage CMake Policy settings.

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

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

		cmake_policy(VERSION major.minor[.patch])

	      Specify  that  the  current  CMake  list file is written for the
	      given version of CMake.  All policies introduced in  the	speci‐
	      fied  version  or	 earlier will be set to use NEW behavior.  All
	      policies introduced after the specified version will  be	unset.
	      This effectively requests behavior preferred as of a given CMake
	      version and tells newer CMake versions to warn about  their  new
	      policies.	  The policy version specified must be at least 2.4 or
	      the command will report an error.	 In order to get compatibility
	      features	supporting versions earlier than 2.4 see documentation
	      of policy CMP0001.

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

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

		cmake_policy(GET CMP<NNNN> <variable>)

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

	      CMake keeps policy settings on a stack, so changes made  by  the
	      cmake_policy  command  affect  only the top of the stack.	 A new
	      entry on the policy stack is managed automatically for each sub‐
	      directory	 to protect its parents and siblings.  CMake also man‐
	      ages a new entry for scripts loaded by include() and  find_pack‐
	      age()  commands  except  when  invoked  with the NO_POLICY_SCOPE
	      option (see also policy CMP0011).	 The cmake_policy command pro‐
	      vides an interface to manage custom entries on the policy stack:

		cmake_policy(PUSH)
		cmake_policy(POP)

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

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

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

		configure_file(<input> <output>
			       [COPYONLY] [ESCAPE_QUOTES] [@ONLY])

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

	      This command replaces any variables in the input file referenced
	      as ${VAR} or @VAR@ with their values as determined by CMake.  If
	      a variable is not defined, it will be replaced with nothing.  If
	      COPYONLY	is  specified,	then  no  variable expansion will take
	      place.  If  ESCAPE_QUOTES	 is  specified	then  any  substituted
	      quotes  will  be	C-style	 escaped.  The file will be configured
	      with the current values of CMake variables. If @ONLY  is	speci‐
	      fied,  only  variables  of  the  form @VAR@ will be replaces and
	      ${VAR} will be ignored.  This is useful for configuring  scripts
	      that  use	 ${VAR}.  Any  occurrences of #cmakedefine VAR will be
	      replaced with either #define VAR or /* #undef VAR	 */  depending
	      on  the  setting	of  VAR in CMake. Any occurrences of #cmakede‐
	      fine01 VAR will be replaced with either #define VAR 1 or #define
	      VAR  0  depending	 on  whether VAR evaluates to TRUE or FALSE in
	      CMake

       ctest_build
	      Build the project.

		ctest_build([BUILD build_dir] [RETURN_VALUE res] [APPEND]
			    [NUMBER_ERRORS val] [NUMBER_WARNINGS val])

	      Builds  the  given  build	 directory  and	 stores	  results   in
	      Build.xml.  If  no  BUILD	 is  given, the CTEST_BINARY_DIRECTORY
	      variable is used. The RETURN_VALUE option specifies  a  variable
	      in which to store the return value of the native build tool. The
	      NUMBER_ERRORS and NUMBER_WARNINGS options specify	 variables  in
	      which to store the number of build errors and warnings detected.

	      The  APPEND  option marks results for append to those previously
	      submitted to a dashboard	server	since  the  last  ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_configure
	      Configure the project build tree.

		ctest_configure([BUILD build_dir] [SOURCE source_dir] [APPEND]
				[OPTIONS options] [RETURN_VALUE res])

	      Configures  the given build directory and stores results in Con‐
	      figure.xml. If no BUILD  is  given,  the	CTEST_BINARY_DIRECTORY
	      variable is used. If no SOURCE is given, the CTEST_SOURCE_DIREC‐
	      TORY variable is used. The OPTIONS  argument  specifies  command
	      line   arguments	 to   pass  to	the  configuration  tool.  The
	      RETURN_VALUE option specifies a variable in which to  store  the
	      return value of the native build tool.

	      The  APPEND  option marks results for append to those previously
	      submitted to a dashboard	server	since  the  last  ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_coverage
	      Collect coverage tool results.

		ctest_coverage([BUILD build_dir] [RETURN_VALUE res] [APPEND]
			       [LABELS label1 [label2 [...]]])

	      Perform  the  coverage  of  the given build directory and stores
	      results in Coverage.xml. The second argument is a variable  that
	      will hold value.

	      The  LABELS  option  filters the coverage report to include only
	      source files labeled with at least one of the labels specified.

	      The APPEND option marks results for append to  those  previously
	      submitted	 to  a	dashboard  server  since the last ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_empty_binary_directory
	      empties the binary directory

		ctest_empty_binary_directory( directory )

	      Removes a binary	directory.  This  command  will	 perform  some
	      checks  prior  to	 deleting the directory in an attempt to avoid
	      malicious or accidental directory deletion.

       ctest_memcheck
	      Run tests with a dynamic analysis tool.

		ctest_memcheck([BUILD build_dir] [RETURN_VALUE res] [APPEND]
			   [START start number] [END end number]
			   [STRIDE stride number] [EXCLUDE exclude regex ]
			   [INCLUDE include regex]
			   [EXCLUDE_LABEL exclude regex]
			   [INCLUDE_LABEL label regex]
			   [PARALLEL_LEVEL level] )

	      Tests the given build  directory	and  stores  results  in  Mem‐
	      Check.xml.  The  second  argument	 is  a variable that will hold
	      value. Optionally, you can  specify  the	starting  test	number
	      START,  the  ending test number END, the number of tests to skip
	      between each test STRIDE, a regular expression for tests to  run
	      INCLUDE,	or  a regular expression for tests not to run EXCLUDE.
	      EXCLUDE_LABEL and	 INCLUDE_LABEL	are  regular  expressions  for
	      tests  to	 be  included  or excluded by the test property LABEL.
	      PARALLEL_LEVEL should be set to a positive  number  representing
	      the number of tests to be run in parallel.

	      The  APPEND  option marks results for append to those previously
	      submitted to a dashboard	server	since  the  last  ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_read_custom_files
	      read CTestCustom files.

		ctest_read_custom_files( directory ... )

	      Read  all	 the CTestCustom.ctest or CTestCustom.cmake files from
	      the given directory.

       ctest_run_script
	      runs a ctest -S script

		ctest_run_script([NEW_PROCESS] script_file_name script_file_name1
			    script_file_name2 ... [RETURN_VALUE var])

	      Runs a script or scripts much like if it was run from ctest  -S.
	      If  no argument is provided then the current script is run using
	      the current settings of the variables. If NEW_PROCESS is	speci‐
	      fied  then  each	script	will  be  run in a seperate process.If
	      RETURN_VALUE is specified the return value of  the  last	script
	      run will be put into var.

       ctest_sleep
	      sleeps for some amount of time

		ctest_sleep( seconds )
		ctest_sleep( time1 duration time2 )

	      With  one	 argument it will sleep for a given number of seconds.
	      With three arguments it will wait for time2 - time1  -  duration
	      seconds.

       ctest_start
	      Starts the testing for a given model

		ctest_start(Model [TRACK <track>] [APPEND] [source [binary]])

	      Starts  the  testing  for	 a  given model. The command should be
	      called  after  the  binary  directory  is	 initialized.  If  the
	      'source'	and 'binary' directory are not specified, it reads the
	      CTEST_SOURCE_DIRECTORY and CTEST_BINARY_DIRECTORY. If the	 track
	      is specified, the submissions will go to the specified track. If
	      APPEND is used, the existing TAG is used rather than creating  a
	      new one based on the current time stamp.

       ctest_submit
	      Submit results to a dashboard server.

		ctest_submit([PARTS ...] [FILES ...] [RETURN_VALUE res])

	      By  default  all	available  parts  are submitted if no PARTS or
	      FILES are specified.  The PARTS option lists a subset  of	 parts
	      to be submitted.	Valid part names are:

		Start	   = nothing
		Update	   = ctest_update results, in Update.xml
		Configure  = ctest_configure results, in Configure.xml
		Build	   = ctest_build results, in Build.xml
		Test	   = ctest_test results, in Test.xml
		Coverage   = ctest_coverage results, in Coverage.xml
		MemCheck   = ctest_memcheck results, in DynamicAnalysis.xml
		Notes	   = Files listed by CTEST_NOTES_FILES, in Notes.xml
		ExtraFiles = Files listed by CTEST_EXTRA_SUBMIT_FILES
		Submit	   = nothing

	      The  FILES  option explicitly lists specific files to be submit‐
	      ted.  Each individual file must exist at the time of the call.

       ctest_test
	      Run tests in the project build tree.

		ctest_test([BUILD build_dir] [APPEND]
			   [START start number] [END end number]
			   [STRIDE stride number] [EXCLUDE exclude regex ]
			   [INCLUDE include regex] [RETURN_VALUE res]
			   [EXCLUDE_LABEL exclude regex]
			   [INCLUDE_LABEL label regex]
			   [PARALLEL_LEVEL level]
			   [SCHEDULE_RANDOM on])

	      Tests the given build directory and stores results in  Test.xml.
	      The  second argument is a variable that will hold value. Option‐
	      ally, you can specify the starting test number START, the ending
	      test  number  END, the number of tests to skip between each test
	      STRIDE, a regular expression for tests to run INCLUDE, or a reg‐
	      ular  expression for tests to not run EXCLUDE. EXCLUDE_LABEL and
	      INCLUDE_LABEL are regular expression for test to be included  or
	      excluded	by  the	 test property LABEL. PARALLEL_LEVEL should be
	      set to a positive number representing the number of tests to  be
	      run  in  parallel. SCHEDULE_RANDOM will launch tests in a random
	      order, and is typically used to detect implicit  test  dependen‐
	      cies.

	      The  APPEND  option marks results for append to those previously
	      submitted to a dashboard	server	since  the  last  ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_update
	      Update the work tree from version control.

		ctest_update([SOURCE source] [RETURN_VALUE res])

	      Updates  the  given  source  directory  and  stores  results  in
	      Update.xml. If no SOURCE is  given,  the	CTEST_SOURCE_DIRECTORY
	      variable	is  used. The RETURN_VALUE option specifies a variable
	      in which to store the result,  which  is	the  number  of	 files
	      updated or -1 on error.

       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.

       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.

       exec_program
	      Deprecated.  Use the execute_process() command instead.

	      Run  an  executable  program during the processing of the CMake‐
	      List.txt file.

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

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

       execute_process
	      Execute one or more child processes.

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

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

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

       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(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 [TIMEOUT timeout] [STATUS status] [LOG log])

	      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.

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

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

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

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

	      REGEX specifies a regular expression that a string must match to
	      be returned. Typical usage

		file(STRINGS myfile.txt myfile)

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

	      GLOB  will  generate a list of all files that match the globbing
	      expressions and store it into the variable. Globbing expressions
	      are  similar  to regular expressions, but much simpler. If RELA‐
	      TIVE flag is specified for an expression, the  results  will  be
	      returned as a relative path to the given path.

	      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.

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

	      DOWNLOAD	will  download the given URL to the given file. If LOG
	      var is specified a log of the download will be put  in  var.  If
	      STATUS  var is specified the status of the operation will be put
	      in var. The status is returned in a list of length 2. The	 first
	      element  is  the numeric return value for the operation, and the
	      second element is a string value for  the	 error.	 A  0  numeric
	      error means no error in the operation. If TIMEOUT time is speci‐
	      fied, the operation will timeout after time seconds, time should
	      be specified as an integer.

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

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

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

	      The INSTALL signature differs slightly from COPY: it prints sta‐
	      tus  messages,  and NO_SOURCE_PERMISSIONS is default.  Installa‐
	      tion scripts generated by the install() command use this	signa‐
	      ture (with some undocumented options for internal use).

       find_file
	      Find the full path to a file.

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

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

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

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

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

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

		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

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

		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

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

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

		 PATH
		 INCLUDE

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

		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

       find_library
	      Find a library.

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

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

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

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

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

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

		 <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_LIBRARY_PATH
		 CMAKE_FRAMEWORK_PATH

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

		 <prefix>/lib for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_LIBRARY_PATH
		 CMAKE_FRAMEWORK_PATH

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

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

		 PATH
		 LIB

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

		 <prefix>/lib for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_LIBRARY_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

	      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.

       find_package
	      Load settings for an external project.

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

	      Finds and loads  settings	 from  an  external  project.	<pack‐
	      age>_FOUND  will	be  set	 to  indicate  whether the package was
	      found.  When the package is found	 package-specific  information
	      is  provided through variables documented by the package itself.
	      The QUIET option disables messages  if  the  package  cannot  be
	      found.   The REQUIRED option stops processing with an error mes‐
	      sage if the package cannot be found.  A package-specific list of
	      components  may be listed after the REQUIRED option or after the
	      COMPONENTS option if no REQUIRED option is given.	 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]  is	given  to  a  recursive	 invocation  inside  a
	      find-module,  the	 [version]  and	 EXACT arguments are forwarded
	      automatically from the outer call.  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 respon‐
	      sible for finding the package, checking the version, and produc‐
	      ing any needed messages.	Many find-modules provide  limited  or
	      no  support  for versioning; check the module documentation.  If
	      no module is found the command proceeds to Config mode.

	      The complete Config mode command signature is:

		find_package(<package> [version] [EXACT] [QUIET]
			     [[REQUIRED|COMPONENTS] [components...]] [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]
			     [CMAKE_FIND_ROOT_PATH_BOTH |
			      ONLY_CMAKE_FIND_ROOT_PATH |
			      NO_CMAKE_FIND_ROOT_PATH])

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	      In  all cases the <name> is treated as case-insensitive and cor‐
	      responds to any of the names specified (<package> or names given
	      by  NAMES).   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 conven‐
	      tion,  so	 all (W) and (U) directories are still searched on all
	      platforms.  Directories marked with (A) are intended for instal‐
	      lations	 on    Apple	platforms.     The   cmake   variables
	      CMAKE_FIND_FRAMEWORK  and	 CMAKE_FIND_APPBUNDLE  determine   the
	      order of preference as specified below.

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

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

		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

		 <package>_DIR
		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

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

		 PATH

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

	      6. Search paths stored in the CMake user package registry.  This
	      can be skipped if NO_CMAKE_PACKAGE_REGISTRY  is  passed.	 Paths
	      are  stored in the registry when CMake configures a project that
	      invokes export(PACKAGE <name>).  See the export(PACKAGE) command
	      documentation for more details.

	      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 specified by the PATHS option.  These are typi‐
	      cally hard-coded guesses.

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

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

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

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

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

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

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

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

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

       find_path
	      Find the directory containing a file.

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

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

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

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

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

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

		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

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

		 <prefix>/include for each <prefix> in CMAKE_PREFIX_PATH
		 CMAKE_INCLUDE_PATH
		 CMAKE_FRAMEWORK_PATH

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

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

		 PATH
		 INCLUDE

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

		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

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

       find_program
	      Find an executable program.

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

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

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

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

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

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

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

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

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

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

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

		 PATH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       get_cmake_property
	      Get a property of the CMake instance.

		get_cmake_property(VAR property)

	      Get  a property from the CMake instance.	The value of the prop‐
	      erty is stored in the variable  VAR.  If	the  property  is  not
	      found,  CMake  will  report  an error. Some supported properties
	      include: VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and  COM‐
	      PONENTS.

       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.

       get_filename_component
	      Get a specific component of a full filename.

		get_filename_component(VarName FileName
				       PATH|ABSOLUTE|NAME|EXT|NAME_WE|REALPATH
				       [CACHE])

	      Set VarName to be the path (PATH), file name (NAME), file exten‐
	      sion  (EXT),  file name without extension (NAME_WE) of FileName,
	      the full path (ABSOLUTE), or the full  path  with	 all  symlinks
	      resolved	(REALPATH).   Note  that the path is converted to Unix
	      slashes format and has no trailing  slashes.  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(VarName FileName
				       PROGRAM [PROGRAM_ARGS ArgVar]
				       [CACHE])

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

       get_property
	      Get a property.

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

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

	      GLOBAL scope is unique and does not accept a name.

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

	      TARGET scope must name one existing target.

	      SOURCE scope must name one source file.

	      TEST scope must name one existing test.

	      CACHE scope must name one cache entry.

	      VARIABLE scope is unique and does not accept a name.

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

       if     Conditionally execute a group of commands.

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

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

		if(<constant>)

	      True  if the constant is 1, ON, YES, TRUE, Y, or a non-zero num‐
	      ber.  False if the constant is 0, OFF, NO, FALSE, N, IGNORE, "",
	      or  ends in the suffix '-NOTFOUND'.  Named boolean constants are
	      case-insensitive.

		if(<variable>)

	      True if the variable's value is not a false constant.

		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(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 MATCHES regex)
		if(string MATCHES regex)

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

		if(variable LESS number)
		if(string LESS number)
		if(variable GREATER number)
		if(string GREATER number)
		if(variable EQUAL number)
		if(string EQUAL number)

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

		if(variable STRLESS string)
		if(string STRLESS string)
		if(variable STRGREATER string)
		if(string STRGREATER string)
		if(variable STREQUAL string)
		if(string STREQUAL string)

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

		if(version1 VERSION_LESS version2)
		if(version1 VERSION_EQUAL version2)
		if(version1 VERSION_GREATER version2)

	      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 statement was written fairly early in CMake's history and
	      it has some convenience features that are worth covering. The if
	      statement reduces operations until there is a  single  remaining
	      value,  at  that	point if the case insensitive value is: ON, 1,
	      YES, TRUE, Y it returns true, if it is OFF,  0,  NO,  FALSE,  N,
	      NOTFOUND, *-NOTFOUND, IGNORE it will return false.

	      This  is	fairly	reasonable. The convenience feature that some‐
	      times throws new authors is how CMake handles values that do not
	      match  the true or false list. Those values are treated as vari‐
	      ables and are dereferenced even though  they  do	not  have  the
	      required ${} syntax. This means that if you write

		if (boobah)

	      CMake will treat it as if you wrote

		if (${boobah})

	      likewise if you write

		if (fubar AND sol)

	      CMake will conveniently treat it as

		if ("${fubar}" AND "${sol}")

	      The  later is really the correct way to write it, but the former
	      will work as well. Only some operations in the if statement have
	      this special handling of arguments. The specific details follow:

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

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

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

	      4)  Both	left and right hand arguments to STRLESS STREQUAL STR‐
	      GREATER are independently tested to  see	if  they  are  defined
	      variables,  if  so  their	 defined values are used otherwise the
	      original value is used.

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

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

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

       include
	      Read CMake listfile code from the given file.

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

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

	      If  a  module is specified instead of a file, the file with name
	      <modulename>.cmake is searched in the CMAKE_MODULE_PATH.

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

       list   List operations.

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

	      LENGTH will return a given list's length.

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

	      APPEND will append elements to the list.

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

	      INSERT  will  insert elements to the list to the specified loca‐
	      tion.

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

	      REMOVE_DUPLICATES will remove duplicated items in the list.

	      REVERSE reverses the contents of the list in-place.

	      SORT sorts the list in-place alphabetically.

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

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

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

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

	      Define a macro named <name> that takes arguments named arg1 arg2
	      arg3 (...).  Commands listed after macro, but before the	match‐
	      ing  endmacro, are not invoked until the macro is invoked.  When
	      it is invoked, the commands recorded in the macro are first mod‐
	      ified  by	 replacing  formal parameters (${arg1}) with the argu‐
	      ments passed, and then invoked as normal commands.  In  addition
	      to  referencing the formal parameters you can reference the val‐
	      ues ${ARGC} which will be set to the number of arguments	passed
	      into  the	 function  as  well  as ${ARGV0} ${ARGV1} ${ARGV2} ...
	      which will have the actual values of the	arguments  passed  in.
	      This  facilitates creating macros with optional arguments. Addi‐
	      tionally ${ARGV} holds the list of all arguments	given  to  the
	      macro  and  ${ARGN}  holds  the  list  of argument past the last
	      expected argument. Note that the parameters to a macro and  val‐
	      ues  such	 as  ARGN  are not variables in the usual CMake sense.
	      They are string replacements much like the c preprocessor	 would
	      do  with	a  macro.  If you want true CMake variables you should
	      look at the function command.

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

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

		make_directory(directory)

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

       mark_as_advanced
	      Mark cmake cached variables as advanced.

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

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

	      It does nothing in script mode.

       math   Mathematical expressions.

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

	      EXPR evaluates mathematical expression and return 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 but skip generation
		FATAL_ERROR    = CMake Error, stop all processing

	      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.

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

		remove(VAR VALUE VALUE ...)

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

       return Return from a file, directory or function.

		return()

	      Returns from a file, directory or function. When this command is
	      encountered in an included file  (via  include()	or  find_pack‐
	      age()),  it  causes  processing  of the current file to stop and
	      control is returned to the including file. If it is  encountered
	      in  a  file which is not included by another file, e.g. a CMake‐
	      Lists.txt, control is returned to the parent directory if	 there
	      is  one.	If return is called in a function, control is returned
	      to the caller of the function. Note that a macro is not a	 func‐
	      tion and does not handle return like a function does.

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

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

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

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

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

		separate_arguments(VARIABLE)

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

       set    Set a CMAKE 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.	 If CACHE is  present,
	      then  the <variable> is put in the cache. <type> and <docstring>
	      are then 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, then the <value> is always	 written  into
	      the cache, replacing any values existing in the cache.  If it is
	      not a cache variable, then this always writes into  the  current
	      makefile. The FORCE option will overwrite the cache value remov‐
	      ing any changes by the user.

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

	      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.

       set_directory_properties
	      Set a property of the directory.

		set_directory_properties(PROPERTIES prop1 value1 prop2 value2)

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

       set_property
	      Set a named property in a given scope.

		set_property(<GLOBAL				|
			      DIRECTORY [dir]			|
			      TARGET	[target1 [target2 ...]] |
			      SOURCE	[src1 [src2 ...]]	|
			      TEST	[test1 [test2 ...]]	|
			      CACHE	[entry1 [entry2 ...]]>
			     [APPEND]
			     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.

	      TEST scope may name zero or more existing tests.

	      CACHE scope must name zero or more cache existing entries.

	      The required PROPERTY option is immediately followed by the name
	      of the property to set.  Remaining arguments are used to compose
	      the  property  value  in the form of a semicolon-separated list.
	      If the APPEND option is given the list is appended to any exist‐
	      ing property value.

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

		site_name(variable)

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

	      REGEX MATCH will match the regular expression once and store the
	      match in the output variable.

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

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

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

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

	      ASCII  will convert all numbers into corresponding ASCII charac‐
	      ters.

	      CONFIGURE will transform a string like CONFIGURE_FILE transforms
	      a file.

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

	      LENGTH will return a given string's length.

	      SUBSTRING will return a substring of a given string.

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

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

	      The following characters have special meaning in regular expres‐
	      sions:

		 ^	   Matches at beginning of a line
		 $	   Matches at end of a line
		 .	   Matches any single character
		 [ ]	   Matches any character(s) inside the brackets
		 [^ ]	   Matches any character(s) not inside the brackets
		  -	   Matches any character in range on either side of a dash
		 *	   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).

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

		unset(<variable> [CACHE])

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

	      <variable> can be an environment variable such as:

		unset(ENV{LD_LIBRARY_PATH})

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

       variable_watch
	      Watch the CMake variable for change.

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

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

       while  Evaluate a group of commands while a condition is true

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

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

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

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

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

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

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

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

       This is the documentation for the properties supported by CMake.	 Prop‐
       erties  can  have  different  scopes.  They can either be assigned to a
       source file, a directory, a target or globally to CMake.	 By  modifying
       the  values of properties the behaviour of the build system can be cus‐
       tomized.

COMPATIBILITY COMMANDS
	 CMake Compatibility Listfile Commands - Obsolete commands supported by CMake for compatibility.

       This is the documentation for now obsolete listfile commands from  pre‐
       vious  CMake versions, which are still supported for compatibility rea‐
       sons. You should instead use the newer, faster  and  shinier  new  com‐
       mands. ;-)

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

       Redistribution and use in source and binary forms, with or without mod‐
       ification,  are	permitted  provided  that the following conditions are
       met:

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

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

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

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

SEE ALSO
       cmake(1), ccmake(1)

       The following resources are available to get help using CMake:

       Home Page
	      http://www.cmake.org

	      The primary starting point for learning about CMake.

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

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

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

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

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

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

       Summary of helpful links:

	 Home: http://www.cmake.org
	 Docs: http://www.cmake.org/HTML/Documentation.html
	 Mail: http://www.cmake.org/HTML/MailingLists.html
	 FAQ:  http://www.cmake.org/Wiki/CMake_FAQ

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

ctest 2.8.1			March 21, 2010			      ctest(1)
[top]

List of man pages available for Mandriva

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

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

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