👤


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

Linux & Unix Commands - Search Man Pages

Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


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-generated build trees cre-
       ated 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 configurations in the same
	      tree.  This option can be used to specify which one should be tested.  Example con-
	      figurations 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 debug-
	      ging 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 environment variable CTEST_OUTPUT_ON_FAILURE

       -F     Enable failover.

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

       -j <jobs>, --parallel <jobs>
	      Run the tests in parallel using thegiven number of jobs.

	      This option tells ctest to run the tests in parallel using given number of jobs.

       -Q,--quiet
	      Make ctest quiet.

	      This option will suppress all the output. The output log file will still be  gener-
	      ated  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 perform a dashboard
	      test. All tests are <Mode><Test>, where Mode can be Experimental, Nightly, and Con-
	      tinuous,	and Test can be Start, Update, Configure, Build, Test, Coverage, and Sub-
	      mit.

       -D <var>:<type>=<value>
	      Define a variable for script mode

	      Pass in variable values on the command line. Use in conjunction  with  -S  to  pass
	      variable	values	to a dashboard script. Parsing -D arguments as variable values is
	      only attempted if the value following -D does not match any of the known	dashboard
	      types.

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

	      This  option tells ctest to act as a Dart client where the TestModel can be Experi-
	      mental, 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 dash-
	      board 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 directories. 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 environ-
	      ment 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 annoy-
	      ing.

       --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-inter-
	      active  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 not to 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	specified.   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-generator-toolset
	      Specify the generator-specific toolset.

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

	      This  option  tells CTest to use different initialization file instead of CTestCon-
	      figuration.tcl. This way multiple initialization files can be used for  example  to
	      submit to multiple dashboards.

       --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 time-
	      out set on them.

       --stop-time <time>
	      Set a time at which all tests should stop running.

	      Set a real time of day at which all tests should timeout. Example:  7:00:00  -0400.
	      Any  time  format  understood  by  the  curl date parser is accepted. Local time is
	      assumed if no timezone is specified.

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

       --print-labels
	      Print all available test labels.

	      This  option  will  not  run any tests, it will simply print the list of all labels
	      associated with the test set.

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

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

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

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

	      Usage describes the basic command line interface and its options.

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

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

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

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

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

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

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

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

