ctest man page on Cygwin

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

ctest(1)							      ctest(1)

NAME
	 ctest - Testing driver provided by CMake.

USAGE
	 ctest [options]

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

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

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

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

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

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

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

       --debug
	      Displaying more verbose internals of CTest.

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

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

       -F     Enable failover.

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

       -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  generated	 if  the  --output-log	is  specified.
	      Options  such  as	 --verbose,  --extra-verbose,  and --debug are
	      ignored if --quiet is specified.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       -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	 Test‐
	      Model can be Experimental, Nightly, and Continuous. Combining -M
	      and -T is similar to -D

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	      This  option  tells  ctest  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 spec‐
	      ified. Both --build-makeprogram and  --build-generator  MUST  be
	      provided to use --built-and-test. If --test-command is specified
	      then that will be run after the build is complete. Other options
	      that   affect  this  mode	 are  --build-target  --build-nocmake,
	      --build-run-dir,	    --build-two-config,	      --build-exe-dir,
	      --build-project,--build-noclean, --build-options

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

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

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

	      Skip the cmake step.

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

	      Directory where programs will be after it has been compiled.

       --build-two-config
	      Run CMake twice

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

       --build-generator
	      Specify the generator to use.

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

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

       --build-noclean
	      Skip the make clean step.

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

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

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

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

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

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

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

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

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

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

       --overwrite
	      Overwrite CTest configuration option.

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

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

	      This option will submit extra files to the dashboard.

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

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

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

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

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

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

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

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

       --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. Exam‐
	      ple: 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 specified, the help is written into it.

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

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

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

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

GENERATORS
       The following generators are available on this platform:

COMMANDS
       break  Break from an enclosing foreach or while loop.

		break()

	      Breaks from an enclosing foreach loop or while loop

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

		build_name(variable)

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

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

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

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

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

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

		cmake_policy(VERSION 2.4)

	      which enables compatibility features for CMake 2.4 and lower.

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

       cmake_policy
	      Manage CMake Policy settings.

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

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

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

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

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

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

		cmake_policy(GET CMP<NNNN> <variable>)

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

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

		cmake_policy(PUSH)
		cmake_policy(POP)

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

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

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

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

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

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

	      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 variables in which to store  the
	      number of build errors and warnings detected.

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

       ctest_configure
	      Configure the project build tree.

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

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

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

       ctest_coverage
	      Collect coverage tool results.

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

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

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

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

       ctest_empty_binary_directory
	      empties the binary directory

		ctest_empty_binary_directory( directory )

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

       ctest_memcheck
	      Run tests with a dynamic analysis tool.

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

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

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

       ctest_read_custom_files
	      read CTestCustom files.

		ctest_read_custom_files( directory ... )

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

       ctest_run_script
	      runs a ctest -S script

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

	      Runs a script or scripts much like if it was run from ctest  -S.
	      If  no argument is provided then the current script is run using
	      the current settings of the variables. If NEW_PROCESS is	speci‐
	      fied  then  each	script	will  be  run in a 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 submit‐
	      ted.  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 submission 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. Option‐
	      ally, you can specify the starting test number START, the ending
	      test  number  END, the number of tests to skip between each test
	      STRIDE, a regular expression for tests to run INCLUDE, or a reg‐
	      ular  expression for tests to not run EXCLUDE. EXCLUDE_LABEL and
	      INCLUDE_LABEL are regular expression for test to be included  or
	      excluded	by  the	 test property LABEL. PARALLEL_LEVEL should be
	      set to a positive number representing the number of tests to  be
	      run  in  parallel. SCHEDULE_RANDOM will launch tests in a random
	      order, and is typically used to detect implicit  test  dependen‐
	      cies. 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	dashboard  server  since the last ctest_start.
	      Append semantics are defined by the dashboard server in use.

       ctest_update
	      Update the work tree from version control.

		ctest_update([SOURCE source] [RETURN_VALUE res])

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

       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 CMake‐
	      List.txt file.

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

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

       execute_process
	      Execute one or more child processes.

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

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

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

       file   File manipulation command.

		file(WRITE filename "message to write"... )
		file(APPEND filename "message to write"... )
		file(READ filename variable [LIMIT numBytes] [OFFSET offset] [HEX])
		file(<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_MD5 sum])
		file(UPLOAD filename url [INACTIVITY_TIMEOUT timeout]
		     [TIMEOUT timeout] [STATUS status] [LOG log] [SHOW_PROGRESS])

	      WRITE  will  write  a  message into a file called 'filename'. It
	      overwrites the file if it already exists, and creates  the  file
	      if it does not exist.

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

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

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

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

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

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

		file(STRINGS myfile.txt myfile)

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

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

	      Examples of globbing expressions include:

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

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

	      Examples of recursive globbing include:

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

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

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

	      REMOVE will remove the given files, also in subdirectories

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

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

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

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

	      DOWNLOAD will download the given URL to the given file.  If  LOG
	      var  is  specified  a log of the download will be put in var. If
	      STATUS var is specified the status of the operation will be  put
	      in  var. The status is returned in a list of length 2. The first
	      element is the numeric return value for the operation,  and  the
	      second  element  is  a  string  value for the error. A 0 numeric
	      error means no error in the operation. If TIMEOUT time is speci‐
	      fied, the operation will timeout after time seconds, time should
	      be specified as an integer. The INACTIVITY_TIMEOUT specifies  an
	      integer  number  of seconds of inactivity after which the opera‐
	      tion should terminate. If EXPECTED_MD5  sum  is  specified,  the
	      operation	 will verify that the downloaded file's actual md5 sum
	      matches the expected value. If it does not match, the  operation
	      fails  with  an  error.  If SHOW_PROGRESS is specified, progress
	      information will be printed as status messages until the	opera‐
	      tion is complete.

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

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

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

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

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

       find_file
	      Find the full path to a file.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 INCLUDE

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

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

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

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

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

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

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

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

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

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

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

       find_library
	      Find a library.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 LIB

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

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

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

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

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

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

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

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

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

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

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

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

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

       find_package
	      Load settings for an external project.

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

	      Finds  and  loads	 settings  from	 an  external project.	<pack‐
	      age>_FOUND will be set  to  indicate  whether  the  package  was
	      found.   When  the package is found package-specific information
	      is provided through variables documented by the package  itself.
	      The  QUIET  option  disables  messages  if the package cannot be
	      found.  The MODULE option disables the  second  signature	 docu‐
	      mented  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	compo‐
	      nent  list is given to a recursive invocation inside a find-mod‐
	      ule, the corresponding  arguments	 are  forwarded	 automatically
	      from  the	 outer	call (including the EXACT flag for [version]).
	      Version support is currently provided only on a package-by-pack‐
	      age basis (details below).

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

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

	      The complete Config mode command signature is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

		 <package>_DIR
		 CMAKE_PREFIX_PATH
		 CMAKE_FRAMEWORK_PATH
		 CMAKE_APPBUNDLE_PATH

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

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

		 PATH

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

	      6. Search paths stored in the CMake user package registry.  This
	      can  be skipped if NO_CMAKE_PACKAGE_REGISTRY is passed.  On Win‐
	      dows a <package> may appear under registry key

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

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

		~/.cmake/packages/<package>

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

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

		 CMAKE_SYSTEM_PREFIX_PATH
		 CMAKE_SYSTEM_FRAMEWORK_PATH
		 CMAKE_SYSTEM_APPBUNDLE_PATH

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

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

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

	      9.  Search paths specified by the PATHS option.  These are typi‐
	      cally hard-coded guesses.

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

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

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

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

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

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

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

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

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

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

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

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

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

       find_path
	      Find the directory containing a file.

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

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

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

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

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

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

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

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

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

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

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

		 PATH
		 INCLUDE

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

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

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

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

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

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

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

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

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

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

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

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

       find_program
	      Find an executable program.

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

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

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

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

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

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

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

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

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

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

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

		 PATH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       get_cmake_property
	      Get a property of the CMake instance.

		get_cmake_property(VAR property)

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

	      See also the more general get_property() command.

       get_directory_property
	      Get a property of DIRECTORY scope.

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

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

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

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

	      See also the more general get_property() command.

       get_filename_component
	      Get a specific component of a full filename.

		get_filename_component(<VAR> FileName
				       PATH|ABSOLUTE|NAME|EXT|NAME_WE|REALPATH
				       [CACHE])

	      Set  <VAR>  to be the path (PATH), file name (NAME), file exten‐
	      sion (EXT), file name without extension (NAME_WE)	 of  FileName,
	      the  full	 path  (ABSOLUTE),  or the full path with all symlinks
	      resolved (REALPATH).  Note that the path is  converted  to  Unix
	      slashes  format  and  has	 no trailing slashes. The longest file
	      extension is always considered. If the optional  CACHE  argument
	      is specified, the result variable is added to the cache.

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

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

       get_property
	      Get a property.

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

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

	      GLOBAL scope is unique and does not accept a name.

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

	      TARGET scope must name one existing target.

	      SOURCE scope must name one source file.

	      TEST scope must name one existing test.

	      CACHE scope must name one cache entry.

	      VARIABLE scope is unique and does not accept a name.

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

       if     Conditionally execute a group of commands.

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

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

		if(<constant>)

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

		if(<variable>)

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

		if(NOT <expression>)

	      True if the expression is not true.

		if(<expr1> AND <expr2>)

	      True if both expressions would be considered true individually.

		if(<expr1> OR <expr2>)

	      True if either expression would be considered true individually.

		if(COMMAND command-name)

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

		if(POLICY policy-id)

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

		if(TARGET target-name)

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

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

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

		if(file1 IS_NEWER_THAN file2)

	      True  if	file1  is  newer than file2 or if one of the two files
	      doesn't exist. Behavior is well-defined only for full paths.

		if(IS_DIRECTORY directory-name)

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

		if(IS_SYMLINK file-name)

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

		if(IS_ABSOLUTE path)

	      True if the given path is an absolute path.

		if(<variable|string> MATCHES regex)

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

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

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

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

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

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

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

		if(DEFINED <variable>)

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

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

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

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

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

	      appears to the if command as

		if(var1)

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

		if(var2)

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

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

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

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

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

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

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

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

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

       include
	      Read CMake listfile code from the given file.

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

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

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

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

       list   List operations.

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

	      LENGTH will return a given list's length.

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

	      APPEND will append elements to the list.

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

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

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

	      REMOVE_DUPLICATES will remove duplicated items in the list.

	      REVERSE reverses the contents of the list in-place.

	      SORT sorts the list in-place alphabetically.

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

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

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

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

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

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

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

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

		make_directory(directory)

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

       mark_as_advanced
	      Mark cmake cached variables as advanced.

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

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

	      It does nothing in script mode.

       math   Mathematical expressions.

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

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

       message
	      Display a message to the user.

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

	      The optional keyword determines the type of message:

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

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

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

       option Provides an option that the user can optionally select.

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

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

	      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_pack‐
	      age()), it causes processing of the current  file	 to  stop  and
	      control  is returned to the including file. If it is encountered
	      in a file which is not included by another file, e.g.  a	CMake‐
	      Lists.txt,  control is returned to the parent directory if there
	      is one. If return is called in a function, control  is  returned
	      to  the caller of the function. Note that a macro is not a func‐
	      tion and does not handle return like a function does.

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

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

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

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

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

		separate_arguments(VARIABLE)

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

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

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

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

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

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

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

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

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

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

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

	      <variable> can be an environment variable such as:

		set( ENV{PATH} /home/martink )

	      in which case the environment variable will be set.

	      *** Variable types in CMake ***

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

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

	      Some examples:

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

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

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

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

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

       set_directory_properties
	      Set a property of the directory.

		set_directory_properties(PROPERTIES prop1 value1 prop2 value2)

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

       set_property
	      Set a named property in a given scope.

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

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

	      GLOBAL scope is unique and does not accept a name.

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

	      TARGET scope may name zero or more existing targets.

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

	      TEST scope may name zero or more existing tests.

	      CACHE scope must name zero or more cache existing entries.

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

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

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

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

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

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

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

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

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

	      CONFIGURE will transform a string like CONFIGURE_FILE transforms
	      a file.

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

	      LENGTH will return a given string's length.

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

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

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

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

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

		 ^	   Matches at beginning of a line
		 $	   Matches at end of a line
		 .	   Matches any single character
		 [ ]	   Matches any character(s) inside the brackets
		 [^ ]	   Matches any character(s) not inside the brackets
		  -	   Matches any character in range on either side of a dash
		 *	   Matches preceding pattern zero or more times
		 +	   Matches preceding pattern one or more times
		 ?	   Matches preceding pattern zero or once only
		 |	   Matches a pattern on either side of the |
		 ()	   Saves a matched subexpression, which can be referenced
			   in the REGEX REPLACE operation. Additionally it is saved
			   by all regular expression-related commands, including
			   e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).

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

		unset(<variable> [CACHE])

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

	      <variable> can be an environment variable such as:

		unset(ENV{LD_LIBRARY_PATH})

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

       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 command will receive the  fol‐
	      lowing  arguments:  COMMAND(<variable> <access> <value> <current
	      list file> <stack>)

       while  Evaluate a group of commands while a condition is true

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SEE ALSO
       cmake(1), ccmake(1)

       The following resources are available to get help using CMake:

       Home Page
	      http://www.cmake.org

	      The primary starting point for learning about CMake.

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

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

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

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

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

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

       Summary of helpful links:

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

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

ctest 2.8.9			August 15, 2012			      ctest(1)
[top]

List of man pages available for Cygwin

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

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

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