GENERATORS
       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 platform and compiler set-
	      tings.   These values are now available through the CMAKE_SYSTEM and CMAKE_CXX_COM-
	      PILER variables.

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

		cmake_minimum_required(VERSION major[.minor[.patch[.tweak]]]
				       [FATAL_ERROR])

	      If the current version of CMake is lower than that required it will stop processing
	      the  project  and report an error.  When a version higher than 2.4 is specified the
	      command implicitly invokes

		cmake_policy(VERSION major[.minor[.patch[.tweak]]])

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

		cmake_policy(VERSION 2.4)

	      which enables compatibility features for CMake 2.4 and lower.

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

       cmake_policy
	      Manage CMake Policy settings.

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

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

		cmake_policy(VERSION major.minor[.patch[.tweak]])

	      Specify that the current CMake list file is written for the given version of CMake.
	      All  policies introduced in the specified version or earlier will be set to use NEW
	      behavior.  All policies introduced  after  the  specified  version  will	be  unset
	      (unless  variable CMAKE_POLICY_DEFAULT_CMP<NNNN> sets a default).  This effectively
	      requests behavior preferred as of a given CMake version and tells newer CMake  ver-
	      sions  to  warn  about their new policies.  The policy version specified must be at
	      least 2.4 or the command will report an error.  In order to get compatibility  fea-
	      tures supporting versions earlier than 2.4 see documentation of policy CMP0001.

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

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

		cmake_policy(GET CMP<NNNN> <variable>)

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

	      CMake keeps policy settings on a stack, so changes made by the cmake_policy command
	      affect only the top of the stack.  A new entry on the policy stack is managed auto-
	      matically  for  each  subdirectory to protect its parents and siblings.  CMake also
	      manages a new entry for scripts loaded by  include()  and  find_package()  commands
	      except when invoked with the NO_POLICY_SCOPE option (see also policy CMP0011).  The
	      cmake_policy command provides an interface to manage custom entries on  the  policy
	      stack:

		cmake_policy(PUSH)
		cmake_policy(POP)

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

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

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

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

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

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

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

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

	      With NEWLINE_STYLE the line ending could be adjusted:

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

	      COPYONLY must not be used with NEWLINE_STYLE.

       ctest_build
	      Build the project.

		ctest_build([BUILD build_dir] [TARGET target] [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  TARGET  variable can be used to specify a build target.  If none is specified,
	      the "all" target will be built.

	      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 vari-
	      ables 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 dash-
	      board server since the last ctest_start.	Append semantics are defined by the dash-
	      board 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  Configure.xml.  If  no
	      BUILD is given, the CTEST_BINARY_DIRECTORY variable is used. If no SOURCE is given,
	      the CTEST_SOURCE_DIRECTORY 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 dash-
	      board server since the last ctest_start.	Append semantics are defined by the dash-
	      board 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  Cover-
	      age.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 dash-
	      board server since the last ctest_start.	Append semantics are defined by the dash-
	      board 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 MemCheck.xml. The second
	      argument is a variable that will hold value. Optionally, you can specify the start-
	      ing  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 regu-
	      lar  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 dash-
	      board server since the last ctest_start.	Append semantics are defined by the dash-
	      board 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 vari-
	      ables. If NEW_PROCESS is specified then each script  will  be  run  in  a  separate
	      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>)

	      Sleep for given number of seconds.

		ctest_sleep(<time1> <duration> <time2>)

	      Sleep for t=(time1 + duration - time2) seconds if t > 0.

       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 ...] [RETRY_COUNT count]		[RETRY_DELAY delay][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 submitted.  Each  individual
	      file must exist at the time of the call.

	      The RETRY_DELAY option specifies how long in seconds to wait after a timed-out sub-
	      mission before attempting to re-submit.

	      The RETRY_COUNT option specifies how many times to retry a timed-out submission.

       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]
			   [STOP_TIME time of day])

	      Tests the given build directory and stores results in Test.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 to not run EXCLUDE. EXCLUDE_LABEL and INCLUDE_LABEL are  regular  expres-
	      sion 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 dependencies. STOP_TIME is the time of  day	at  which
	      the tests should all stop running.

	      The APPEND option marks results for append to those previously submitted to a dash-
	      board server since the last ctest_start.	Append semantics are defined by the dash-
	      board 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.

       ctest_upload
	      Upload files to a dashboard server.

		ctest_upload(FILES ...)

	      Pass a list of files to be sent along with  the  build  results  to  the	dashboard
	      server.

       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 CMakeList.txt file.

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

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

       execute_process
	      Execute one or more child processes.

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

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

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

       file   File manipulation command.

		file(WRITE filename "message to write"... )
		file(APPEND filename "message to write"... )
		file(READ filename variable [LIMIT numBytes] [OFFSET offset] [HEX])
		file(<MD5|SHA1|SHA224|SHA256|SHA384|SHA512> filename variable)
		file(STRINGS filename variable [LIMIT_COUNT num]
		     [LIMIT_INPUT numBytes] [LIMIT_OUTPUT numBytes]
		     [LENGTH_MINIMUM numBytes] [LENGTH_MAXIMUM numBytes]
		     [NEWLINE_CONSUME] [REGEX regex]
		     [NO_HEX_CONVERSION])
		file(GLOB variable [RELATIVE path] [globbing expressions]...)
		file(GLOB_RECURSE variable [RELATIVE path]
		     [FOLLOW_SYMLINKS] [globbing expressions]...)
		file(RENAME <oldname> <newname>)
		file(REMOVE [file1 ...])
		file(REMOVE_RECURSE [file1 ...])
		file(MAKE_DIRECTORY [directory1 directory2 ...])
		file(RELATIVE_PATH variable directory file)
		file(TO_CMAKE_PATH path result)
		file(TO_NATIVE_PATH path result)
		file(DOWNLOAD url file [INACTIVITY_TIMEOUT timeout]
		     [TIMEOUT timeout] [STATUS status] [LOG log] [SHOW_PROGRESS]
		     [EXPECTED_HASH ALGO=value] [EXPECTED_MD5 sum]
		     [TLS_VERIFY on|off] [TLS_CAINFO file])
		file(UPLOAD filename url [INACTIVITY_TIMEOUT timeout]
		     [TIMEOUT timeout] [STATUS status] [LOG log] [SHOW_PROGRESS])
		file(TIMESTAMP filename variable [<format string>] [UTC])

	      WRITE will write a message into a file called 'filename'. It overwrites the file if
	      it already exists, and creates the file if it does not exist. (If  the  file  is	a
	      build input, use configure_file to update the file only when its content changes.)

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

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

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

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

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

	      REGEX specifies a regular expression that a string must match to be returned. Typi-
	      cal usage

		file(STRINGS myfile.txt myfile)

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

	      GLOB  will  generate  a  list  of all files that match the globbing expressions and
	      store it into the variable. Globbing expressions are  similar  to  regular  expres-
	      sions,  but  much  simpler.  If  RELATIVE  flag is specified for an expression, the
	      results will be returned as a relative path to the given path.  (We do  not  recom-
	      mend  using  GLOB  to  collect a list of source files from your source tree.  If no
	      CMakeLists.txt file changes when a source is added or removed  then  the	generated
	      build system cannot know when to ask CMake to regenerate.)

	      Examples of globbing expressions include:

		 *.cxx	    - match all files with extension cxx
		 *.vt?	    - match all files with extension vta,...,vtz
		 f[3-5].txt - match files f3.txt, f4.txt, f5.txt

	      GLOB_RECURSE  will generate a list similar to the regular GLOB, except it will tra-
	      verse all the subdirectories of the matched directory and match the  files.  Subdi-
	      rectories that are symlinks are only traversed if FOLLOW_SYMLINKS is given or cmake
	      policy CMP0009 is not set to NEW. See cmake --help-policy CMP0009 for more informa-
	      tion.

	      Examples of recursive globbing include:

		 /dir/*.py  - match all python files in /dir and subdirectories

	      MAKE_DIRECTORY  will create the given directories, also if their parent directories
	      don't exist yet

	      RENAME moves a file or directory within a  filesystem,  replacing  the  destination
	      atomically.

	      REMOVE will remove the given files, also in subdirectories

	      REMOVE_RECURSE will remove the given files and directories, also non-empty directo-
	      ries

	      RELATIVE_PATH will determine relative path from directory to the given file.

	      TO_CMAKE_PATH will convert path into a cmake style path with unix /.  The input can
	      be a single path or a system path like "$ENV{PATH}".  Note the double quotes around
	      the ENV call TO_CMAKE_PATH only takes  one argument. This command will also convert
	      the native list delimiters for a list of paths like the PATH environment variable.

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

	      DOWNLOAD will download the given URL to the given file. If LOG var is  specified	a
	      log  of  the  download will be put in var. If STATUS var is specified the status of
	      the operation will be put in var. The status is returned in a list of length 2. The
	      first element is the numeric return value for the operation, and the second element
	      is a string value for the error. A 0 numeric error means no error in the operation.
	      If  TIMEOUT  time is specified, the operation will timeout after time seconds, time
	      should be specified as an integer. The INACTIVITY_TIMEOUT specifies an integer num-
	      ber  of  seconds	of  inactivity	after  which  the  operation should terminate. If
	      EXPECTED_HASH ALGO=value is specified, the operation will  verify  that  the  down-
	      loaded  file's  actual  hash  matches the expected value, where ALGO is one of MD5,
	      SHA1, SHA224, SHA256, SHA384, or SHA512.	If it does not match, the operation fails
	      with  an	error. ("EXPECTED_MD5 sum" is short-hand for "EXPECTED_HASH MD5=sum".) If
	      SHOW_PROGRESS is specified, progress information will be printed as status messages
	      until  the  operation is complete. For https URLs CMake must be built with OpenSSL.
	      TLS/SSL certificates are not checked by default.	Set TLS_VERIFY	to  ON	to  check
	      certificates and/or use EXPECTED_HASH to verify downloaded content.  Set TLS_CAINFO
	      to specify a custom Certificate Authority file.  If either TLS option is not  given
	      CMake will check variables CMAKE_TLS_VERIFY and CMAKE_TLS_CAINFO, respectively.

	      UPLOAD  will  upload the given file to the given URL. If LOG var is specified a log
	      of the upload will be put in var. If STATUS var is  specified  the  status  of  the
	      operation  will  be  put	in var. The status is returned in a list of length 2. The
	      first element is the numeric return value for the operation, and the second element
	      is a string value for the error. A 0 numeric error means no error in the operation.
	      If TIMEOUT time is specified, the operation will timeout after time  seconds,  time
	      should be specified as an integer. The INACTIVITY_TIMEOUT specifies an integer num-
	      ber of seconds of  inactivity  after  which  the	operation  should  terminate.  If
	      SHOW_PROGRESS is specified, progress information will be printed as status messages
	      until the operation is complete.

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

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

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

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

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

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

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

       find_file
	      Find the full path to a file.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 INCLUDE

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

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

       find_library
	      Find a library.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 LIB

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

		 <prefix>/lib/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/lib for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_LIBRARY_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

	      When  more than one value is given to the NAMES option this command by default will
	      consider one name at a time and search every directory for it.   The  NAMES_PER_DIR
	      option  tells  this  command to consider one directory at a time and search for all
	      names in it.

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

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

       find_package
	      Load settings for an external project.

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

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

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

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

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

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

	      The complete Config mode command signature is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	      In  all  cases  the <name> is treated as case-insensitive and corresponds to any of
	      the names specified (<package> or names given by NAMES).	Paths with lib/<arch> are
	      enabled  if  CMAKE_LIBRARY_ARCHITECTURE  is set.	If PATH_SUFFIXES is specified the
	      suffixes are appended to each (W) or (U) directory entry one-by-one.

	      This set of directories is intended to work in cooperation with projects that  pro-
	      vide  configuration  files  in  their installation trees.  Directories above marked
	      with (W) are intended for installations on Windows where the prefix  may	point  at
	      the  top	of  an	application's  installation directory.	Those marked with (U) are
	      intended for installations on UNIX platforms where the prefix is shared by multiple
	      packages.   This	is  merely a convention, so all (W) and (U) directories are still
	      searched on all platforms.  Directories marked with (A) are intended for	installa-
	      tions   on   Apple   platforms.	 The  cmake  variables	CMAKE_FIND_FRAMEWORK  and
	      CMAKE_FIND_APPBUNDLE determine the order of preference as specified below.

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

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

		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

		 <package>_DIR
		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

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

		 PATH

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

	      6.  Search paths stored in the CMake user package registry.  This can be skipped if
	      NO_CMAKE_PACKAGE_REGISTRY is passed.  On Windows a <package> may appear under  reg-
	      istry key

		HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\<package>

	      as a REG_SZ value, with arbitrary name, that specifies the directory containing the
	      package configuration file.  On UNIX platforms a <package>  may  appear  under  the
	      directory

		~/.cmake/packages/<package>

	      as  a  file,  with arbitrary name, whose content specifies the directory containing
	      the package configuration file.  See the export(PACKAGE)	command  to  create  user
	      package registry entries for project build trees.

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

		 CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH
		 CMAKE_SYSTEM_APPBUNDLE_PATH

	      8. Search paths stored in the CMake system package registry.  This can  be  skipped
	      if  NO_CMAKE_SYSTEM_PACKAGE_REGISTRY  is passed.	On Windows a <package> may appear
	      under registry key

		HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<package>

	      as a REG_SZ value, with arbitrary name, that specifies the directory containing the
	      package  configuration  file.   There  is no system package registry on non-Windows
	      platforms.

	      9. Search paths specified by the PATHS  option.	These  are  typically  hard-coded
	      guesses.

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

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

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

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

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

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

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

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

	      Every  non-REQUIRED  find_package()  call  can  be disabled by setting the variable
	      CMAKE_DISABLE_FIND_PACKAGE_<package>  to	TRUE.  See  the  documentation	for   the
	      CMAKE_DISABLE_FIND_PACKAGE_<package> variable for more information.

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

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

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

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

       find_path
	      Find the directory containing a file.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 INCLUDE

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

		 <prefix>/include/<arch> if CMAKE_LIBRARY_ARCHITECTURE is set, and
		 <prefix>/include for each <prefix> in CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_INCLUDE_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH

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

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

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

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

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

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

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

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

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

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

       find_program
	      Find an executable program.

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

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

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

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

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

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

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

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

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

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

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

		 PATH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	      A function opens a new scope: see set(var PARENT_SCOPE) for details.

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

       get_cmake_property
	      Get a property of the CMake instance.

		get_cmake_property(VAR property)

	      Get a property from the CMake instance.  The value of the property is stored in the
	      variable VAR.  If the property is not found, VAR will be set to  "NOTFOUND".   Some
	      supported  properties  include:  VARIABLES,  CACHE_VARIABLES, COMMANDS, MACROS, and
	      COMPONENTS.

	      See also the more general get_property() command.

       get_directory_property
	      Get a property of DIRECTORY scope.

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

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

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

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

	      See also the more general get_property() command.

       get_filename_component
	      Get a specific component of a full filename.

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

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

	       PATH	 = Directory without file name
	       NAME	 = File name without directory
	       EXT	 = File name longest extension (.b.c from d/a.b.c)
	       NAME_WE	 = File name without directory or longest extension
	       ABSOLUTE  = Full path to file
	       REALPATH  = Full path to existing file with symlinks resolved

	      Paths are returned with forward slashes and have no trailing  slahes.  The  longest
	      file  extension  is always considered. If the optional CACHE argument is specified,
	      the result variable is added to the cache.

		get_filename_component(<VAR> FileName
				       PROGRAM [PROGRAM_ARGS <ARG_VAR>]
				       [CACHE])

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

       get_property
	      Get a property.

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

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

	      GLOBAL scope is unique and does not accept a name.

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

	      TARGET scope must name one existing target.

	      SOURCE scope must name one source file.

	      TEST scope must name one existing test.

	      CACHE scope must name one cache entry.

	      VARIABLE scope is unique and does not accept a name.

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

       if     Conditionally execute a group of commands.

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

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

		if(<constant>)

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

		if(<variable>)

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

		if(NOT <expression>)

	      True if the expression is not true.

		if(<expr1> AND <expr2>)

	      True if both expressions would be considered true individually.

		if(<expr1> OR <expr2>)

	      True if either expression would be considered true individually.

		if(COMMAND command-name)

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

		if(POLICY policy-id)

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

		if(TARGET target-name)

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

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

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

		if(file1 IS_NEWER_THAN file2)

	      True  if file1 is newer than file2 or if one of the two files doesn't exist. Behav-
	      ior is well-defined only for full paths. If the file time stamps	are  exactly  the
	      same,  an IS_NEWER_THAN comparison returns true, so that any dependent build opera-
	      tions will occur in the event of a tie. This includes the case of passing the  same
	      file name for both file1 and file2.

		if(IS_DIRECTORY directory-name)

	      True  if	the  given  name  is a directory.  Behavior is well-defined only for full
	      paths.

		if(IS_SYMLINK file-name)

	      True if the given name is a symbolic link.  Behavior is well-defined only for  full
	      paths.

		if(IS_ABSOLUTE path)

	      True if the given path is an absolute path.

		if(<variable|string> MATCHES regex)

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

		if(<variable|string> LESS <variable|string>)
		if(<variable|string> GREATER <variable|string>)
		if(<variable|string> EQUAL <variable|string>)

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

		if(<variable|string> STRLESS <variable|string>)
		if(<variable|string> STRGREATER <variable|string>)
		if(<variable|string> STREQUAL <variable|string>)

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

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

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

		if(DEFINED <variable>)

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

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

	      The  expressions	inside the parenthesis are evaluated first and then the remaining
	      expression is evaluated as in the previous examples. Where there are nested  paren-
	      thesis  the  innermost are evaluated as part of evaluating the expression that con-
	      tains them.

	      The if command was written very early in CMake's history, predating the  ${}  vari-
	      able  evaluation syntax, and for convenience evaluates variables named by its argu-
	      ments as shown in the above signatures.  Note that normal variable evaluation  with
	      ${} applies before the if command even receives the arguments.  Therefore code like

		set(var1 OFF)
		set(var2 "var1")
		if(${var2})

	      appears to the if command as

		if(var1)

	      and is evaluated according to the if(<variable>) case documented above.  The result
	      is OFF which is false.  However, if we remove the ${} from  the  example	then  the
	      command sees

		if(var2)

	      which is true because var2 is defined to "var1" which is not a false constant.

	      Automatic  evaluation applies in the other cases whenever the above-documented sig-
	      nature accepts <variable|string>:

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

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

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

	      4)  Both	left and right hand arguments to STRLESS STREQUAL STRGREATER are indepen-
	      dently tested to see if they are defined variables, if so their defined values  are
	      used otherwise the original value is used.

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

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

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

       include
	      Read CMake listfile code from the given file.

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

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

	      If  a  module is specified instead of a file, the file with name <modulename>.cmake
	      is searched first in CMAKE_MODULE_PATH, then in the CMake module	directory.  There
	      is  one  exception  to this: if the file which calls include() is located itself in
	      the CMake module directory, then first the CMake module directory is  searched  and
	      CMAKE_MODULE_PATH afterwards. See also policy CMP0017.

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

       list   List operations.

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

	      LENGTH will return a given list's length.

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

	      APPEND will append elements to the list.

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

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

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

	      REMOVE_DUPLICATES will remove duplicated items in the list.

	      REVERSE reverses the contents of the list in-place.

	      SORT sorts the list in-place alphabetically.

	      The  list  subcommands  APPEND,  INSERT, REMOVE_AT, REMOVE_ITEM, REMOVE_DUPLICATES,
	      REVERSE and SORT may create new values for the list within the current CMake  vari-
	      able  scope. Similar to the SET command, the LIST command creates new variable val-
	      ues in the current scope, even if the list itself is actually defined in	a  parent
	      scope.  To  propagate  the  results  of these operations upwards, use SET with PAR-
	      ENT_SCOPE, SET with CACHE INTERNAL, or some other means of value propagation.

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

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

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

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

	      Define a macro named <name> that takes arguments named arg1 arg2 arg3 (...).   Com-
	      mands  listed  after macro, but before the matching endmacro, are not invoked until
	      the macro is invoked.  When it is invoked, the commands recorded in the  macro  are
	      first  modified by replacing formal parameters (${arg1}) with the arguments passed,
	      and then invoked as normal commands. In addition to referencing the formal  parame-
	      ters  you can reference the values ${ARGC} which will be set to the number of argu-
	      ments passed into the function as well as ${ARGV0} ${ARGV1} ${ARGV2} ... which will
	      have the actual values of the arguments passed in. This facilitates creating macros
	      with optional arguments. Additionally ${ARGV} holds the list of all arguments given
	      to  the  macro and ${ARGN} holds the list of arguments past the last expected argu-
	      ment. Note that the parameters to a macro and values such as ARGN are not variables
	      in the usual CMake sense. They are string replacements much like the C preprocessor
	      would do with a macro. If you want true CMake variables and/or better  CMake  scope
	      control you should look at the function command.

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

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

		make_directory(directory)

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

       mark_as_advanced
	      Mark cmake cached variables as advanced.

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

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

	      It does nothing in script mode.

       math   Mathematical expressions.

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

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

       message
	      Display a message to the user.

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

	      The optional keyword determines the type of message:

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

	      The CMake command-line tool displays STATUS messages on stdout and all  other  mes-
	      sage  types  on  stderr.	The CMake GUI displays all messages in its log area.  The
	      interactive dialogs (ccmake and CMakeSetup) show STATUS messages one at a time on a
	      status line and other messages in interactive pop-up boxes.

	      CMake  Warning  and  Error  message  text  displays using a simple markup language.
	      Non-indented text is formatted in line-wrapped paragraphs  delimited  by	newlines.
	      Indented text is considered pre-formatted.

       option Provides an option that the user can optionally select.

		option(<option_variable> "help string describing option"
		       [initial value])

	      Provide an option for the user to select as ON or OFF.  If no initial value is pro-
	      vided, OFF is used.

	      If you have options that depend on the values of other options, see the module help
	      for CMakeDependentOption.

       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_package()), it causes processing of the cur-
	      rent file to stop and control is returned to the including file. If it  is  encoun-
	      tered  in a file which is not included by another file, e.g. a CMakeLists.txt, con-
	      trol is returned to the parent directory if there is one. If return is called in	a
	      function,  control  is returned to the caller of the function. Note that a macro is
	      not a function and does not handle return like a function does.

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

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

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

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

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

		separate_arguments(VARIABLE)

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

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

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

	      Within  CMake  sets  <variable>  to  the value <value>.  <value> is expanded before
	      <variable> is set to it.	Normally, set will set a regular CMake variable. If CACHE
	      is  present,  then the <variable> is put in the cache instead, unless it is already
	      in the cache. See section 'Variable types in CMake' below for  details  of  regular
	      and  cache  variables  and  their  interactions. If CACHE is used, <type> and <doc-
	      string> are required. <type> is used by the CMake GUI to choose a widget with which
	      the user sets a value. The value for <type> may be one of

		FILEPATH = File chooser dialog.
		PATH	 = Directory chooser dialog.
		STRING	 = Arbitrary string.
		BOOL	 = Boolean ON/OFF checkbox.
		INTERNAL = No GUI entry (used for persistent variables).

	      If  <type>  is  INTERNAL, the cache variable is marked as internal, and will not be
	      shown to the user in tools like cmake-gui. This is intended for values that  should
	      be  persisted  in  the  cache, but which users should not normally change. INTERNAL
	      implies FORCE.

	      Normally, set(...CACHE...) creates cache variables, but does not	modify	them.  If
	      FORCE is specified, the value of the cache variable is set, even if the variable is
	      already in the cache. This should normally  be  avoided,	as  it	will  remove  any
	      changes to the cache variable's value by the user.

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

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

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

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

	      <variable> can be an environment variable such as:

		set( ENV{PATH} /home/martink )

	      in which case the environment variable will be set.

	      *** Variable types in CMake ***

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

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

	      Some examples:

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

	      The  code 'set(FOO "x" CACHE ...)' checks for 'FOO' in the cache, ignoring any nor-
	      mal variable of the same name. If 'FOO' is in the cache  then  nothing  happens  to
	      either  the  normal  variable  or the cache variable. If 'FOO' is not in the cache,
	      then it is added to the cache.

	      Finally, whenever a cache variable is added or modified by a  command,  CMake  also
	      *removes*  the  normal  variable of the same name from the current scope so that an
	      immediately following evaluation of it will expose the newly cached value.

	      Normally projects should avoid using normal and cache variables of the  same  name,
	      as  this	interaction  can be hard to follow. However, in some situations it can be
	      useful. One example (used by some projects):

	      A project has a subproject in its source tree. The child project has its own CMake-
	      Lists.txt,  which  is  included  from the parent CMakeLists.txt using add_subdirec-
	      tory(). Now, if the parent and the child project provide the same option (for exam-
	      ple  a  compiler	option),  the parent gets the first chance to add a user-editable
	      option to the cache. Normally, the child would then use the  same  value	that  the
	      parent  uses.  However,  it  may	be necessary to hard-code the value for the child
	      project's option while still allowing the user to edit the value used by the parent
	      project.	The  parent  project can achieve this simply by setting a normal variable
	      with the same name as the option in a scope sufficient to hide the  option's  cache
	      variable	from the child completely. The parent has already set the cache variable,
	      so the child's set(...CACHE...) will do nothing, and evaluating the option variable
	      will use the value from the normal variable, which hides the cache variable.

       set_directory_properties
	      Set a property of the directory.

		set_directory_properties(PROPERTIES prop1 value1 prop2 value2)

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

       set_property
	      Set a named property in a given scope.

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

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

	      GLOBAL scope is unique and does not accept a name.

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

	      TARGET scope may name zero or more existing targets.

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

	      TEST scope may name zero or more existing tests.

	      CACHE scope must name zero or more cache existing entries.

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

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

	      REGEX  MATCH will match the regular expression once and store the match in the out-
	      put variable.

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

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

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

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

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

	      ASCII will convert all numbers into corresponding ASCII characters.

	      CONFIGURE will transform a string like CONFIGURE_FILE transforms a file.

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

	      LENGTH will return a given string's length.

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

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

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

	      FIND  will  return the position where the given substring was found in the supplied
	      string. If the REVERSE flag was used, the command will search for the  position  of
	      the last occurrence of the specified substring.

	      The following characters have special meaning in regular expressions:

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

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

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

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

	      The  optional UTC flag requests the current date/time representation to be in Coor-
	      dinated Universal Time (UTC) rather than local time.

	      The optional <format string> may contain the following format specifiers:

		 %d	   The day of the current month (01-31).
		 %H	   The hour on a 24-hour clock (00-23).
		 %I	   The hour on a 12-hour clock (01-12).
		 %j	   The day of the current year (001-366).
		 %m	   The month of the current year (01-12).
		 %M	   The minute of the current hour (00-59).
		 %S	   The second of the current minute.
			   60 represents a leap second. (00-60)
		 %U	   The week number of the current year (00-53).
		 %w	   The day of the current week. 0 is Sunday. (0-6)
		 %y	   The last two digits of the current year (00-99)
		 %Y	   The current year.

	      Unknown format specifiers will be ignored and copied to the output as-is.

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

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

       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.

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

		use_mangled_mesa(PATH_TO_MESA OUTPUT_DIRECTORY)

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

       variable_watch
	      Watch the CMake variable for change.

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

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

       while  Evaluate a group of commands while a condition is true

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

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

       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. Properties can have dif-
       ferent scopes. They can either be assigned to a source file,  a	directory,  a  target  or
       globally to CMake. By modifying the values of properties the behaviour of the build system
       can be customized.

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

       This is the documentation for now obsolete listfile commands from previous CMake versions,
       which  are  still  supported  for compatibility reasons. You should instead use the newer,
       faster and shinier new commands. ;-)

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

       Redistribution and use in source and binary forms, with or without modification, are  per-
       mitted provided that the following conditions are met:

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

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

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

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

SEE ALSO
       cmake(1), 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 questions.

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

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

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

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

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

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


All times are GMT -4. The time now is 02:55 AM.

Unix & Linux Forums Content Copyright©1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password





Not a Forum Member?
Forgot Password?