Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CMAKE-MODULES(7)		     CMake		      CMAKE-MODULES(7)

NAME
       cmake-modules - CMake Modules Reference

       The  modules  listed here are part of the CMake distribution.  Projects
       may provide further modules; their location(s) can be specified in  the
       CMAKE_MODULE_PATH variable.

UTILITY	MODULES
       These modules are loaded	using the include() command.

   AndroidTestUtilities
       New in version 3.7.

       Create  a  test that automatically loads	specified data onto an Android
       device.

   Introduction
       Use this	module to push data needed for testing an Android  device  be-
       havior  onto  a	connected Android device. The module will accept files
       and libraries as	well as	separate destinations for each.	It will	create
       a test that loads the files into	a device object	store and link to them
       from the	specified destination. The files are only uploaded if they are
       not already in the object store.

       For example:

	  include(AndroidTestUtilities)
	  android_add_test_data(
	    example_setup_test
	    FILES <files>...
	    LIBS <libs>...
	    DEVICE_TEST_DIR "/data/local/tests/example"
	    DEVICE_OBJECT_STORE	"/sdcard/.ExternalData/SHA"
	    )

       At  build  time a test named "example_setup_test" will be created.  Run
       this test on the	command	line with ctest(1) to load the data  onto  the
       Android device.

   Module Functions
       android_add_test_data

		 android_add_test_data(<test-name>
		   [FILES <files>...] [FILES_DEST <device-dir>]
		   [LIBS <libs>...]   [LIBS_DEST <device-dir>]
		   [DEVICE_OBJECT_STORE	<device-dir>]
		   [DEVICE_TEST_DIR <device-dir>]
		   [NO_LINK_REGEX <strings>...]
		   )

	      The android_add_test_data	function is used to copy files and li-
	      braries needed to	run project-specific tests. On the host	 oper-
	      ating system, this is done at build time.	For on-device testing,
	      the files	are loaded onto	the device by the manufactured test at
	      run time.

	      This function accepts the	following named	parameters:

	      FILES <files>...
		     zero or more files	needed for testing

	      LIBS <libs>...
		     zero or more libraries needed for testing

	      FILES_DEST <device-dir>
		     absolute path where the data files	are expected to	be

	      LIBS_DEST	<device-dir>
		     absolute path where the libraries are expected to be

	      DEVICE_OBJECT_STORE <device-dir>
		     absolute  path  to	 the location where the	data is	stored
		     on-device

	      DEVICE_TEST_DIR <device-dir>
		     absolute path to the root directory of the	on-device test
		     location

	      NO_LINK_REGEX <strings>...
		     list  of  regex  strings matching the names of files that
		     should be copied from the object store to the testing di-
		     rectory

   BundleUtilities
       Functions to help assemble a standalone bundle application.

       A  collection  of  CMake	utility	functions useful for dealing with .app
       bundles on the Mac and bundle-like directories on any OS.

       The following functions are provided by this module:

	  fixup_bundle
	  copy_and_fixup_bundle
	  verify_app
	  get_bundle_main_executable
	  get_dotapp_dir
	  get_bundle_and_executable
	  get_bundle_all_executables
	  get_item_key
	  get_item_rpaths
	  clear_bundle_keys
	  set_bundle_key_values
	  get_bundle_keys
	  copy_resolved_item_into_bundle
	  copy_resolved_framework_into_bundle
	  fixup_bundle_item
	  verify_bundle_prerequisites
	  verify_bundle_symlinks

       Requires	CMake 2.6 or greater because it	uses function, break and  PAR-
       ENT_SCOPE.  Also	depends	on GetPrerequisites.cmake.

       DO  NOT	USE  THESE  FUNCTIONS AT CONFIGURE TIME	(from CMakeLists.txt)!
       Instead,	invoke them from an install(CODE) or install(SCRIPT) rule.

	  fixup_bundle(<app> <libs> <dirs>)

       Fix up <app> bundle in-place and	make it	standalone, such that  it  can
       be  drag-n-drop	copied	to  another machine and	run on that machine as
       long as all of the system libraries are compatible.

       If you pass plugins to fixup_bundle as the libs parameter,  you	should
       install	them or	copy them into the bundle before calling fixup_bundle.
       The <libs> parameter is a list of libraries that	must be	fixed up,  but
       that cannot be determined by otool output analysis  (i.e. plugins).

       Gather  all the keys for	all the	executables and	libraries in a bundle,
       and then, for each key, copy each prerequisite into the	bundle.	  Then
       fix each	one up according to its	own list of prerequisites.

       Then  clear all the keys	and call verify_app on the final bundle	to en-
       sure that it is truly standalone.

       New in version 3.6: As an optional parameter (IGNORE_ITEM)  a  list  of
       file  names  can	 be  passed,  which are	then ignored (e.g. IGNORE_ITEM
       "vcredist_x86.exe;vcredist_x64.exe").

	  copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)

       Makes a copy of the bundle <src>	at location <dst> and  then  fixes  up
       the new copied bundle in-place at <dst>.

	  verify_app(<app>)

       Verifies	 that  an  application	<app>  appears	valid based on running
       analysis	tools on it.  Calls message(FATAL_ERROR) if the	application is
       not verified.

       New  in	version	 3.6: As an optional parameter (IGNORE_ITEM) a list of
       file names can be passed, which	are  then  ignored  (e.g.  IGNORE_ITEM
       "vcredist_x86.exe;vcredist_x64.exe")

	  get_bundle_main_executable(<bundle> <result_var>)

       The  result  will be the	full path name of the bundle's main executable
       file or an error: prefixed string if it could not be determined.

	  get_dotapp_dir(<exe> <dotapp_dir_var>)

       Returns the nearest parent dir whose name ends with .app	given the full
       path to an executable.  If there	is no such parent dir, then simply re-
       turn the	dir containing the executable.

       The returned directory may or may not exist.

	  get_bundle_and_executable(<app> <bundle_var> <executable_var>	<valid_var>)

       Takes either a .app directory name or the name of an executable	nested
       inside  a  .app directory and returns the path to the .app directory in
       <bundle_var> and	the path to its	main executable	in <executable_var>.

	  get_bundle_all_executables(<bundle> <exes_var>)

       Scans <bundle> bundle recursively for all <exes_var>  executable	 files
       and accumulates them into a variable.

	  get_item_key(<item> <key_var>)

       Given  <item>  file  name, generate <key_var> key that should be	unique
       considering the set of libraries	that need copying or fixing up to make
       a  bundle  standalone.  This is essentially the file name including ex-
       tension with . replaced by _

       This key	is used	as a prefix for	CMake variables	so that	we  can	 asso-
       ciate a set of variables	with a given item based	on its key.

	  clear_bundle_keys(<keys_var>)

       Loop over the <keys_var>	list of	keys, clearing all the variables asso-
       ciated with each	key.  After the	loop, clear the	list of	keys itself.

       Caller of get_bundle_keys should	call clear_bundle_keys when done  with
       list of keys.

	  set_bundle_key_values(<keys_var> <context> <item> <exepath> <dirs>
				<copyflag> [<rpaths>])

       Add  <keys_var>	key to the list	(if necessary) for the given item.  If
       added, also set all the variables associated with that key.

	  get_bundle_keys(<app>	<libs> <dirs> <keys_var>)

       Loop over all the executable and	library	files within <app> bundle (and
       given as	extra <libs>) and accumulate a list of keys representing them.
       Set values associated with each key such	that we	can loop over  all  of
       them and	copy prerequisite libs into the	bundle and then	do appropriate
       install_name_tool fixups.

       New in version 3.6: As an optional parameter (IGNORE_ITEM)  a  list  of
       file  names  can	 be  passed,  which are	then ignored (e.g. IGNORE_ITEM
       "vcredist_x86.exe;vcredist_x64.exe")

	  copy_resolved_item_into_bundle(<resolved_item> <resolved_embedded_item>)

       Copy a resolved item into the bundle if necessary.  Copy	is not	neces-
       sary,  if  the  <resolved_item>	is  "the same as" the <resolved_embed-
       ded_item>.

	  copy_resolved_framework_into_bundle(<resolved_item> <resolved_embedded_item>)

       Copy a resolved framework into the bundle if necessary.	 Copy  is  not
       necessary, if the <resolved_item> is "the same as" the <resolved_embed-
       ded_item>.

       By default, BU_COPY_FULL_FRAMEWORK_CONTENTS is not set.	 If  you  want
       full  frameworks	 embedded  in  your  bundles,  set BU_COPY_FULL_FRAME-
       WORK_CONTENTS to	ON before calling fixup_bundle.	 By default,  COPY_RE-
       SOLVED_FRAMEWORK_INTO_BUNDLE copies the framework dylib itself plus the
       framework Resources directory.

	  fixup_bundle_item(<resolved_embedded_item> <exepath> <dirs>)

       Get  the	 direct/non-system  prerequisites  of	the   <resolved_embed-
       ded_item>.   For	 each prerequisite, change the way it is referenced to
       the value of the	_EMBEDDED_ITEM keyed variable for  that	 prerequisite.
       (Most likely changing to	an @executable_path style reference.)

       This  function requires that the	<resolved_embedded_item> be inside the
       bundle already.	In other words,	if you pass plugins to fixup_bundle as
       the  libs parameter, you	should install them or copy them into the bun-
       dle before calling fixup_bundle.	 The libs parameter is a list  of  li-
       braries	that  must be fixed up,	but that cannot	be determined by otool
       output analysis.	 (i.e.,	plugins)

       Also, change the	id of the item being  fixed  up	 to  its  own  _EMBED-
       DED_ITEM	value.

       Accumulate  changes  in	a  local  variable  and	 make  one call	to in-
       stall_name_tool at the end of the function  with	 all  the  changes  at
       once.

       If  the BU_CHMOD_BUNDLE_ITEMS variable is set then bundle items will be
       marked writable before install_name_tool	tries to change	them.

	  verify_bundle_prerequisites(<bundle> <result_var> <info_var>)

       Verifies	that the sum of	all prerequisites of all files inside the bun-
       dle  are	 contained within the bundle or	are system libraries, presumed
       to exist	everywhere.

       New in version 3.6: As an optional parameter (IGNORE_ITEM)  a  list  of
       file  names  can	 be  passed,  which are	then ignored (e.g. IGNORE_ITEM
       "vcredist_x86.exe;vcredist_x64.exe")

	  verify_bundle_symlinks(<bundle> <result_var> <info_var>)

       Verifies	that any symlinks found	in the <bundle>	bundle point to	 other
       files  that  are	already	also in	the bundle...  Anything	that points to
       an external file	causes this function to	fail the verification.

   CheckCCompilerFlag
       Check whether the C compiler supports a given flag.

       check_c_compiler_flag

		 check_c_compiler_flag(<flag> <var>)

	      Check that the <flag> is accepted	by the compiler	without	a  di-
	      agnostic.	  Stores  the  result in an internal cache entry named
	      <var>.

       This command temporarily	sets the  CMAKE_REQUIRED_DEFINITIONS  variable
       and  calls  the check_c_source_compiles macro from the CheckCSourceCom-
       piles module.  See documentation	of that	module for a listing of	 vari-
       ables that can otherwise	modify the build.

       A  positive result from this check indicates only that the compiler did
       not issue a diagnostic message when given the flag.  Whether  the  flag
       has  any	effect or even a specific one is beyond	the scope of this mod-
       ule.

       NOTE:
	  Since	the try_compile() command forwards flags from  variables  like
	  CMAKE_C_FLAGS,  unknown  flags  in  such variables may cause a false
	  negative for this check.

   CheckCompilerFlag
       New in version 3.19.

       Check whether the compiler supports a given flag.

       check_compiler_flag

		 check_compiler_flag(<lang> <flag> <var>)

       Check that the <flag> is	accepted by the	compiler without a diagnostic.
       Stores the result in an internal	cache entry named <var>.

       This  command  temporarily sets the CMAKE_REQUIRED_DEFINITIONS variable
       and calls the check_source_compiles(<LANG>) function  from  the	Check-
       SourceCompiles  module.	See documentation of that module for a listing
       of variables that can otherwise modify the build.

       A positive result from this check indicates only	that the compiler  did
       not  issue  a diagnostic	message	when given the flag.  Whether the flag
       has any effect or even a	specific one is	beyond the scope of this  mod-
       ule.

       NOTE:
	  Since	 the  try_compile() command forwards flags from	variables like
	  CMAKE_<LANG>_FLAGS, unknown flags in	such  variables	 may  cause  a
	  false	negative for this check.

   CheckCSourceCompiles
       Check if	given C	source compiles	and links into an executable.

       check_c_source_compiles

		 check_c_source_compiles(<code>	<resultVar>
					 [FAIL_REGEX <regex1> [<regex2>...]])

	      Check  that the source supplied in <code>	can be compiled	as a C
	      source file and linked as	an executable (so it must  contain  at
	      least  a	main() function). The result will be stored in the in-
	      ternal cache variable specified by <resultVar>, with  a  boolean
	      true  value  for	success	 and  boolean  false  for  failure. If
	      FAIL_REGEX is provided, then failure is determined  by  checking
	      if  anything  in the output matches any of the specified regular
	      expressions.

	      The underlying check is performed	by the try_compile()  command.
	      The  compile  and	link commands can be influenced	by setting any
	      of the following variables prior to calling  check_c_source_com-
	      piles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_C_FLAGS and its	associated  configura-
		     tion-specific  variable  are  automatically  added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_compile(),  i.e. the contents of the INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     New in version 3.14.

		     A ;-list of options to  add  to  the  link	 command  (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     New in version 3.1.

		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckCSourceRuns
       Check if	given C	source compiles	and links into an executable  and  can
       subsequently be run.

       check_c_source_runs

		 check_c_source_runs(<code> <resultVar>)

	      Check  that the source supplied in <code>	can be compiled	as a C
	      source file, linked as an	executable and then  run.  The	<code>
	      must  contain at least a main() function.	If the <code> could be
	      built and	run successfully, the internal cache  variable	speci-
	      fied  by	<resultVar> will be set	to 1, otherwise	it will	be set
	      to an value that evaluates  to  boolean  false  (e.g.  an	 empty
	      string or	an error message).

	      The  underlying check is performed by the	try_run() command. The
	      compile and link commands	can be influenced by  setting  any  of
	      the following variables prior to calling check_c_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_C_FLAGS and its	associated  configura-
		     tion-specific  variable  are  automatically  added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_run(),	 i.e.  the contents of the INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     New in version 3.14.

		     A ;-list of options to  add  to  the  link	 command  (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     New in version 3.1.

		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckCXXCompilerFlag
       Check whether the CXX compiler supports a given flag.

       check_cxx_compiler_flag

		 check_cxx_compiler_flag(<flag>	<var>)

	      Check that the <flag> is accepted	by the compiler	without	a  di-
	      agnostic.	  Stores  the  result in an internal cache entry named
	      <var>.

       This command temporarily	sets the  CMAKE_REQUIRED_DEFINITIONS  variable
       and  calls the check_cxx_source_compiles	macro from the CheckCXXSource-
       Compiles	module.	 See documentation of that module  for	a  listing  of
       variables that can otherwise modify the build.

       A  positive result from this check indicates only that the compiler did
       not issue a diagnostic message when given the flag.  Whether  the  flag
       has  any	effect or even a specific one is beyond	the scope of this mod-
       ule.

       NOTE:
	  Since	the try_compile() command forwards flags from  variables  like
	  CMAKE_CXX_FLAGS,  unknown  flags in such variables may cause a false
	  negative for this check.

   CheckCXXSourceCompiles
       Check if	given C++ source compiles and links into an executable.

       check_cxx_source_compiles

		 check_cxx_source_compiles(<code> <resultVar>
					   [FAIL_REGEX <regex1>	[<regex2>...]])

	      Check that the source supplied in	<code> can be  compiled	 as  a
	      C++  source file and linked as an	executable (so it must contain
	      at least a main()	function). The result will be  stored  in  the
	      internal cache variable specified	by <resultVar>,	with a boolean
	      true value  for  success	and  boolean  false  for  failure.  If
	      FAIL_REGEX  is  provided,	then failure is	determined by checking
	      if anything in the output	matches	any of the  specified  regular
	      expressions.

	      The  underlying check is performed by the	try_compile() command.
	      The compile and link commands can	be influenced by  setting  any
	      of     the     following	   variables	prior	 to    calling
	      check_cxx_source_compiles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents of CMAKE_CXX_FLAGS and its associated configura-
		     tion-specific variable are	 automatically	added  to  the
		     compiler	command	  before  the  contents	 of  CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_compile(), i.e. the contents of the  INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     New in version 3.14.

		     A	;-list	of  options  to	 add  to the link command (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     New in version 3.1.

		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckCXXSourceRuns
       Check if	given C++ source compiles and links into an executable and can
       subsequently be run.

       check_cxx_source_runs

		 check_cxx_source_runs(<code> <resultVar>)

	      Check that the source supplied in	<code> can be  compiled	 as  a
	      C++  source  file,  linked  as  an  executable and then run. The
	      <code> must contain at least a main() function.  If  the	<code>
	      could be built and run successfully, the internal	cache variable
	      specified	by <resultVar> will be set to 1, otherwise it will  be
	      set  to  an value	that evaluates to boolean false	(e.g. an empty
	      string or	an error message).

	      The underlying check is performed	by the try_run() command.  The
	      compile  and  link  commands can be influenced by	setting	any of
	      the     following	     variables	    prior      to      calling
	      check_cxx_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_CXX_FLAGS and its associated configura-
		     tion-specific  variable  are  automatically  added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_run(),	 i.e.  the contents of the INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     New in version 3.14.

		     A ;-list of options to  add  to  the  link	 command  (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     New in version 3.1.

		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckCXXSymbolExists
       Check if	a symbol exists	as a function, variable, or macro in C++.

       check_cxx_symbol_exists

		 check_cxx_symbol_exists(<symbol> <files> <variable>)

	      Check that the  <symbol>	is  available  after  including	 given
	      header  <files>  and  store the result in	a <variable>.  Specify
	      the list of files	in one argument	as a semicolon-separated list.
	      check_cxx_symbol_exists()	 can  be  used to check	for symbols as
	      seen by the C++ compiler,	as opposed  to	check_symbol_exists(),
	      which always uses	the C compiler.

	      If  the  header files define the symbol as a macro it is consid-
	      ered available and assumed to work.  If the header files declare
	      the  symbol  as a	function or variable then the symbol must also
	      be available for linking.	 If the	symbol is a type, enum	value,
	      or  C++  template	 it will not be	recognized: consider using the
	      CheckTypeSize or CheckCXXSourceCompiles module instead.

       NOTE:
	  This command is unreliable when <symbol> is (potentially)  an	 over-
	  loaded function. Since there is no reliable way to predict whether a
	  given	function in the	system environment may be defined as an	 over-
	  loaded function or may be an overloaded function on other systems or
	  will become so in the	future,	it is generally	 advised  to  use  the
	  CheckCXXSourceCompiles  module for checking any function symbol (un-
	  less somehow you surely know the checked function is not  overloaded
	  on other systems or will not be so in	the future).

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	 ;-list	 of  libraries	to add to the link command. See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       For example:

	  include(CheckCXXSymbolExists)

	  # Check for macro SEEK_SET
	  check_cxx_symbol_exists(SEEK_SET "cstdio" HAVE_SEEK_SET)
	  # Check for function std::fopen
	  check_cxx_symbol_exists(std::fopen "cstdio" HAVE_STD_FOPEN)

   CheckFortranCompilerFlag
       New in version 3.3.

       Check whether the Fortran compiler supports a given flag.

       check_fortran_compiler_flag

		 check_fortran_compiler_flag(<flag> <var>)

	      Check that the <flag> is accepted	by the compiler	without	a  di-
	      agnostic.	  Stores  the  result in an internal cache entry named
	      <var>.

       This command temporarily	sets the  CMAKE_REQUIRED_DEFINITIONS  variable
       and  calls  the	check_fortran_source_compiles macro from the CheckFor-
       tranSourceCompiles module.  See documentation  of  that	module	for  a
       listing of variables that can otherwise modify the build.

       A  positive result from this check indicates only that the compiler did
       not issue a diagnostic message when given the flag.  Whether  the  flag
       has  any	effect or even a specific one is beyond	the scope of this mod-
       ule.

       NOTE:
	  Since	the try_compile() command forwards flags from  variables  like
	  CMAKE_Fortran_FLAGS,	unknown	 flags	in  such variables may cause a
	  false	negative for this check.

   CheckFortranFunctionExists
       Check if	a Fortran function exists.

       CHECK_FORTRAN_FUNCTION_EXISTS

		 CHECK_FORTRAN_FUNCTION_EXISTS(<function> <result>)

	      where

	      <function>
		     the name of the Fortran function

	      <result>
		     variable to store the result; will	be created as  an  in-
		     ternal cache variable.

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: A ;-list of options to add to the link com-
	      mand (see	try_compile() for further details).

       CMAKE_REQUIRED_LIBRARIES
	      A	 ;-list	 of libraries to add to	the link command. These	can be
	      the name of system libraries or they  can	 be  Imported  Targets
	      (see try_compile() for further details).

   CheckFortranSourceCompiles
       New in version 3.1.

       Check if	given Fortran source compiles and links	into an	executable.

       check_fortran_source_compiles

		 check_fortran_source_compiles(<code> <resultVar>
		     [FAIL_REGEX <regex>...]
		     [SRC_EXT <extension>]
		 )

	      Checks  that  the	source supplied	in <code> can be compiled as a
	      Fortran source file and linked as	an executable. The <code> must
	      be  a  Fortran program containing	at least an end	statement--for
	      example:

		 check_fortran_source_compiles("character :: b;	error stop b; end" F2018ESTOPOK	SRC_EXT	F90)

	      This command can help avoid costly build processes when  a  com-
	      piler  lacks  support  for  a necessary feature, or a particular
	      vendor library is	not compatible with the	Fortran	compiler  ver-
	      sion being used. This generate-time check	may advise the user of
	      such before the main build  process.  See	 also  the  check_for-
	      tran_source_runs() command to actually run the compiled code.

	      The  result  will	 be stored in the internal cache variable <re-
	      sultVar>,	with a boolean true  value  for	 success  and  boolean
	      false for	failure.

	      If  FAIL_REGEX is	provided, then failure is determined by	check-
	      ing if anything in the output matches any	of the specified regu-
	      lar expressions.

	      By  default, the test source file	will be	given a	.F file	exten-
	      sion. The	SRC_EXT	option can be used to override this with .<ex-
	      tension> instead-- .F90 is a typical choice.

	      The  underlying check is performed by the	try_compile() command.
	      The compile and link commands can	be influenced by  setting  any
	      of   the	 following   variables	prior  to  calling  check_for-
	      tran_source_compiles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents  of  CMAKE_Fortran_FLAGS and its associated con-
		     figuration-specific variable are automatically  added  to
		     the  compiler  command  before  the contents of CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_compile(), i.e. the contents of the  INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     New in version 3.14.

		     A	;-list	of  options  to	 add  to the link command (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckFortranSourceRuns
       New in version 3.14.

       Check if	given Fortran source compiles and links	into an	executable and
       can subsequently	be run.

       check_fortran_source_runs

		 check_fortran_source_runs(<code> <resultVar>
		     [SRC_EXT <extension>])

	      Check that the source supplied in	<code> can be  compiled	 as  a
	      Fortran  source  file, linked as an executable and then run. The
	      <code> must be a Fortran program	containing  at	least  an  end
	      statement--for example:

		 check_fortran_source_runs("real :: x[*]; call co_sum(x); end" F2018coarrayOK)

	      This  command  can help avoid costly build processes when	a com-
	      piler lacks support for a	necessary  feature,  or	 a  particular
	      vendor  library is not compatible	with the Fortran compiler ver-
	      sion being used. Some of these failures only  occur  at  runtime
	      instead of linktime, and a trivial runtime example can catch the
	      issue before the main build process.

	      If the <code> could be built and run successfully, the  internal
	      cache variable specified by <resultVar> will be set to 1,	other-
	      wise it will be set to an	value that evaluates to	boolean	 false
	      (e.g. an empty string or an error	message).

	      By  default,  the	test source file will be given a .F90 file ex-
	      tension. The SRC_EXT option can be used to  override  this  with
	      .<extension> instead.

	      The  underlying check is performed by the	try_run() command. The
	      compile and link commands	can be influenced by  setting  any  of
	      the    following	 variables   prior   to	  calling   check_for-
	      tran_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents  of  CMAKE_Fortran_FLAGS and its associated con-
		     figuration-specific variable are automatically  added  to
		     the  compiler  command  before  the contents of CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_run(),	i.e. the contents of  the  INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A	;-list	of  options  to	 add  to the link command (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckFunctionExists
       Check if	a C function can be linked

       check_function_exists

		 check_function_exists(<function> <variable>)

	      Checks  that the <function> is provided by libraries on the sys-
	      tem and store the	result in a <variable>,	which will be  created
	      as an internal cache variable.

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	 ;-list	 of  libraries	to add to the link command. See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       NOTE:
	  Prefer using CheckSymbolExists instead of this module, for the  fol-
	  lowing reasons:

	  o check_function_exists() can't detect functions that	are inlined in
	    headers or specified as a macro.

	  o check_function_exists() can't detect anything in the  32-bit  ver-
	    sions  of  the Win32 API, because of a mismatch in calling conven-
	    tions.

	  o check_function_exists() only verifies linking, it does not	verify
	    that the function is declared in system headers.

   CheckIncludeFileCXX
       Provides	a macro	to check if a header file can be included in CXX.

       CHECK_INCLUDE_FILE_CXX

		 CHECK_INCLUDE_FILE_CXX(<include> <variable> [<flags>])

	      Check  if	 the  given  <include>	file  may be included in a CXX
	      source file and store the	result	in  an	internal  cache	 entry
	      named  <variable>.   The	optional third argument	may be used to
	      add compilation flags to the check (or use  CMAKE_REQUIRED_FLAGS
	      below).

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	 ;-list	 of  libraries	to add to the link command. See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       See modules CheckIncludeFile and	CheckIncludeFiles to check for one  or
       more C headers.

   CheckIncludeFile
       Provides	a macro	to check if a header file can be included in C.

       CHECK_INCLUDE_FILE

		 CHECK_INCLUDE_FILE(<include> <variable> [<flags>])

	      Check  if	the given <include> file may be	included in a C	source
	      file and store the result	 in  an	 internal  cache  entry	 named
	      <variable>.  The optional	third argument may be used to add com-
	      pilation flags to	the check (or use CMAKE_REQUIRED_FLAGS below).

       The following variables may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	;-list of libraries to add to the  link	 command.  See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       See the CheckIncludeFiles module	to check for multiple headers at once.
       See the CheckIncludeFileCXX module to check for headers using  the  CXX
       language.

   CheckIncludeFiles
       Provides	 a macro to check if a list of one or more header files	can be
       included	together.

       CHECK_INCLUDE_FILES

		 CHECK_INCLUDE_FILES("<includes>" <variable> [LANGUAGE <language>])

	      Check if the given <includes> list may be	included together in a
	      source  file  and	 store	the  result in an internal cache entry
	      named <variable>.	 Specify the <includes>	argument as  a	;-list
	      of header	file names.

	      If  LANGUAGE is set, the specified compiler will be used to per-
	      form the check. Acceptable values	are C and CXX. If not set, the
	      C	compiler will be used if enabled. If the C compiler is not en-
	      abled, the C++ compiler will be used if enabled.

       The following variables may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	;-list of libraries to add to the  link	 command.  See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       See  modules  CheckIncludeFile  and  CheckIncludeFileCXX	to check for a
       single header file in C or CXX languages.

   CheckIPOSupported
       New in version 3.9.

       Check whether the compiler  supports  an	 interprocedural  optimization
       (IPO/LTO).   Use	 this before enabling the INTERPROCEDURAL_OPTIMIZATION
       target property.

       check_ipo_supported

		 check_ipo_supported([RESULT <result>] [OUTPUT <output>]
				     [LANGUAGES	<lang>...])

	      Options are:

	      RESULT <result>
		     Set <result> variable to YES if IPO is supported  by  the
		     compiler  and  NO otherwise.  If this option is not given
		     then the command will issue a fatal error if IPO  is  not
		     supported.

	      OUTPUT <output>
		     Set <output> variable with	details	about any error.

	      LANGUAGES	<lang>...
		     Specify languages whose compilers to check.  Languages C,
		     CXX, and Fortran are supported.

       It makes	no sense to use	this module when CMP0069 is set	to OLD so mod-
       ule will	return error in	this case. See policy CMP0069 for details.

       New in version 3.13: Add	support	for Visual Studio generators.

   Examples
	  check_ipo_supported()	# fatal	error if IPO is	not supported
	  set_property(TARGET foo PROPERTY INTERPROCEDURAL_OPTIMIZATION	TRUE)

	  # Optional IPO. Do not use IPO if it's not supported by compiler.
	  check_ipo_supported(RESULT result OUTPUT output)
	  if(result)
	    set_property(TARGET	foo PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)
	  else()
	    message(WARNING "IPO is not	supported: ${output}")
	  endif()

   CheckLanguage
       Check if	a language can be enabled

       Usage:

	  check_language(<lang>)

       where <lang> is a language that may be passed to	enable_language() such
       as Fortran.  If CMAKE_<LANG>_COMPILER is	already	defined	the check does
       nothing.	  Otherwise  it	tries enabling the language in a test project.
       The result is cached in CMAKE_<LANG>_COMPILER as	the compiler that  was
       found,  or  NOTFOUND  if	the language cannot be enabled.	For CUDA which
       can have	an explicit host compiler, the cache  CMAKE_CUDA_HOST_COMPILER
       variable	will be	set if it was required for compilation (and cleared if
       it was not).

       Example:

	  check_language(Fortran)
	  if(CMAKE_Fortran_COMPILER)
	    enable_language(Fortran)
	  else()
	    message(STATUS "No Fortran support")
	  endif()

   CheckLibraryExists
       Check if	the function exists.

       CHECK_LIBRARY_EXISTS

		 CHECK_LIBRARY_EXISTS(LIBRARY FUNCTION LOCATION	VARIABLE)

		 LIBRARY  - the	name of	the library you	are looking for
		 FUNCTION - the	name of	the function
		 LOCATION - location where the library should be found
		 VARIABLE - variable to	store the result
			    Will be created as an internal cache variable.

       The following variables may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      list of macros to	define (-DFOO=bar).

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: list	of options to pass to link command.

       CMAKE_REQUIRED_LIBRARIES
	      list of libraries	to link.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

   CheckLinkerFlag
       New in version 3.18.

       Check whether the compiler supports a given link	flag.

       check_linker_flag

		 check_linker_flag(<lang> <flag> <var>)

       Check that the link <flag> is accepted by the <lang> compiler without a
       diagnostic.  Stores the result in an internal cache entry named <var>.

       This command temporarily	sets the CMAKE_REQUIRED_LINK_OPTIONS  variable
       and  calls the check_source_compiles() command from the CheckSourceCom-
       piles module.  See that module's	documentation for a listing  of	 vari-
       ables that can otherwise	modify the build.

       The  underlying	implementation	relies on the LINK_OPTIONS property to
       check the specified flag. The LINKER: prefix, as	described in the  tar-
       get_link_options() command, can be used as well.

       A  positive result from this check indicates only that the compiler did
       not issue a diagnostic message when given the link flag.	  Whether  the
       flag  has any effect or even a specific one is beyond the scope of this
       module.

       NOTE:
	  Since	the try_compile() command forwards flags from  variables  like
	  CMAKE_<LANG>_FLAGS,  unknown	flags  in  such	 variables may cause a
	  false	negative for this check.

   CheckOBJCCompilerFlag
       New in version 3.16.

       Check whether the Objective-C compiler supports a given flag.

       check_objc_compiler_flag

		 check_objc_compiler_flag(<flag> <var>)

	      Check that the <flag> is accepted	by the compiler	without	a  di-
	      agnostic.	  Stores  the  result in an internal cache entry named
	      <var>.

       This command temporarily	sets the  CMAKE_REQUIRED_DEFINITIONS  variable
       and  calls  the	check_objc_source_compiles  macro  from	the CheckOBJC-
       SourceCompiles module.  See documentation of that module	for a  listing
       of variables that can otherwise modify the build.

       A  positive result from this check indicates only that the compiler did
       not issue a diagnostic message when given the flag.  Whether  the  flag
       has  any	effect or even a specific one is beyond	the scope of this mod-
       ule.

       NOTE:
	  Since	the try_compile() command forwards flags from  variables  like
	  CMAKE_OBJC_FLAGS,  unknown flags in such variables may cause a false
	  negative for this check.

   CheckOBJCSourceCompiles
       New in version 3.16.

       Check if	given Objective-C source  compiles  and	 links	into  an  exe-
       cutable.

       check_objc_source_compiles

		 check_objc_source_compiles(<code> <resultVar>
					    [FAIL_REGEX	<regex1> [<regex2>...]])

	      Check  that  the	source supplied	in <code> can be compiled as a
	      Objectie-C source	file and linked	as an executable (so  it  must
	      contain  at  least a main() function). The result	will be	stored
	      in the internal cache variable specified by <resultVar>, with  a
	      boolean true value for success and boolean false for failure. If
	      FAIL_REGEX is provided, then failure is determined  by  checking
	      if  anything  in the output matches any of the specified regular
	      expressions.

	      The underlying check is performed	by the try_compile()  command.
	      The  compile  and	link commands can be influenced	by setting any
	      of    the	   following	variables     prior	to     calling
	      check_objc_source_compiles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_OBJC_FLAGS and its associated  configu-
		     ration-specific  variable	are automatically added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_compile(),  i.e. the contents of the INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A ;-list of options to  add  to  the  link	 command  (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckOBJCSourceRuns
       New in version 3.16.

       Check if	given Objective-C source compiles and links into an executable
       and can subsequently be run.

       check_objc_source_runs

		 check_objc_source_runs(<code> <resultVar>)

	      Check  that  the	source supplied	in <code> can be compiled as a
	      Objective-C source file, linked as an executable and  then  run.
	      The  <code>  must	 contain  at  least  a main() function.	If the
	      <code> could be built and	run successfully, the  internal	 cache
	      variable specified by <resultVar>	will be	set to 1, otherwise it
	      will be set to an	value that evaluates to	boolean	false (e.g. an
	      empty string or an error message).

	      The  underlying check is performed by the	try_run() command. The
	      compile and link commands	can be influenced by  setting  any  of
	      the      following      variables	     prior	to     calling
	      check_objc_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents  of CMAKE_OBJC_FLAGS and its associated configu-
		     ration-specific variable are automatically	added  to  the
		     compiler	command	  before  the  contents	 of  CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_run(),	i.e. the contents of  the  INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A	;-list	of  options  to	 add  to the link command (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckOBJCXXCompilerFlag
       New in version 3.16.

       Check whether the Objective-C++ compiler	supports a given flag.

       check_objcxx_compiler_flag

		 check_objcxx_compiler_flag(<flag> <var>)

	      Check  that the <flag> is	accepted by the	compiler without a di-
	      agnostic.	 Stores	the result in an internal  cache  entry	 named
	      <var>.

       This  command  temporarily sets the CMAKE_REQUIRED_DEFINITIONS variable
       and calls the  check_objcxx_source_compiles  macro  from	 the  CheckOB-
       JCXXSourceCompiles  module.   See  documentation	 of  that module for a
       listing of variables that can otherwise modify the build.

       A positive result from this check indicates only	that the compiler  did
       not  issue  a diagnostic	message	when given the flag.  Whether the flag
       has any effect or even a	specific one is	beyond the scope of this  mod-
       ule.

       NOTE:
	  Since	 the  try_compile() command forwards flags from	variables like
	  CMAKE_OBJCXX_FLAGS, unknown flags in	such  variables	 may  cause  a
	  false	negative for this check.

   CheckOBJCXXSourceCompiles
       New in version 3.16.

       Check  if  given	 Objective-C++	source compiles	and links into an exe-
       cutable.

       check_objcxx_source_compiles

		 check_objcxx_source_compiles(<code> <resultVar>
					      [FAIL_REGEX <regex1> [<regex2>...]])

	      Check that the source supplied in	<code> can be  compiled	 as  a
	      Objective-C++  source  file  and	linked as an executable	(so it
	      must contain at least a main() function).	 The  result  will  be
	      stored  in the internal cache variable specified by <resultVar>,
	      with a boolean true value	for  success  and  boolean  false  for
	      failure.	If  FAIL_REGEX is provided, then failure is determined
	      by checking if anything in the output matches any	of the	speci-
	      fied regular expressions.

	      The  underlying check is performed by the	try_compile() command.
	      The compile and link commands can	be influenced by  setting  any
	      of   the	 following   variables	 prior	to  calling  check_ob-
	      jcxx_source_compiles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents of CMAKE_OBJCXX_FLAGS and	its associated config-
		     uration-specific variable are automatically added to  the
		     compiler	command	  before  the  contents	 of  CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_compile(), i.e. the contents of the  INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A	;-list	of  options  to	 add  to the link command (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckOBJCXXSourceRuns
       New in version 3.16.

       Check  if  given	 Objective-C++	source compiles	and links into an exe-
       cutable and can subsequently be run.

       check_objcxx_source_runs

		 check_objcxx_source_runs(<code> <resultVar>)

	      Check that the source supplied in	<code> can be  compiled	 as  a
	      Objective-C++ source file, linked	as an executable and then run.
	      The <code> must contain at  least	 a  main()  function.  If  the
	      <code>  could  be	built and run successfully, the	internal cache
	      variable specified by <resultVar>	will be	set to 1, otherwise it
	      will be set to an	value that evaluates to	boolean	false (e.g. an
	      empty string or an error message).

	      The underlying check is performed	by the try_run() command.  The
	      compile  and  link  commands can be influenced by	setting	any of
	      the   following	variables   prior   to	  calling    check_ob-
	      jcxx_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_OBJCXX_FLAGS and	its associated config-
		     uration-specific  variable	are automatically added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_run(),	 i.e.  the contents of the INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A ;-list of options to  add  to  the  link	 command  (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckPIESupported
       New in version 3.14.

       Check whether the linker	supports Position Independent Code (PIE) or No
       Position	Independent Code (NO_PIE) for executables.  Use	this to	ensure
       that the	POSITION_INDEPENDENT_CODE target property for executables will
       be honored at link time.

       check_pie_supported

		 check_pie_supported([OUTPUT_VARIABLE <output>]
				     [LANGUAGES	<lang>...])

	      Options are:

	      OUTPUT_VARIABLE <output>
		     Set <output> variable with	details	about any error.

	      LANGUAGES	<lang>...
		     Check  the	 linkers  used	for each of the	specified lan-
		     guages.  Supported	languages are C, CXX, and Fortran.

       It makes	no sense to use	this module when CMP0083 is set	to OLD,	so the
       command	will return an error in	this case.  See	policy CMP0083 for de-
       tails.

   Variables
       For each	language checked, two boolean cache variables are defined.

	  CMAKE_<lang>_LINK_PIE_SUPPORTED
		 Set to	YES if PIE is supported	by the linker  and  NO	other-
		 wise.

	  CMAKE_<lang>_LINK_NO_PIE_SUPPORTED
		 Set to	YES if NO_PIE is supported by the linker and NO	other-
		 wise.

   Examples
	  check_pie_supported()
	  set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)

	  # Retrieve any error message.
	  check_pie_supported(OUTPUT_VARIABLE output LANGUAGES C)
	  set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)
	  if(NOT CMAKE_C_LINK_PIE_SUPPORTED)
	    message(WARNING "PIE is not	supported at link time:	${output}.\n"
			    "PIE link options will not be passed to linker.")
	  endif()

   CheckPrototypeDefinition
       Check if	the prototype we expect	is correct.

       check_prototype_definition

		 check_prototype_definition(FUNCTION PROTOTYPE RETURN HEADER VARIABLE)

		 FUNCTION - The	name of	the function (used to check if prototype exists)
		 PROTOTYPE- The	prototype to check.
		 RETURN	- The return value of the function.
		 HEADER	- The header files required.
		 VARIABLE - The	variable to store the result.
			    Will be created as an internal cache variable.

	      Example:

		 check_prototype_definition(getpwent_r
		  "struct passwd *getpwent_r(struct passwd *src, char *buf, int	buflen)"
		  "NULL"
		  "unistd.h;pwd.h"
		  SOLARIS_GETPWENT_R)

       The following variables may be set before calling this function to mod-
       ify the way the check is	run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      list of macros to	define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      list of include directories.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: list	of options to pass to link command.

       CMAKE_REQUIRED_LIBRARIES
	      list of libraries	to link.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

   CheckSourceCompiles
       New in version 3.19.

       Check if	given source compiles and links	into an	executable.

       check_source_compiles

		 check_source_compiles(<lang> <code> <resultVar>
				       [FAIL_REGEX <regex1> [<regex2>...]]
				       [SRC_EXT	<extension>])

	      Check  that  the	source supplied	in <code> can be compiled as a
	      source file for the requested language and  linked  as  an  exe-
	      cutable (so it must contain at least a main() function). The re-
	      sult will	be stored in the internal cache	variable specified  by
	      <resultVar>,  with  a boolean true value for success and boolean
	      false for	failure. If FAIL_REGEX is provided,  then  failure  is
	      determined  by checking if anything in the output	matches	any of
	      the specified regular expressions.

	      By default, the test source file will be given a file  extension
	      that  matches  the requested language. The SRC_EXT option	can be
	      used to override this with .<extension> instead.

	      The underlying check is performed	by the try_compile()  command.
	      The  compile  and	link commands can be influenced	by setting any
	      of the following variables prior	to  calling  check_source_com-
	      piles():

	      CMAKE_REQUIRED_FLAGS
		     Additional	 flags	to pass	to the compiler. Note that the
		     contents of CMAKE_<LANG>_FLAGS and	its associated config-
		     uration-specific  variable	are automatically added	to the
		     compiler  command	before	the  contents	of   CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A	;-list	of  compiler  definitions of the form -DFOO or
		     -DFOO=bar.	A definition for the name  specified  by  <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A	;-list of header search	paths to pass to the compiler.
		     These will	be  the	 only  header  search  paths  used  by
		     try_compile(),  i.e. the contents of the INCLUDE_DIRECTO-
		     RIES directory property will be ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A ;-list of options to  add  to  the  link	 command  (see
		     try_compile() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A	;-list	of libraries to	add to the link	command. These
		     can be the	name of	system libraries or they  can  be  Im-
		     ported Targets (see try_compile() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	 this  variable	evaluates to a boolean true value, all
		     status messages associated	with the check	will  be  sup-
		     pressed.

	      The  check is only performed once, with the result cached	in the
	      variable named by	<resultVar>. Every subsequent CMake  run  will
	      re-use this cached value rather than performing the check	again,
	      even if the <code> changes.  In order to force the check	to  be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckSourceRuns
       New in version 3.19.

       Check if	given source compiles and links	into  an  executable  and  can
       subsequently be run.

       check_source_runs

		 check_source_runs(<lang> <code> <resultVar>
				   [SRC_EXT <extension>])

	      Check  that  the	source supplied	in <code> can be compiled as a
	      source file for the requested language, linked as	an  executable
	      and  then	 run.  The <code> must contain at least	a main() func-
	      tion. If the <code> could	be built and run successfully, the in-
	      ternal cache variable specified by <resultVar> will be set to 1,
	      otherwise	it will	be set to an value that	evaluates  to  boolean
	      false (e.g. an empty string or an	error message).

	      By  default, the test source file	will be	given a	file extension
	      that matches the requested language. The SRC_EXT option  can  be
	      used to override this with .<extension> instead.

	      The  underlying check is performed by the	try_run() command. The
	      compile and link commands	can be influenced by  setting  any  of
	      the      following      variables	     prior	to     calling
	      check_objc_source_runs():

	      CMAKE_REQUIRED_FLAGS
		     Additional	flags to pass to the compiler. Note  that  the
		     contents  of CMAKE_OBJC_FLAGS and its associated configu-
		     ration-specific variable are automatically	added  to  the
		     compiler	command	  before  the  contents	 of  CMAKE_RE-
		     QUIRED_FLAGS.

	      CMAKE_REQUIRED_DEFINITIONS
		     A ;-list of compiler definitions of  the  form  -DFOO  or
		     -DFOO=bar.	 A  definition	for the	name specified by <re-
		     sultVar> will also	be added automatically.

	      CMAKE_REQUIRED_INCLUDES
		     A ;-list of header	search paths to	pass to	the  compiler.
		     These  will  be  the  only	 header	 search	 paths used by
		     try_run(),	i.e. the contents of  the  INCLUDE_DIRECTORIES
		     directory property	will be	ignored.

	      CMAKE_REQUIRED_LINK_OPTIONS
		     A	;-list	of  options  to	 add  to the link command (see
		     try_run() for further details).

	      CMAKE_REQUIRED_LIBRARIES
		     A ;-list of libraries to add to the link  command.	 These
		     can  be  the  name	of system libraries or they can	be Im-
		     ported Targets (see try_run() for further details).

	      CMAKE_REQUIRED_QUIET
		     If	this variable evaluates	to a boolean true  value,  all
		     status  messages  associated  with	the check will be sup-
		     pressed.

	      The check	is only	performed once,	with the result	cached in  the
	      variable	named  by <resultVar>. Every subsequent	CMake run will
	      re-use this cached value rather than performing the check	again,
	      even  if	the <code> changes.  In	order to force the check to be
	      re-evaluated, the	variable named by <resultVar> must be manually
	      removed from the cache.

   CheckStructHasMember
       Check if	the given struct or class has the specified member variable

       CHECK_STRUCT_HAS_MEMBER

		 CHECK_STRUCT_HAS_MEMBER(<struct> <member> <header> <variable>
					 [LANGUAGE <language>])

		 <struct> - the	name of	the struct or class you	are interested in
		 <member> - the	member which existence you want	to check
		 <header> - the	header(s) where	the prototype should be	declared
		 <variable> - variable to store	the result
		 <language> - the compiler to use (C or	CXX)

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      list of macros to	define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      list of include directories.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: list	of options to pass to link command.

       CMAKE_REQUIRED_LIBRARIES
	      list of libraries	to link.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       Example:

	  CHECK_STRUCT_HAS_MEMBER("struct timeval" tv_sec sys/select.h
				  HAVE_TIMEVAL_TV_SEC LANGUAGE C)

   CheckSymbolExists
       Provides	a macro	to check if a symbol exists as a  function,  variable,
       or macro	in C.

       check_symbol_exists

		 check_symbol_exists(<symbol> <files> <variable>)

	      Check  that  the	<symbol>  is  available	 after including given
	      header <files> and store the result in  a	 <variable>.   Specify
	      the list of files	in one argument	as a semicolon-separated list.
	      <variable> will be created as an internal	cache variable.

       If the header files define the symbol  as  a  macro  it	is  considered
       available  and assumed to work.	If the header files declare the	symbol
       as a function or	variable then the symbol must also  be	available  for
       linking	(so intrinsics may not be detected).  If the symbol is a type,
       enum value, or intrinsic	it will	 not  be  recognized  (consider	 using
       CheckTypeSize  or CheckCSourceCompiles).	 If the	check needs to be done
       in C++, consider	using CheckCXXSymbolExists instead.

       The following variables may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      a	;-list of macros to define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      a	;-list of header search	paths to pass to the compiler.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: a ;-list of options to add to the link com-
	      mand.

       CMAKE_REQUIRED_LIBRARIES
	      a	;-list of libraries to add to the  link	 command.  See	policy
	      CMP0075.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       For example:

	  include(CheckSymbolExists)

	  # Check for macro SEEK_SET
	  check_symbol_exists(SEEK_SET "stdio.h" HAVE_SEEK_SET)
	  # Check for function fopen
	  check_symbol_exists(fopen "stdio.h" HAVE_FOPEN)

   CheckTypeSize
       Check sizeof a type

       CHECK_TYPE_SIZE

		 CHECK_TYPE_SIZE(TYPE VARIABLE [BUILTIN_TYPES_ONLY]
					       [LANGUAGE <language>])

	      Check  if	 the  type  exists and determine its size.  On return,
	      HAVE_${VARIABLE} holds the existence of the  type,  and  ${VARI-
	      ABLE} holds one of the following:

		 <size>	= type has non-zero size <size>
		 "0"	= type has arch-dependent size (see below)
		 ""	= type does not	exist

	      Both  HAVE_${VARIABLE} and ${VARIABLE} will be created as	inter-
	      nal cache	variables.

	      Furthermore, the variable	${VARIABLE}_CODE holds C  preprocessor
	      code to define the macro ${VARIABLE} to the size of the type, or
	      leave the	macro undefined	if the type does not exist.

	      The variable ${VARIABLE} may be 0	 when  CMAKE_OSX_ARCHITECTURES
	      has multiple architectures for building OS X universal binaries.
	      This indicates that the type size	varies	across	architectures.
	      In this case ${VARIABLE}_CODE contains C preprocessor tests map-
	      ping from	each architecture  macro  to  the  corresponding  type
	      size.   The  list	 of  architecture  macros is stored in ${VARI-
	      ABLE}_KEYS, and the value	for each  key  is  stored  in  ${VARI-
	      ABLE}-${KEY}.

	      If  the BUILTIN_TYPES_ONLY option	is not given, the macro	checks
	      for headers <sys/types.h>, <stdint.h>, and <stddef.h>, and saves
	      results  in  HAVE_SYS_TYPES_H, HAVE_STDINT_H, and	HAVE_STDDEF_H.
	      The type size check automatically	includes the  available	 head-
	      ers, thus	supporting checks of types defined in the headers.

	      If  LANGUAGE is set, the specified compiler will be used to per-
	      form the check. Acceptable values	are C and CXX.

       Despite the name	of the macro you may use it to check the size of  more
       complex expressions, too.  To check e.g.	 for the size of a struct mem-
       ber you can do something	like this:

	  check_type_size("((struct something*)0)->member" SIZEOF_MEMBER)

       The following variables may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      list of macros to	define (-DFOO=bar).

       CMAKE_REQUIRED_INCLUDES
	      list of include directories.

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: list	of options to pass to link command.

       CMAKE_REQUIRED_LIBRARIES
	      list of libraries	to link.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

       CMAKE_EXTRA_INCLUDE_FILES
	      list of extra headers to include.

   CheckVariableExists
       Check if	the variable exists.

       CHECK_VARIABLE_EXISTS

		 CHECK_VARIABLE_EXISTS(VAR VARIABLE)

		 VAR	  - the	name of	the variable
		 VARIABLE - variable to	store the result
			    Will be created as an internal cache variable.

	      This macro is only for C variables.

       The  following variables	may be set before calling this macro to	modify
       the way the check is run:

       CMAKE_REQUIRED_FLAGS
	      string of	compile	command	line flags.

       CMAKE_REQUIRED_DEFINITIONS
	      list of macros to	define (-DFOO=bar).

       CMAKE_REQUIRED_LINK_OPTIONS
	      New in version 3.14: list	of options to pass to link command.

       CMAKE_REQUIRED_LIBRARIES
	      list of libraries	to link.

       CMAKE_REQUIRED_QUIET
	      New in version 3.1: execute quietly without messages.

   CMakeAddFortranSubdirectory
       Add a fortran-only subdirectory,	find a fortran compiler, and build.

       The cmake_add_fortran_subdirectory function adds	a  subdirectory	 to  a
       project that contains a fortran-only subproject.	 The module will check
       the current compiler and	see if it can support fortran.	If no  fortran
       compiler	 is found and the compiler is MSVC, then this module will find
       the MinGW gfortran.  It will then use an	external project to build with
       the  MinGW  tools.   It	will  also create imported targets for the li-
       braries created.	 This will only	work if	the fortran code is built into
       a  dll,	so BUILD_SHARED_LIBS is	turned on in the project.  In addition
       the CMAKE_GNUtoMS option	is set to on, so that Microsoft	.lib files are
       created.	 Usage is as follows:

	  cmake_add_fortran_subdirectory(
	   <subdir>		   # name of subdirectory
	   PROJECT <project_name>  # project name in subdir top	CMakeLists.txt
	   ARCHIVE_DIR <dir>	   # dir where project places .lib files
	   RUNTIME_DIR <dir>	   # dir where project places .dll files
	   LIBRARIES <lib>...	   # names of library targets to import
	   LINK_LIBRARIES	   # link interface libraries for LIBRARIES
	    [LINK_LIBS <lib> <dep>...]...
	   CMAKE_COMMAND_LINE ...  # extra command line	flags to pass to cmake
	   NO_EXTERNAL_INSTALL	   # skip installation of external project
	   )

       Relative	 paths in ARCHIVE_DIR and RUNTIME_DIR are interpreted with re-
       spect to	the build directory corresponding to the source	 directory  in
       which the function is invoked.

       Limitations:

       NO_EXTERNAL_INSTALL is required for forward compatibility with a	future
       version that supports installation of  the  external  project  binaries
       during make install.

   CMakeBackwardCompatibilityCXX
       define a	bunch of backwards compatibility variables

	  CMAKE_ANSI_CXXFLAGS -	flag for ansi c++
	  CMAKE_HAS_ANSI_STRING_STREAM - has <strstream>
	  include(TestForANSIStreamHeaders)
	  include(CheckIncludeFileCXX)
	  include(TestForSTDNamespace)
	  include(TestForANSIForScope)

   CMakeDependentOption
       Macro to	provide	an option dependent on other options.

       This macro presents an option to	the user only if a set of other	condi-
       tions are true.

       Usage:

	  cmake_dependent_option(<option> "<help_text>"	<value>	<depends> <force>)

       Where <option> is available to the user if <depends> is true. When <op-
       tion> is	available, the given <help_text> and initial <value> are used.
       If the <depends>	condition is not true, <option>	will not be  presented
       and  will  always have the value	given by <force>. Any value set	by the
       user is preserved for when the option is	presented again. Each  element
       in  the	fourth parameter is evaluated as an if-condition, so Condition
       Syntax can be used.

       Example invocation:

	  cmake_dependent_option(USE_FOO "Use Foo" ON
				 "USE_BAR;NOT USE_ZOT" OFF)

       If USE_BAR is true and USE_ZOT is false,	this provides an option	called
       USE_FOO	that  defaults	to  ON.	 Otherwise, it sets USE_FOO to OFF and
       hides the option	from the user. If the status  of  USE_BAR  or  USE_ZOT
       ever  changes,  any  value for the USE_FOO option is saved so that when
       the option is re-enabled	it retains its old value.

   CMakeFindDependencyMacro
       find_dependency
	      The find_dependency() macro wraps	a find_package()  call	for  a
	      package dependency:

		 find_dependency(<dep> [...])

	      It  is  designed	to  be	used  in  a Package Configuration File
	      (<PackageName>Config.cmake).  find_dependency forwards the  cor-
	      rect  parameters for QUIET and REQUIRED which were passed	to the
	      original find_package() call.  Any additional  arguments	speci-
	      fied are forwarded to find_package().

	      If  the dependency could not be found it sets an informative di-
	      agnostic message and calls return() to  end  processing  of  the
	      calling  package configuration file and return to	the find_pack-
	      age() command that loaded	it.

	      NOTE:
		 The call to return() makes this macro unsuitable to call from
		 Find Modules.

   CMakeFindFrameworks
       helper module to	find OSX frameworks

       This module reads hints about search locations from variables:

	  CMAKE_FIND_FRAMEWORK_EXTRA_LOCATIONS - Extra directories

   CMakeFindPackageMode
       This  file  is  executed	by cmake when invoked with --find-package.  It
       expects that the	following variables are	set using -D:

       NAME   name of the package

       COMPILER_ID
	      the CMake	compiler ID for	which  the  result  is,	 i.e.  GNU/In-
	      tel/Clang/MSVC, etc.

       LANGUAGE
	      language	for  which  the	 result	 will be used, i.e. C/CXX/For-
	      tran/ASM

       MODE

	      EXIST  only check	for existence of the given package

	      COMPILE
		     print the flags needed for	compiling an object file which
		     uses the given package

	      LINK   print  the	 flags needed for linking when using the given
		     package

       QUIET  if TRUE, don't print anything

   CMakeGraphVizOptions
       The builtin Graphviz support of CMake.

   Generating Graphviz files
       CMake can generate Graphviz files showing the dependencies between  the
       targets	in  a  project,	as well	as external libraries which are	linked
       against.

       When running CMake with the --graphviz=foo.dot option, it produces:

       o a foo.dot file, showing all dependencies in the project

       o a foo.dot.<target> file for each target, showing on which other  tar-
	 gets it depends

       o a  foo.dot.<target>.dependers	file  for  each	 target, showing which
	 other targets depend on it

       Those .dot files	can be converted to images using the dot command  from
       the Graphviz package:

	  dot -Tpng -o foo.png foo.dot

       New  in	version	3.10: The different dependency types PUBLIC, INTERFACE
       and PRIVATE are represented as solid, dashed and	dotted edges.

   Variables specific to the Graphviz support
       The resulting graphs can	be huge.  The look and content of  the	gener-
       ated   graphs   can  be	controlled  using  the	file  CMakeGraphVizOp-
       tions.cmake.  This file is first	searched in CMAKE_BINARY_DIR, and then
       in CMAKE_SOURCE_DIR.  If	found, the variables set in it are used	to ad-
       just options for	the generated Graphviz files.

       GRAPHVIZ_GRAPH_NAME
	      The graph	name.

	      o	Mandatory: NO

	      o	Default: value of CMAKE_PROJECT_NAME

       GRAPHVIZ_GRAPH_HEADER
	      The header written at the	top of the Graphviz files.

	      o	Mandatory: NO

	      o	Default: "node [ fontsize = "12" ];"

       GRAPHVIZ_NODE_PREFIX
	      The prefix for each node in the Graphviz files.

	      o	Mandatory: NO

	      o	Default: "node"

       GRAPHVIZ_EXECUTABLES
	      Set to FALSE to exclude executables from the generated graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_STATIC_LIBS
	      Set to FALSE to exclude  static  libraries  from	the  generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_SHARED_LIBS
	      Set  to  FALSE  to  exclude  shared libraries from the generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_MODULE_LIBS
	      Set to FALSE to exclude  module  libraries  from	the  generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_INTERFACE_LIBS
	      Set  to  FALSE to	exclude	interface libraries from the generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_OBJECT_LIBS
	      Set to FALSE to exclude  object  libraries  from	the  generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_UNKNOWN_LIBS
	      Set  to  FALSE  to  exclude unknown libraries from the generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_EXTERNAL_LIBS
	      Set to FALSE to exclude external libraries  from	the  generated
	      graphs.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_CUSTOM_TARGETS
	      Set to TRUE to include custom targets in the generated graphs.

	      o	Mandatory: NO

	      o	Default: FALSE

       GRAPHVIZ_IGNORE_TARGETS
	      A	 list  of  regular expressions for names of targets to exclude
	      from the generated graphs.

	      o	Mandatory: NO

	      o	Default: empty

       GRAPHVIZ_GENERATE_PER_TARGET
	      Set to FALSE to not generate per-target graphs foo.dot.<target>.

	      o	Mandatory: NO

	      o	Default: TRUE

       GRAPHVIZ_GENERATE_DEPENDERS
	      Set to FALSE  to	not  generate  depender	 graphs	 foo.dot.<tar-
	      get>.dependers.

	      o	Mandatory: NO

	      o	Default: TRUE

   CMakePackageConfigHelpers
       Helpers	functions  for	creating  config files that can	be included by
       other projects to find and use a	package.

       Adds	     the	  configure_package_config_file()	   and
       write_basic_package_version_file() commands.

   Generating a	Package	Configuration File
       configure_package_config_file
	      Create a config file for a project:

		 configure_package_config_file(<input> <output>
		   INSTALL_DESTINATION <path>
		   [PATH_VARS <var1> <var2> ...	<varN>]
		   [NO_SET_AND_CHECK_MACRO]
		   [NO_CHECK_REQUIRED_COMPONENTS_MACRO]
		   [INSTALL_PREFIX <path>]
		   )

       configure_package_config_file()	should	be  used  instead of the plain
       configure_file()	command	when creating the <PackageName>Config.cmake or
       <PackageName>-config.cmake  file	 for  installing a project or library.
       It helps	making the resulting package relocatable by avoiding hardcoded
       paths in	the installed Config.cmake file.

       In  a  FooConfig.cmake file there may be	code like this to make the in-
       stall destinations know to the using project:

	  set(FOO_INCLUDE_DIR	"@CMAKE_INSTALL_FULL_INCLUDEDIR@" )
	  set(FOO_DATA_DIR   "@CMAKE_INSTALL_PREFIX@/@RELATIVE_DATA_INSTALL_DIR@" )
	  set(FOO_ICONS_DIR   "@CMAKE_INSTALL_PREFIX@/share/icons" )
	  #...logic to determine installedPrefix from the own location...
	  set(FOO_CONFIG_DIR  "${installedPrefix}/@CONFIG_INSTALL_DIR@"	)

       All 4 options shown above are not sufficient, since the first  3	 hard-
       code  the  absolute directory locations,	and the	4th case works only if
       the logic to determine the installedPrefix  is  correct,	 and  if  CON-
       FIG_INSTALL_DIR	contains  a  relative path, which in general cannot be
       guaranteed.  This has the effect	 that  the  resulting  FooConfig.cmake
       file  would  work poorly	under Windows and OSX, where users are used to
       choose the install location of a	binary package at install time,	 inde-
       pendent from how	CMAKE_INSTALL_PREFIX was set at	build/cmake time.

       Using configure_package_config_file helps.  If used correctly, it makes
       the resulting FooConfig.cmake file relocatable.	Usage:

       1. write	a FooConfig.cmake.in file as you are used to

       2. insert a line	containing only	the string @PACKAGE_INIT@

       3. instead  of  set(FOO_DIR  "@SOME_INSTALL_DIR@"),   use   set(FOO_DIR
	  "@PACKAGE_SOME_INSTALL_DIR@")	(this must be after the	@PACKAGE_INIT@
	  line)

       4. instead of using the normal  configure_file(),  use  configure_pack-
	  age_config_file()

       The  <input>  and <output> arguments are	the input and output file, the
       same way	as in configure_file().

       The <path> given	to INSTALL_DESTINATION must be the  destination	 where
       the FooConfig.cmake file	will be	installed to.  This path can either be
       absolute, or relative to	the INSTALL_PREFIX path.

       The variables <var1> to <varN> given as	PATH_VARS  are	the  variables
       which  contain  install	destinations.  For each	of them	the macro will
       create a	helper variable	PACKAGE_<var...>.  These helper	variables must
       be  used	in the FooConfig.cmake.in file for setting the installed loca-
       tion.  They are calculated  by  configure_package_config_file  so  that
       they  are  always  relative  to	the installed location of the package.
       This works both for relative and	also for absolute locations.  For  ab-
       solute  locations it works only if the absolute location	is a subdirec-
       tory of INSTALL_PREFIX.

       New in version 3.1: If the INSTALL_PREFIX argument is passed,  this  is
       used  as	base path to calculate all the relative	paths.	The <path> ar-
       gument must be an absolute path.	 If this argument is not  passed,  the
       CMAKE_INSTALL_PREFIX  variable will be used instead.  The default value
       is good when generating a FooConfig.cmake file to use your package from
       the  install  tree.  When generating a FooConfig.cmake file to use your
       package from the	build tree this	option should be used.

       By default  configure_package_config_file  also	generates  two	helper
       macros,	 set_and_check()   and	check_required_components()  into  the
       FooConfig.cmake file.

       set_and_check() should be used instead of the normal set() command  for
       setting	directories  and  file locations.  Additionally	to setting the
       variable	it also	checks that the	referenced file	or directory  actually
       exists  and  fails  with	a FATAL_ERROR otherwise.  This makes sure that
       the created FooConfig.cmake file	does  not  contain  wrong  references.
       When using the NO_SET_AND_CHECK_MACRO, this macro is not	generated into
       the FooConfig.cmake file.

       check_required_components(<PackageName>)	should be called at the	end of
       the  FooConfig.cmake  file.  This  macro	 checks	whether	all requested,
       non-optional components have been found,	and if this is not  the	 case,
       sets the	Foo_FOUND variable to FALSE, so	that the package is considered
       to be not found.	 It does that  by  testing  the	 Foo_<Component>_FOUND
       variables  for all requested required components.  This macro should be
       called even if the package doesn't provide any components to make  sure
       users  are  not	specifying  components	erroneously.   When  using the
       NO_CHECK_REQUIRED_COMPONENTS_MACRO option, this macro is	not  generated
       into the	FooConfig.cmake	file.

       For     an     example	  see	  below	   the	  documentation	   for
       write_basic_package_version_file().

   Generating a	Package	Version	File
       write_basic_package_version_file
	      Create a version file for	a project:

		 write_basic_package_version_file(<filename>
		   [VERSION <major.minor.patch>]
		   COMPATIBILITY <AnyNewerVersion|SameMajorVersion|SameMinorVersion|ExactVersion>
		   [ARCH_INDEPENDENT] )

       Writes a	file  for  use	as  <PackageName>ConfigVersion.cmake  file  to
       <filename>.   See  the  documentation  of find_package()	for details on
       this.

       <filename> is the output	filename, it should  be	 in  the  build	 tree.
       <major.minor.patch>  is	the  version  number  of the project to	be in-
       stalled.

       If no VERSION is	given, the PROJECT_VERSION variable is used.  If  this
       hasn't been set,	it errors out.

       The COMPATIBILITY mode AnyNewerVersion means that the installed package
       version will be considered compatible if	it is  newer  or  exactly  the
       same  as	 the requested version.	 This mode should be used for packages
       which are fully backward	compatible, also across	 major	versions.   If
       SameMajorVersion	 is  used  instead,  then  the	behaviour differs from
       AnyNewerVersion in that the major version number	must be	 the  same  as
       requested,  e.g.	  version 2.0 will not be considered compatible	if 1.0
       is requested.  This mode	should be used for  packages  which  guarantee
       backward	compatibility within the same major version.  If SameMinorVer-
       sion is used, the behaviour is the same as SameMajorVersion,  but  both
       major  and minor	version	must be	the same as requested, e.g version 0.2
       will not	be compatible if 0.1 is	requested.  If ExactVersion  is	 used,
       then the	package	is only	considered compatible if the requested version
       matches exactly its own version number (not considering the tweak  ver-
       sion).  For example, version 1.2.3 of a package is only considered com-
       patible to requested version 1.2.3.  This mode is for packages  without
       compatibility  guarantees.  If your project has more elaborated version
       matching	rules, you will	need  to  write	 your  own  custom  ConfigVer-
       sion.cmake file instead of using	this macro.

       New in version 3.11: The	SameMinorVersion compatibility mode.

       New  in version 3.14: If	ARCH_INDEPENDENT is given, the installed pack-
       age version will	be considered compatible even if it was	 built	for  a
       different  architecture than the	requested architecture.	 Otherwise, an
       architecture check will be performed, and the package will  be  consid-
       ered compatible only if the architecture	matches	exactly.  For example,
       if the package is built for a 32-bit architecture, the package is  only
       considered  compatible  if  it is used on a 32-bit architecture,	unless
       ARCH_INDEPENDENT	is given, in which case	the package is considered com-
       patible on any architecture.

       NOTE:
	  ARCH_INDEPENDENT  is	intended  for header-only libraries or similar
	  packages with	no binaries.

       New in version 3.19: COMPATIBILITY_MODE AnyNewerVersion,	 SameMajorVer-
       sion  and SameMinorVersion handle the version range if any is specified
       (see find_package() command for the details).  ExactVersion mode	is in-
       compatible  with	 version  ranges and will display an author warning if
       one is specified.

       Internally, this	macro executes configure_file()	to create the  result-
       ing  version  file.   Depending on the COMPATIBILITY, the corresponding
       BasicConfigVersion-<COMPATIBILITY>.cmake.in file	is used.  Please  note
       that  these files are internal to CMake and you should not call config-
       ure_file() on them yourself, but	they can be used as starting point  to
       create more sophisticted	custom ConfigVersion.cmake files.

   Example Generating Package Files
       Example	 using	 both  configure_package_config_file()	and  write_ba-
       sic_package_version_file():

       CMakeLists.txt:

	  set(INCLUDE_INSTALL_DIR include/ ... CACHE )
	  set(LIB_INSTALL_DIR lib/ ... CACHE )
	  set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE )
	  #...
	  include(CMakePackageConfigHelpers)
	  configure_package_config_file(FooConfig.cmake.in
	    ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
	    INSTALL_DESTINATION	${LIB_INSTALL_DIR}/Foo/cmake
	    PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
	  write_basic_package_version_file(
	    ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
	    VERSION 1.2.3
	    COMPATIBILITY SameMajorVersion )
	  install(FILES	${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
			${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
		  DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )

       FooConfig.cmake.in:

	  set(FOO_VERSION x.y.z)
	  ...
	  @PACKAGE_INIT@
	  ...
	  set_and_check(FOO_INCLUDE_DIR	"@PACKAGE_INCLUDE_INSTALL_DIR@")
	  set_and_check(FOO_SYSCONFIG_DIR "@PACKAGE_SYSCONFIG_INSTALL_DIR@")

	  check_required_components(Foo)

   CMakePrintHelpers
       Convenience functions for printing  properties  and  variables,	useful
       e.g. for	debugging.

	  cmake_print_properties([TARGETS target1 ..  targetN]
				[SOURCES source1 .. sourceN]
				[DIRECTORIES dir1 .. dirN]
				[TESTS test1 ..	testN]
				[CACHE_ENTRIES entry1 .. entryN]
				PROPERTIES prop1 .. propN )

       This function prints the	values of the properties of the	given targets,
       source files, directories, tests	or cache entries.  Exactly one of  the
       scope keywords must be used.  Example:

	  cmake_print_properties(TARGETS foo bar PROPERTIES
				 LOCATION INTERFACE_INCLUDE_DIRECTORIES)

       This  will print	the LOCATION and INTERFACE_INCLUDE_DIRECTORIES proper-
       ties for	both targets foo and bar.

	  cmake_print_variables(var1 var2 ..  varN)

       This function will print	the name of  each  variable  followed  by  its
       value.  Example:

	  cmake_print_variables(CMAKE_C_COMPILER CMAKE_MAJOR_VERSION DOES_NOT_EXIST)

       Gives:

	  -- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ; DOES_NOT_EXIST=""

   CMakePrintSystemInformation
       Print system information.

       This module serves diagnostic purposes. Just include it in a project to
       see various internal CMake variables.

   CMakePushCheckState
       This   module   defines	  three	   macros:    CMAKE_PUSH_CHECK_STATE()
       CMAKE_POP_CHECK_STATE()	and CMAKE_RESET_CHECK_STATE() These macros can
       be used to save,	restore	and reset (i.e., clear contents) the state  of
       the    variables	   CMAKE_REQUIRED_FLAGS,   CMAKE_REQUIRED_DEFINITIONS,
       CMAKE_REQUIRED_LINK_OPTIONS,    CMAKE_REQUIRED_LIBRARIES,     CMAKE_RE-
       QUIRED_INCLUDES	and  CMAKE_EXTRA_INCLUDE_FILES	used  by  the  various
       Check-files coming with CMake, like e.g.	 check_function_exists()  etc.
       The  variable contents are pushed on a stack, pushing multiple times is
       supported.  This	is  useful  e.g.   when	 executing  such  tests	 in  a
       Find-module,  where  they have to be set, but after the Find-module has
       been executed they should have the same value as	they had before.

       CMAKE_PUSH_CHECK_STATE()	 macro	receives  optional   argument	RESET.
       Whether it's specified, CMAKE_PUSH_CHECK_STATE()	will set all CMAKE_RE-
       QUIRED_*	variables to empty values, same	 as  CMAKE_RESET_CHECK_STATE()
       call will do.

       Usage:

	  cmake_push_check_state(RESET)
	  set(CMAKE_REQUIRED_DEFINITIONS -DSOME_MORE_DEF)
	  check_function_exists(...)
	  cmake_reset_check_state()
	  set(CMAKE_REQUIRED_DEFINITIONS -DANOTHER_DEF)
	  check_function_exists(...)
	  cmake_pop_check_state()

   CMakeVerifyManifest
       CMakeVerifyManifest.cmake

       This  script is used to verify that embedded manifests and side by side
       manifests for a project match.  To run this script, cd to  a  directory
       and  run	the script with	cmake -P.  On the command line you can pass in
       versions	that are OK even if not	found in the .manifest files.  For ex-
       ample,  cmake  -Dallow_versions=8.0.50608.0 -PCmakeVerifyManifest.cmake
       could be	used to	allow an embedded manifest of 8.0.50608.0 to  be  used
       in a project even if that version was not found in the .manifest	file.

   CPack
       Configure generators for	binary installers and source packages.

   Introduction
       The  CPack  module  generates the configuration files CPackConfig.cmake
       and CPackSourceConfig.cmake. They are intended for use in a  subsequent
       run of  the cpack program where they steer the generation of installers
       or/and source packages.

       Depending on the	CMake generator, the CPack module may also add two new
       build  targets,	package	 and package_source. See the packaging targets
       section below for details.

       The generated binary installers will contain all	files that  have  been
       installed  via  CMake's	install() command (and the deprecated commands
       install_files(),	install_programs(), and	install_targets()). Note  that
       the  DESTINATION	 option	 of  the  install() command must be a relative
       path; otherwise installed files are ignored by CPack.

       Certain kinds of	binary installers can be configured  such  that	 users
       can  select  individual	application  components	 to  install.  See the
       CPackComponent module for further details.

       Source packages (configured through CPackSourceConfig.cmake and	gener-
       ated  by	 the CPack Archive Generator) will contain all source files in
       the     project	   directory	 except	    those     specified	    in
       CPACK_SOURCE_IGNORE_FILES.

   CPack Generators
       The  CPACK_GENERATOR  variable has different meanings in	different con-
       texts.  In a CMakeLists.txt file, CPACK_GENERATOR is a list of  genera-
       tors:  and  when	 cpack is run with no other arguments, it will iterate
       over that list and produce  one	package	 for  each  generator.	 In  a
       CPACK_PROJECT_CONFIG_FILE,  CPACK_GENERATOR is a	string naming a	single
       generator.  If you need	per-cpack-generator  logic  to	control	 other
       cpack settings, then you	need a CPACK_PROJECT_CONFIG_FILE.  If set, the
       CPACK_PROJECT_CONFIG_FILE is included automatically on a	 per-generator
       basis.  It only need contain overrides.

       Here's how it works:

       o cpack runs

       o it includes CPackConfig.cmake

       o it  iterates over the generators given	by the -G command line option,
	 or if no such option was specified, over the list of generators given
	 by  the  CPACK_GENERATOR  variable set	in the CPackConfig.cmake input
	 file.

       o foreach generator, it then

	 o sets	CPACK_GENERATOR	to the one currently being iterated

	 o includes the	CPACK_PROJECT_CONFIG_FILE

	 o produces the	package	for that generator

       This is the key:	For each generator listed in CPACK_GENERATOR in	CPack-
       Config.cmake,  cpack  will  reset CPACK_GENERATOR internally to the one
       currently being used and	then include the CPACK_PROJECT_CONFIG_FILE.

       For a list of available generators, see cpack-generators(7).

   Targets package and package_source
       If CMake	is run with the	Makefile, Ninja, or Xcode generator, then  in-
       clude(CPack)  generates	a  target  package.  This makes	it possible to
       build a binary installer	from CMake, Make, or Ninja: Instead of	cpack,
       one  may	call cmake --build . --target package or make package or ninja
       package.	The VS generator creates an uppercase target PACKAGE.

       If CMake	is  run	 with  the  Makefile  or  Ninja	 generator,  then  in-
       clude(CPack)  also generates a target package_source. To	build a	source
       package,	instead	of cpack -G TGZ	--config  CPackSourceConfig.cmake  one
       may  call cmake --build . --target package_source, make package_source,
       or ninja	package_source.

   Variables common to all CPack Generators
       Before including	this CPack module in your CMakeLists.txt  file,	 there
       are  a  variety of variables that can be	set to customize the resulting
       installers.  The	most commonly-used variables are:

       CPACK_PACKAGE_NAME
	      The name of the package (or application).	 If not	specified,  it
	      defaults to the project name.

       CPACK_PACKAGE_VENDOR
	      The  name	of the package vendor. (e.g., "Kitware").  The default
	      is "Humanity".

       CPACK_PACKAGE_DIRECTORY
	      The directory in which CPack is doing its	packaging.  If	it  is
	      not  set	then  this will	default	(internally) to	the build dir.
	      This variable may	be defined in a	CPack config file or from  the
	      cpack  command  line option -B.  If set, the command line	option
	      overrides	the value found	in the config file.

       CPACK_PACKAGE_VERSION_MAJOR
	      Package major version.  This variable will always	 be  set,  but
	      its default value	depends	on whether or not version details were
	      given to the project() command in	the top	 level	CMakeLists.txt
	      file.   If version details were given, the default value will be
	      CMAKE_PROJECT_VERSION_MAJOR.  If no version details were	given,
	      a	  default  version  of	0.1.1  will  be	 assumed,  leading  to
	      CPACK_PACKAGE_VERSION_MAJOR having a default value of 0.

       CPACK_PACKAGE_VERSION_MINOR
	      Package minor version.  The default value	is determined based on
	      whether  or not version details were given to the	project() com-
	      mand in the top level CMakeLists.txt file.  If  version  details
	      were  given, the default value will be CMAKE_PROJECT_VERSION_MI-
	      NOR, but if  no  minor  version  component  was  specified  then
	      CPACK_PACKAGE_VERSION_MINOR  will	 be left unset.	 If no project
	      version was given	at all,	a default version of 0.1.1 will	be as-
	      sumed,  leading  to CPACK_PACKAGE_VERSION_MINOR having a default
	      value of 1.

       CPACK_PACKAGE_VERSION_PATCH
	      Package patch version.  The default value	is determined based on
	      whether  or not version details were given to the	project() com-
	      mand in the top level CMakeLists.txt file.  If  version  details
	      were   given,  the  default  value  will	be  CMAKE_PROJECT_VER-
	      SION_PATCH, but if no patch version component was	specified then
	      CPACK_PACKAGE_VERSION_PATCH  will	 be left unset.	 If no project
	      version was given	at all,	a default version of 0.1.1 will	be as-
	      sumed,  leading  to CPACK_PACKAGE_VERSION_PATCH having a default
	      value of 1.

       CPACK_PACKAGE_DESCRIPTION
	      A	description of the project, used in places such	as the	intro-
	      duction  screen  of  CPack-generated Windows installers.	If not
	      set, the value of	this variable is populated from	the file named
	      by CPACK_PACKAGE_DESCRIPTION_FILE.

       CPACK_PACKAGE_DESCRIPTION_FILE
	      A	   text	   file	   used	  to   describe	  the	project	  when
	      CPACK_PACKAGE_DESCRIPTION	is not explicitly  set.	  The  default
	      value  for  CPACK_PACKAGE_DESCRIPTION_FILE  points to a built-in
	      template file Templates/CPack.GenericDescription.txt.

       CPACK_PACKAGE_DESCRIPTION_SUMMARY
	      Short description	of the project (only a	few  words).   If  the
	      CMAKE_PROJECT_DESCRIPTION	variable is set, it is used as the de-
	      fault value, otherwise the default will be a string generated by
	      CMake based on CMAKE_PROJECT_NAME.

       CPACK_PACKAGE_HOMEPAGE_URL
	      Project  homepage	 URL.	The  default  value  is	taken from the
	      CMAKE_PROJECT_HOMEPAGE_URL variable, which is  set  by  the  top
	      level project() command, or else the default will	be empty if no
	      URL was provided to project().

       CPACK_PACKAGE_FILE_NAME
	      The name of the package file to generate,	not including the  ex-
	      tension.	 For  example,	cmake-2.6.1-Linux-i686.	  The  default
	      value is:

		 ${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}

       CPACK_PACKAGE_INSTALL_DIRECTORY
	      Installation directory on	the target system. This	may be used by
	      some CPack generators like NSIS to create	an installation	direc-
	      tory e.g., "CMake	2.5" below the installation prefix.   All  in-
	      stalled elements will be put inside this directory.

       CPACK_PACKAGE_ICON
	      A	 branding  image  that	will be	displayed inside the installer
	      (used by GUI installers).

       CPACK_PACKAGE_CHECKSUM
	      New in version 3.7.

	      An algorithm that	will be	used to	generate  an  additional  file
	      with the checksum	of the package.	 The output file name will be:

		 ${CPACK_PACKAGE_FILE_NAME}.${CPACK_PACKAGE_CHECKSUM}

	      Supported	algorithms are those listed by the string(<HASH>) com-
	      mand.

       CPACK_PROJECT_CONFIG_FILE
	      CPack-time project CPack configuration file.  This file  is  in-
	      cluded  at  cpack	 time,	once per generator after CPack has set
	      CPACK_GENERATOR to the actual generator being used.   It	allows
	      per-generator setting of CPACK_* variables at cpack time.

       CPACK_RESOURCE_FILE_LICENSE
	      License  to  be embedded in the installer.  It will typically be
	      displayed	to the user by the produced installer (often  with  an
	      explicit "Accept"	button,	for graphical installers) prior	to in-
	      stallation.  This	license	file is	NOT  added  to	the  installed
	      files  but  is  used by some CPack generators like NSIS.	If you
	      want to install a	license	file (may be the  same	as  this  one)
	      along  with  your	project, you must add an appropriate CMake in-
	      stall() command in your CMakeLists.txt.

       CPACK_RESOURCE_FILE_README
	      ReadMe file to be	embedded in the	installer.  It	typically  de-
	      scribes in some detail the purpose of the	project	during the in-
	      stallation.  Not all CPack generators use	this file.

       CPACK_RESOURCE_FILE_WELCOME
	      Welcome file to be embedded in the installer.  It	welcomes users
	      to  this	installer.  Typically used in the graphical installers
	      on Windows and Mac OS X.

       CPACK_MONOLITHIC_INSTALL
	      Disables the component-based installation	mechanism.  When  set,
	      the  component  specification is ignored and all installed items
	      are put in a single "MONOLITHIC" package.	 Some CPack generators
	      do monolithic packaging by default and may be asked to do	compo-
	      nent packaging by	setting	 CPACK_<GENNAME>_COMPONENT_INSTALL  to
	      TRUE.

       CPACK_GENERATOR
	      List  of	CPack generators to use.  If not specified, CPack will
	      create  a	 set  of  options   following	the   naming   pattern
	      CPACK_BINARY__GENNAME_  (e.g.  CPACK_BINARY_NSIS)	 allowing  the
	      user to enable/disable individual	generators.  If	the -G	option
	      is  given	on the cpack command line, it will override this vari-
	      able and any CPACK_BINARY_<GENNAME> options.

       CPACK_OUTPUT_CONFIG_FILE
	      The name of the CPack binary configuration file.	This  file  is
	      the CPack	configuration generated	by the CPack module for	binary
	      installers.  Defaults to CPackConfig.cmake.

       CPACK_PACKAGE_EXECUTABLES
	      Lists each of the	executables and	associated text	 label	to  be
	      used  to create Start Menu shortcuts.  For example, setting this
	      to the list ccmake;CMake will create a  shortcut	named  "CMake"
	      that  will  execute  the	installed  executable ccmake.  Not all
	      CPack generators use it (at least	NSIS, WIX and OSXX11 do).

       CPACK_STRIP_FILES
	      List of files  to	 be  stripped.	 Starting  with	 CMake	2.6.0,
	      CPACK_STRIP_FILES	 will  be  a  boolean  variable	 which enables
	      stripping	of all files (a	list of	files  evaluates  to  TRUE  in
	      CMake, so	this change is compatible).

       CPACK_VERBATIM_VARIABLES
	      New in version 3.4.

	      If set to	TRUE, values of	variables prefixed with	CPACK_ will be
	      escaped before being written to the configuration	files, so that
	      the  cpack program receives them exactly as they were specified.
	      If not, characters like quotes and backslashes can cause parsing
	      errors  or  alter	 the value received by the cpack program.  De-
	      faults to	FALSE for backwards compatibility.

       CPACK_THREADS
	      New in version 3.20.

	      Number of	threads	to use	when  performing  parallelized	opera-
	      tions, such as compressing the installer package.

	      Some compression methods used by CPack generators	such as	Debian
	      or Archive may take advantage of multiple	CPU cores to speed  up
	      compression.   CPACK_THREADS  can	 be set	to positive integer to
	      specify how many threads will be used for	compression. If	it  is
	      set  to 0, CPack will set	it so that all available CPU cores are
	      used.  By	default	CPACK_THREADS is set to	1.

	      Currently	only xz	compression may	 take  advantage  of  multiple
	      cores.  Other compression	methods	ignore this value and use only
	      one thread.

	      NOTE:
		 Official CMake	binaries available on cmake.org	 ship  with  a
		 liblzma that does not support parallel	compression.

   Variables for Source	Package	Generators
       The following CPack variables are specific to source packages, and will
       not affect binary packages:

       CPACK_SOURCE_PACKAGE_FILE_NAME
	      The name of the source package.  For example cmake-2.6.1.

       CPACK_SOURCE_STRIP_FILES
	      List of files in the source tree that will be stripped.	Start-
	      ing with CMake 2.6.0, CPACK_SOURCE_STRIP_FILES will be a boolean
	      variable which enables stripping of all files (a list  of	 files
	      evaluates	to TRUE	in CMake, so this change is compatible).

       CPACK_SOURCE_GENERATOR
	      List  of	generators  used  for  the  source  packages.  As with
	      CPACK_GENERATOR, if this is not specified	then CPack will	create
	      a	 set  of options (e.g. CPACK_SOURCE_ZIP) allowing users	to se-
	      lect which packages will be generated.

       CPACK_SOURCE_OUTPUT_CONFIG_FILE
	      The name of the CPack source configuration file.	This  file  is
	      the CPack	configuration generated	by the CPack module for	source
	      installers.  Defaults to CPackSourceConfig.cmake.

       CPACK_SOURCE_IGNORE_FILES
	      Pattern of files in the source tree that won't be	packaged  when
	      building a source	package.  This is a list of regular expression
	      patterns	 (that	  must	  be	properly    escaped),	 e.g.,
	      /CVS/;/\\.svn/;\\.swp$;\\.#;/#;.*~;cscope.*

   Variables for Advanced Use
       The following variables are for advanced	uses of	CPack:

       CPACK_CMAKE_GENERATOR
	      What  CMake  generator  should be	used if	the project is a CMake
	      project.	Defaults to the	value of CMAKE_GENERATOR.   Few	 users
	      will want	to change this setting.

       CPACK_INSTALL_CMAKE_PROJECTS
	      List  of	four values that specify what project to install.  The
	      four values are: Build directory,	Project	Name,  Project	Compo-
	      nent, Directory.	If omitted, CPack will build an	installer that
	      installs everything.

       CPACK_SYSTEM_NAME
	      System name, defaults to the value of CMAKE_SYSTEM_NAME,	except
	      on Windows where it will be win32	or win64.

       CPACK_PACKAGE_VERSION
	      Package  full  version,  used  internally.   By default, this is
	      built		from		  CPACK_PACKAGE_VERSION_MAJOR,
	      CPACK_PACKAGE_VERSION_MINOR, and CPACK_PACKAGE_VERSION_PATCH.

       CPACK_TOPLEVEL_TAG
	      Directory	for the	installed files.

       CPACK_INSTALL_COMMANDS
	      Extra  commands to install components.  The environment variable
	      CMAKE_INSTALL_PREFIX is set to the temporary  install  directory
	      during execution.

       CPACK_INSTALL_SCRIPTS
	      New in version 3.16.

	      Extra  CMake  scripts executed by	CPack during its local staging
	      installation.  They are executed before installing the files  to
	      be packaged.  The	scripts	are not	called by a standalone install
	      (e.g.: make install).  For every script, the following variables
	      will  be set: CMAKE_CURRENT_SOURCE_DIR, CMAKE_CURRENT_BINARY_DIR
	      and CMAKE_INSTALL_PREFIX (which is set to	 the  staging  install
	      directory).  The singular	form CMAKE_INSTALL_SCRIPT is supported
	      as an alternative	variable for historical	reasons, but its value
	      is ignored if CMAKE_INSTALL_SCRIPTS is set and a warning will be
	      issued.

	      See also	CPACK_PRE_BUILD_SCRIPTS	 and  CPACK_POST_BUILD_SCRIPTS
	      which can	be used	to specify scripts to be executed later	in the
	      packaging	process.

       CPACK_PRE_BUILD_SCRIPTS
	      New in version 3.19.

	      List of CMake scripts to execute after CPack has	installed  the
	      files to be packaged into	a staging directory and	before produc-
	      ing   the	  package(s)	from	those	 files.	   See	  also
	      CPACK_INSTALL_SCRIPTS and	CPACK_POST_BUILD_SCRIPTS.

       CPACK_POST_BUILD_SCRIPTS
	      New in version 3.19.

	      List  of	CMake  scripts to execute after	CPack has produced the
	      resultant	packages and before copying them back to the build di-
	      rectory.		See	    also	CPACK_INSTALL_SCRIPTS,
	      CPACK_PRE_BUILD_SCRIPTS and CPACK_PACKAGE_FILES.

       CPACK_PACKAGE_FILES
	      New in version 3.19.

	      List of package files created in	the  staging  directory,  with
	      each  file  provided  as a full absolute path.  This variable is
	      populated	by CPack just before invoking the  post-build  scripts
	      listed in	CPACK_POST_BUILD_SCRIPTS.  It is the preferred way for
	      the post-build scripts to	know the set of	package	files to oper-
	      ate  on.	 Projects  should  not	try to set this	variable them-
	      selves.

       CPACK_INSTALLED_DIRECTORIES
	      Extra directories	to install.

       CPACK_PACKAGE_INSTALL_REGISTRY_KEY
	      Registry key used	when installing	this project.	This  is  only
	      used  by	installers for Windows.	 The default value is based on
	      the installation directory.

       CPACK_CREATE_DESKTOP_LINKS
	      List of desktop links to create.	Each desktop link  requires  a
	      corresponding    start	menu	shortcut    as	  created   by
	      CPACK_PACKAGE_EXECUTABLES.

       CPACK_BINARY_<GENNAME>
	      CPack generated options for binary generators.  The  CPack.cmake
	      module  generates	 (when	CPACK_GENERATOR	 is  not set) a	set of
	      CMake options (see CMake option()	command)  which	 may  then  be
	      used  to	select the CPack generator(s) to be used when building
	      the package target or when running cpack without the -G option.

   CPackComponent
       Configure components for	binary installers and source packages.

   Introduction
       This module is automatically included by	CPack.

       Certain binary installers (especially the graphical installers)	gener-
       ated  by	 CPack allow users to select individual	application components
       to install.  This module	allows developers to configure	the  packaging
       of such components.

       Contents	is assigned to components by the COMPONENT argument of CMake's
       install() command.  Components  can  be	annotated  with	 user-friendly
       names and descriptions, inter-component dependencies, etc., and grouped
       in various ways to customize the	resulting installer,  using  the  com-
       mands described below.

       To  specify  different  groupings  for different	CPack generators use a
       CPACK_PROJECT_CONFIG_FILE.

   Variables
       The following variables influence the component-specific	packaging:

       CPACK_COMPONENTS_ALL
	      The list of component to install.

	      The default value	of this	variable is computed by	CPack and con-
	      tains  all  components defined by	the project.  The user may set
	      it to only include the specified components.

	      Instead of specifying all	the desired components,	it is possible
	      to  obtain  a list of all	defined	components and then remove the
	      unwanted ones from the list.  The	 get_cmake_property()  command
	      can be used to obtain the	COMPONENTS property, then the list(RE-
	      MOVE_ITEM) command can be	used to	remove the unwanted ones.  For
	      example, to use all defined components except foo	and bar:

		 get_cmake_property(CPACK_COMPONENTS_ALL COMPONENTS)
		 list(REMOVE_ITEM CPACK_COMPONENTS_ALL "foo" "bar")

       CPACK_<GENNAME>_COMPONENT_INSTALL
	      Enable/Disable component install for CPack generator <GENNAME>.

	      Each  CPack Generator (RPM, DEB, ARCHIVE,	NSIS, DMG, etc...) has
	      a	legacy default behavior.  e.g.	RPM builds monolithic  whereas
	      NSIS  builds  component.	One can	change the default behavior by
	      setting this variable to 0/1 or OFF/ON.

       CPACK_COMPONENTS_GROUPING
	      Specify how components  are  grouped  for	 multi-package	compo-
	      nent-aware CPack generators.

	      Some generators like RPM or ARCHIVE (TGZ,	ZIP, ...) may generate
	      several packages files when there	are components,	 depending  on
	      the value	of this	variable:

	      o	ONE_PER_GROUP  (default):  create  one	package	 per component
		group

	      o	IGNORE : create	one package per	component (ignore the groups)

	      o	ALL_COMPONENTS_IN_ONE :	create a single	package	with  all  re-
		quested	components

       CPACK_COMPONENT_<compName>_DISPLAY_NAME
	      The name to be displayed for a component.

       CPACK_COMPONENT_<compName>_DESCRIPTION
	      The description of a component.

       CPACK_COMPONENT_<compName>_GROUP
	      The group	of a component.

       CPACK_COMPONENT_<compName>_DEPENDS
	      The  dependencies	 (list	of components) on which	this component
	      depends.

       CPACK_COMPONENT_<compName>_HIDDEN
	      True if this component is	hidden from the	user.

       CPACK_COMPONENT_<compName>_REQUIRED
	      True if this component is	required.

       CPACK_COMPONENT_<compName>_DISABLED
	      True if this component is	not selected to	be  installed  by  de-
	      fault.

   Commands
   Add component
       cpack_add_component

       Describe	an installation	component.

	  cpack_add_component(compname
			      [DISPLAY_NAME name]
			      [DESCRIPTION description]
			      [HIDDEN |	REQUIRED | DISABLED ]
			      [GROUP group]
			      [DEPENDS comp1 comp2 ... ]
			      [INSTALL_TYPES type1 type2 ... ]
			      [DOWNLOADED]
			      [ARCHIVE_FILE filename]
			      [PLIST filename])

       compname	 is  the  name of an installation component, as	defined	by the
       COMPONENT argument of one or more CMake install() commands.   With  the
       cpack_add_component  command  one  can  set  a name, a description, and
       other attributes	of an installation component.  One can also  assign  a
       component to a component	group.

       DISPLAY_NAME  is	the displayed name of the component, used in graphical
       installers to display the  component  name.   This  value  can  be  any
       string.

       DESCRIPTION is an extended description of the component,	used in	graph-
       ical installers to give the user	additional information about the  com-
       ponent.	Descriptions can span multiple lines using \n as the line sep-
       arator.	Typically, these descriptions should be	no  more  than	a  few
       lines long.

       HIDDEN  indicates  that	this component will be hidden in the graphical
       installer, so that the user cannot directly change whether  it  is  in-
       stalled or not.

       REQUIRED	 indicates that	this component is required, and	therefore will
       always be installed.  It	will be	visible	in  the	 graphical  installer,
       but it cannot be	unselected.  (Typically, required components are shown
       greyed out).

       DISABLED	indicates that this component should be	disabled  (unselected)
       by  default.   The  user	is free	to select this component for installa-
       tion, unless it is also HIDDEN.

       DEPENDS lists the components on which this component depends.  If  this
       component  is selected, then each of the	components listed must also be
       selected.  The dependency information is	encoded	within	the  installer
       itself, so that users cannot install inconsistent sets of components.

       GROUP  names the	component group	of which this component	is a part.  If
       not provided, the component will	be a standalone	component, not part of
       any   component	 group.	  Component  groups  are  described  with  the
       cpack_add_component_group command, detailed below.

       INSTALL_TYPES lists the installation types of which this	component is a
       part.   When  one of these installations	types is selected, this	compo-
       nent will automatically be selected.  Installation types	are  described
       with the	cpack_add_install_type command,	detailed below.

       DOWNLOADED   indicates	that   this  component	should	be  downloaded
       on-the-fly by the installer, rather than	packaged in with the installer
       itself.	 For  more information,	see the	cpack_configure_downloads com-
       mand.

       ARCHIVE_FILE provides a name for	the archive file created by  CPack  to
       be  used	for downloaded components.  If not supplied, CPack will	create
       a file with some	name based on CPACK_PACKAGE_FILE_NAME and the name  of
       the component.  See cpack_configure_downloads for more information.

       PLIST  gives  a	filename  that is passed to pkgbuild with the --compo-
       nent-plist argument when	using the productbuild generator.

   Add component group
       cpack_add_component_group

       Describes a group of related CPack installation components.

	  cpack_add_component_group(groupname
				   [DISPLAY_NAME name]
				   [DESCRIPTION	description]
				   [PARENT_GROUP parent]
				   [EXPANDED]
				   [BOLD_TITLE])

       The cpack_add_component_group describes a group of installation	compo-
       nents,  which  will  be	placed together	within the listing of options.
       Typically, component groups allow the user to  select/deselect  all  of
       the  components	within a single	group via a single group-level option.
       Use component groups to reduce the complexity of	installers  with  many
       options.	  groupname is an arbitrary name used to identify the group in
       the GROUP argument of the cpack_add_component command, which is used to
       place  a	component in a group.  The name	of the group must not conflict
       with the	name of	any component.

       DISPLAY_NAME is the displayed name of  the  component  group,  used  in
       graphical  installers  to display the component group name.  This value
       can be any string.

       DESCRIPTION is an extended description of the component group, used  in
       graphical  installers to	give the user additional information about the
       components within that group.  Descriptions can span multiple lines us-
       ing  \n as the line separator.  Typically, these	descriptions should be
       no more than a few lines	long.

       PARENT_GROUP, if	supplied, names	the parent group of this group.	  Par-
       ent  groups  are	 used to establish a hierarchy of groups, providing an
       arbitrary hierarchy of groups.

       EXPANDED	indicates that,	by default, the	group should show up  as  "ex-
       panded",	so that	the user immediately sees all of the components	within
       the group.  Otherwise, the group	will initially show up as a single en-
       try.

       BOLD_TITLE  indicates  that  the	 group title should appear in bold, to
       call the	user's attention to the	group.

   Add installation type
       cpack_add_install_type

       Add a new installation type containing a	set  of	 predefined  component
       selections to the graphical installer.

	  cpack_add_install_type(typename
				 [DISPLAY_NAME name])

       The cpack_add_install_type command identifies a set of preselected com-
       ponents that represents a common	use case for an	application.  For  ex-
       ample,  a  "Developer"  install type might include an application along
       with its	header and library files, while	an  "End  user"	 install  type
       might  just include the application's executable.  Each component iden-
       tifies itself with one or more install types via	the INSTALL_TYPES  ar-
       gument to cpack_add_component.

       DISPLAY_NAME is the displayed name of the install type, which will typ-
       ically show up in a drop-down box within	a graphical  installer.	  This
       value can be any	string.

   Configure downloads
       cpack_configure_downloads

       Configure  CPack	 to download selected components on-the-fly as part of
       the installation	process.

	  cpack_configure_downloads(site
				    [UPLOAD_DIRECTORY dirname]
				    [ALL]
				    [ADD_REMOVE|NO_ADD_REMOVE])

       The  cpack_configure_downloads  command	configures   installation-time
       downloads  of  selected	components.   For each downloadable component,
       CPack will create an archive containing the contents of that component,
       which should be uploaded	to the given site.  When the user selects that
       component for installation, the installer will download and extract the
       component in place.  This feature is useful for creating	small install-
       ers that	only download the requested components,	saving bandwidth.  Ad-
       ditionally, the installers are small enough that	they will be installed
       as part of the normal installation process, and the "Change" button  in
       Windows	Add/Remove Programs control panel will allow one to add	or re-
       move parts of the application after the original	installation.  On Win-
       dows,  the  downloaded-components  functionality	 requires  the	ZipDLL
       plug-in for NSIS, available at:

	  http://nsis.sourceforge.net/ZipDLL_plug-in

       On macOS, installers that download components on-the-fly	 can  only  be
       built and installed on system using macOS 10.5 or later.

       The  site  argument is a	URL where the archives for downloadable	compo-
       nents will reside, e.g.,	 https://cmake.org/files/2.6.1/installer/  All
       of the archives produced	by CPack should	be uploaded to that location.

       UPLOAD_DIRECTORY	 is  the  local	 directory where CPack will create the
       various archives	for each of the	components.  The contents of this  di-
       rectory should be uploaded to a location	accessible by the URL given in
       the site	argument.  If omitted, CPack will use  the  directory  CPackU-
       ploads  inside  the  CMake  binary directory to store the generated ar-
       chives.

       The ALL flag indicates that all components be  downloaded.   Otherwise,
       only  those  components	explicitly marked as DOWNLOADED	or that	have a
       specified ARCHIVE_FILE will be downloaded.  Additionally, the  ALL  op-
       tion implies ADD_REMOVE (unless NO_ADD_REMOVE is	specified).

       ADD_REMOVE  indicates that CPack	should install a copy of the installer
       that can	be called from Windows'	Add/Remove Programs  dialog  (via  the
       "Modify"	button)	to change the set of installed components.  NO_ADD_RE-
       MOVE turns off this behavior.  This option is ignored on	Mac OS X.

   CPackIFW
       New in version 3.1.

       This module looks for the location of the command-line  utilities  sup-
       plied with the Qt Installer Framework (QtIFW).

       The module also defines several commands	to control the behavior	of the
       CPack IFW Generator.

   Commands
       The module defines the following	commands:

       cpack_ifw_configure_component
	      Sets the arguments specific to the CPack IFW generator.

		 cpack_ifw_configure_component(<compname> [COMMON] [ESSENTIAL] [VIRTUAL]
				     [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
				     [NAME <name>]
				     [DISPLAY_NAME <display_name>] # Note: Internationalization	supported
				     [DESCRIPTION <description>] # Note: Internationalization supported
				     [UPDATE_TEXT <update_text>]
				     [VERSION <version>]
				     [RELEASE_DATE <release_date>]
				     [SCRIPT <script>]
				     [PRIORITY|SORTING_PRIORITY	<sorting_priority>] # Note: PRIORITY is	deprecated
				     [DEPENDS|DEPENDENCIES <com_id> ...]
				     [AUTO_DEPEND_ON <comp_id> ...]
				     [LICENSES <display_name> <file_path> ...]
				     [DEFAULT <value>]
				     [USER_INTERFACES <file_path> <file_path> ...]
				     [TRANSLATIONS <file_path> <file_path> ...]
				     [REPLACES <comp_id> ...]
				     [CHECKABLE	<value>])

	      This command should be called after  cpack_add_component()  com-
	      mand.

	      COMMON if	set, then the component	will be	packaged and installed
		     as	part of	a group	to which it belongs.

	      ESSENTIAL
		     New in version 3.6.

		     if	set, then the package  manager	stays  disabled	 until
		     that component is updated.

	      VIRTUAL
		     New in version 3.8.

		     if	 set,  then  the component will	be hidden from the in-
		     staller.  It is a equivalent of the  HIDDEN  option  from
		     the cpack_add_component() command.

	      FORCED_INSTALLATION
		     New in version 3.8.

		     if	 set, then the component must always be	installed.  It
		     is	 a  equivalent	of  the	 REQUIRED  option   from   the
		     cpack_add_component() command.

	      REQUIRES_ADMIN_RIGHTS
		     New in version 3.8.

		     set  it  if the component needs to	be installed with ele-
		     vated permissions.

	      NAME   is	used to	create	domain-like  identification  for  this
		     component.	 By default used origin	component name.

	      DISPLAY_NAME
		     New in version 3.8.

		     set to rewrite original name configured by	cpack_add_com-
		     ponent() command.

	      DESCRIPTION
		     New in version 3.8.

		     set  to  rewrite  original	 description   configured   by
		     cpack_add_component() command.

	      UPDATE_TEXT
		     New in version 3.8.

		     will  be added to the component description if this is an
		     update to the component.

	      VERSION
		     is	version	of component.	By  default  used  CPACK_PACK-
		     AGE_VERSION.

	      RELEASE_DATE
		     New in version 3.8.

		     keep empty	to auto	generate.

	      SCRIPT is	 a  relative or	absolute path to operations script for
		     this component.

	      SORTING_PRIORITY
		     New in version 3.8.

		     is	priority of the	component in the tree.

	      PRIORITY
		     Deprecated	since version 3.8: Old name for	SORTING_PRIOR-
		     ITY.

	      DEPENDS, DEPENDENCIES
		     New in version 3.8.

		     list  of  dependency component or component group identi-
		     fiers in QtIFW style.

	      AUTO_DEPEND_ON
		     New in version 3.8.

		     list of identifiers of component or  component  group  in
		     QtIFW  style  that	this component has an automatic	depen-
		     dency on.

	      LICENSES
		     pair of <display_name> and	<file_path>  of	 license  text
		     for  this	component.  You	 can specify more then one li-
		     cense.

	      DEFAULT
		     New in version 3.8.

		     Possible values are: TRUE,	FALSE,	and  SCRIPT.   Set  to
		     FALSE  to	disable	 the  component	in the installer or to
		     SCRIPT to resolved	during runtime (don't forget  add  the
		     file of the script	as a value of the SCRIPT option).

	      USER_INTERFACES
		     New in version 3.7.

		     is	a list of <file_path> ('.ui' files) representing pages
		     to	load.

	      TRANSLATIONS
		     New in version 3.8.

		     is	a  list	 of  <file_path>  ('.qm'  files)  representing
		     translations to load.

	      REPLACES
		     New in version 3.10.

		     list  of  identifiers  of component or component group to
		     replace.

	      CHECKABLE
		     New in version 3.10.

		     Possible values are: TRUE,	FALSE.	Set to	FALSE  if  you
		     want  to  hide  the checkbox for an item.	This is	useful
		     when only a few subcomponents should be selected  instead
		     of	all.

       cpack_ifw_configure_component_group
	      Sets the arguments specific to the CPack IFW generator.

		 cpack_ifw_configure_component_group(<groupname> [VIRTUAL]
				     [FORCED_INSTALLATION] [REQUIRES_ADMIN_RIGHTS]
				     [NAME <name>]
				     [DISPLAY_NAME <display_name>] # Note: Internationalization	supported
				     [DESCRIPTION <description>] # Note: Internationalization supported
				     [UPDATE_TEXT <update_text>]
				     [VERSION <version>]
				     [RELEASE_DATE <release_date>]
				     [SCRIPT <script>]
				     [PRIORITY|SORTING_PRIORITY	<sorting_priority>] # Note: PRIORITY is	deprecated
				     [DEPENDS|DEPENDENCIES <com_id> ...]
				     [AUTO_DEPEND_ON <comp_id> ...]
				     [LICENSES <display_name> <file_path> ...]
				     [DEFAULT <value>]
				     [USER_INTERFACES <file_path> <file_path> ...]
				     [TRANSLATIONS <file_path> <file_path> ...]
				     [REPLACES <comp_id> ...]
				     [CHECKABLE	<value>])

	      This  command should be called after cpack_add_component_group()
	      command.

	      VIRTUAL
		     New in version 3.8.

		     if	set, then the group will be hidden from	the installer.
		     Note that setting this on a root component	does not work.

	      FORCED_INSTALLATION
		     New in version 3.8.

		     if	set, then the group must always	be installed.

	      REQUIRES_ADMIN_RIGHTS
		     New in version 3.8.

		     set  it if	the component group needs to be	installed with
		     elevated permissions.

	      NAME   is	used to	create	domain-like  identification  for  this
		     component	group.	By default used	origin component group
		     name.

	      DISPLAY_NAME
		     New in version 3.8.

		     set to rewrite original name configured by	cpack_add_com-
		     ponent_group() command.

	      DESCRIPTION
		     New in version 3.8.

		     set   to	rewrite	 original  description	configured  by
		     cpack_add_component_group() command.

	      UPDATE_TEXT
		     New in version 3.8.

		     will be added to the component group description if  this
		     is	an update to the component group.

	      VERSION
		     is	  version   of	 component  group.   By	 default  used
		     CPACK_PACKAGE_VERSION.

	      RELEASE_DATE
		     New in version 3.8.

		     keep empty	to auto	generate.

	      SCRIPT is	a relative or absolute path to operations  script  for
		     this component group.

	      SORTING_PRIORITY
		     is	priority of the	component group	in the tree.

	      PRIORITY
		     Deprecated	since version 3.8: Old name for	SORTING_PRIOR-
		     ITY.

	      DEPENDS, DEPENDENCIES
		     New in version 3.8.

		     list of dependency	component or component	group  identi-
		     fiers in QtIFW style.

	      AUTO_DEPEND_ON
		     New in version 3.8.

		     list  of  identifiers  of component or component group in
		     QtIFW style that this component group  has	 an  automatic
		     dependency	on.

	      LICENSES
		     pair  of  <display_name>  and <file_path> of license text
		     for this component	group. You can specify more  then  one
		     license.

	      DEFAULT
		     New in version 3.8.

		     Possible  values  are:  TRUE,  FALSE, and SCRIPT.	Set to
		     TRUE to preselect the group in the	installer (this	 takes
		     effect  only  on groups that have no visible child	compo-
		     nents) or to SCRIPT to  resolved  during  runtime	(don't
		     forget  add  the  file  of	 the  script as	a value	of the
		     SCRIPT option).

	      USER_INTERFACES
		     New in version 3.7.

		     is	a list of <file_path> ('.ui' files) representing pages
		     to	load.

	      TRANSLATIONS
		     New in version 3.8.

		     is	 a  list  of  <file_path>  ('.qm'  files) representing
		     translations to load.

	      REPLACES
		     New in version 3.10.

		     list of identifiers of component or  component  group  to
		     replace.

	      CHECKABLE
		     New in version 3.10.

		     Possible  values  are:  TRUE, FALSE.  Set to FALSE	if you
		     want to hide the checkbox for an item.   This  is	useful
		     when  only	a few subcomponents should be selected instead
		     of	all.

       cpack_ifw_add_repository
	      Add QtIFW	specific remote	repository to binary installer.

		 cpack_ifw_add_repository(<reponame> [DISABLED]
				     URL <url>
				     [USERNAME <username>]
				     [PASSWORD <password>]
				     [DISPLAY_NAME <display_name>])

	      This command will	also add the <reponame>	repository to a	 vari-
	      able CPACK_IFW_REPOSITORIES_ALL.

	      DISABLED
		     if	set, then the repository will be disabled by default.

	      URL    is	points to a list of available components.

	      USERNAME
		     is	used as	user on	a protected repository.

	      PASSWORD
		     is	password to use	on a protected repository.

	      DISPLAY_NAME
		     is	string to display instead of the URL.

       cpack_ifw_update_repository
	      New in version 3.6.

	      Update QtIFW specific repository from remote repository.

		 cpack_ifw_update_repository(<reponame>
				     [[ADD|REMOVE] URL <url>]|
				      [REPLACE OLD_URL <old_url> NEW_URL <new_url>]]
				     [USERNAME <username>]
				     [PASSWORD <password>]
				     [DISPLAY_NAME <display_name>])

	      This  command will also add the <reponame> repository to a vari-
	      able CPACK_IFW_REPOSITORIES_ALL.

	      URL    is	points to a list of available components.

	      OLD_URL
		     is	points to a list that will replaced.

	      NEW_URL
		     is	points to a list that will replace to.

	      USERNAME
		     is	used as	user on	a protected repository.

	      PASSWORD
		     is	password to use	on a protected repository.

	      DISPLAY_NAME
		     is	string to display instead of the URL.

       cpack_ifw_add_package_resources
	      New in version 3.7.

	      Add additional resources in the installer	binary.

		 cpack_ifw_add_package_resources(<file_path> <file_path> ...)

	      This command will	also add the specified	files  to  a  variable
	      CPACK_IFW_PACKAGE_RESOURCES.

   CPackIFWConfigureFile
       New in version 3.8.

       The  module  defines configure_file() similar command to	configure file
       templates prepared in QtIFW/SDK/Creator style.

   Commands
       The module defines the following	commands:

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

		 cpack_ifw_configure_file(<input> <output>)

	      Copies an	<input>	file to	an <output> file and substitutes vari-
	      able values referenced as	%{VAR} or %VAR%	in the input file con-
	      tent.  Each variable reference will be replaced with the current
	      value  of	 the  variable,	or the empty string if the variable is
	      not defined.

   CSharpUtilities
       New in version 3.8.

       Functions to make configuration of CSharp/.NET targets easier.

       A collection of CMake utility functions useful for dealing with	CSharp
       targets for Visual Studio generators from version 2010 and later.

       The following functions are provided by this module:

       Main functions

       o csharp_set_windows_forms_properties()

       o csharp_set_designer_cs_properties()

       o csharp_set_xaml_cs_properties()

       Helper functions

       o csharp_get_filename_keys()

       o csharp_get_filename_key_base()

       o csharp_get_dependentupon_name()

   Main	functions provided by the module
       csharp_set_windows_forms_properties
	      Sets  source file	properties for use of Windows Forms. Use this,
	      if your CSharp target uses Windows Forms:

		 csharp_set_windows_forms_properties([<file1> [<file2> [...]]])

	      <fileN>
		     List of all source	files which are	relevant  for  setting
		     the  VS_CSHARP_<tagname> properties (including .cs, .resx
		     and .Designer.cs extensions).

	      In the list of all given files for all files  ending  with  .De-
	      signer.cs	and .resx is searched.	For every designer or resource
	      file a file with the same	base name but only .cs as extension is
	      searched.	  If this is found, the	VS_CSHARP_<tagname> properties
	      are set as follows:

	      for the .cs file:

		     o VS_CSHARP_SubType "Form"

	      for the .Designer.cs file	(if it exists):

		     o VS_CSHARP_DependentUpon <cs-filename>

		     o VS_CSHARP_DesignTime "" (delete tag if  previously  de-
		       fined)

		     o VS_CSHARP_AutoGen ""(delete tag if previously defined)

	      for the .resx file (if it	exists):

		     o VS_RESOURCE_GENERATOR  "" (delete tag if	previously de-
		       fined)

		     o VS_CSHARP_DependentUpon <cs-filename>

		     o VS_CSHARP_SubType "Designer"

       csharp_set_designer_cs_properties
	      Sets source file properties of .Designer.cs files	 depending  on
	      sibling  filenames. Use this, if your CSharp target does not use
	      Windows	   Forms      (for	 Windows       Forms	   use
	      csharp_set_designer_cs_properties() instead):

		 csharp_set_designer_cs_properties([<file1> [<file2> [...]]])

	      <fileN>
		     List  of  all source files	which are relevant for setting
		     the VS_CSHARP_<tagname> properties	(including .cs,	.resx,
		     .settings and .Designer.cs	extensions).

	      In  the  list  of	all given files	for all	files ending with .De-
	      signer.cs	is searched. For every designer	file  all  files  with
	      the  same	 base name but different extensions are	searched. If a
	      match is found, the source file properties of the	designer  file
	      are set depending	on the extension of the	matched	file:

	      if match is .resx	file:

		     o VS_CSHARP_AutoGen "True"

		     o VS_CSHARP_DesignTime "True"

		     o VS_CSHARP_DependentUpon <resx-filename>

	      if match is .cs file:

		     o VS_CSHARP_DependentUpon <cs-filename>

	      if match is .settings file:

		     o VS_CSHARP_AutoGen "True"

		     o VS_CSHARP_DesignTimeSharedInput "True"

		     o VS_CSHARP_DependentUpon <settings-filename>

       NOTE:
	  Because  the source file properties of the .Designer.cs file are set
	  according  to	 the  found  matches  and   every   match   sets   the
	  VS_CSHARP_DependentUpon property, there should only be one match for
	  each Designer.cs file.

       csharp_set_xaml_cs_properties
	      Sets source file properties  for	use  of	 Windows  Presentation
	      Foundation  (WPF)	and XAML. Use this, if your CSharp target uses
	      WPF/XAML:

		 csharp_set_xaml_cs_properties([<file1>	[<file2> [...]]])

	      <fileN>
		     List of all source	files which are	relevant  for  setting
		     the VS_CSHARP_<tagname> properties	(including .cs,	.xaml,
		     and .xaml.cs extensions).

	      In the list of  all  given  files	 for  all  files  ending  with
	      .xaml.cs	is  searched.  For every xaml-cs file, a file with the
	      same base	name but extension .xaml is searched.  If a  match  is
	      found, the source	file properties	of the .xaml.cs	file are set:

		 o VS_CSHARP_DependentUpon <xaml-filename>

   Helper functions which are used by the above	ones
       csharp_get_filename_keys
	      Helper  function which computes a	list of	key values to identify
	      source files independently of relative/absolute paths  given  in
	      cmake and	eliminates case	sensitivity:

		 csharp_get_filename_keys(OUT [<file1> [<file2>	[...]]])

	      OUT    Name of the variable in which the list of keys is stored

	      <fileN>
		     filename(s)  as  given  to	to CSharp target using add_li-
		     brary() or	add_executable()

	      In some way the  function	 applies  a  canonicalization  to  the
	      source  names.   This  is	 necessary to find file	matches	if the
	      files have been added to the  target  with  different  directory
	      prefixes:

		 add_library(lib
		   myfile.cs
		   ${CMAKE_CURRENT_SOURCE_DIR}/myfile.Designer.cs)

		 set_source_files_properties(myfile.Designer.cs	PROPERTIES
		   VS_CSHARP_DependentUpon myfile.cs)

		 # this	will fail, because in cmake
		 #  - ${CMAKE_CURRENT_SOURCE_DIR}/myfile.Designer.cs
		 #  - myfile.Designer.cs
		 # are not the same source file. The source file property is not set.

       csharp_get_filename_key_base
	      Returns  the  full filepath and name without extension of	a key.
	      KEY is expected to be a key  from	 csharp_get_filename_keys.  In
	      BASE the value of	KEY without the	file extension is returned:

		 csharp_get_filename_key_base(BASE KEY)

	      BASE   Name of the variable with the computed "base" of KEY.

	      KEY    The  key  of which	the base will be computed. Expected to
		     be	a upper	case full filename.

       csharp_get_dependentupon_name
	      Computes a string	which can be used as value for the source file
	      property VS_CSHARP_<tagname> with	target being DependentUpon:

		 csharp_get_dependentupon_name(NAME FILE)

	      NAME   Name of the variable with the result value

	      FILE   Filename to convert to <DependentUpon> value

	      Actually this is only the	filename without any path given	at the
	      moment.

   CTest
       Configure a project for testing with CTest/CDash

       Include this module in the top CMakeLists.txt file of a project to  en-
       able testing with CTest and dashboard submissions to CDash:

	  project(MyProject)
	  ...
	  include(CTest)

       The  module  automatically  creates a BUILD_TESTING option that selects
       whether to enable testing support (ON by	default).  After including the
       module, use code	like:

	  if(BUILD_TESTING)
	    # ... CMake	code to	create tests ...
	  endif()

       to creating tests when testing is enabled.

       To  enable  submissions	to  a CDash server, create a CTestConfig.cmake
       file at the top of the project with content such	as:

	  set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC")
	  set(CTEST_SUBMIT_URL "http://my.cdash.org/submit.php?project=MyProject")

       (the CDash server can provide the file to a project  administrator  who
       configures  MyProject).	Settings in the	config file are	shared by both
       this CTest module and the ctest(1) command-line Dashboard  Client  mode
       (ctest -S).

       While building a	project	for submission to CDash, CTest scans the build
       output for errors and warnings and reports them with  surrounding  con-
       text  from  the	build  log.  This generic approach works for all build
       tools, but does not give	details	about the command invocation that pro-
       duced  a	 given	problem.  One may get more detailed reports by setting
       the CTEST_USE_LAUNCHERS variable:

	  set(CTEST_USE_LAUNCHERS 1)

       in the CTestConfig.cmake	file.

   CTestCoverageCollectGCOV
       New in version 3.2.

       This module provides the	ctest_coverage_collect_gcov function.

       This function runs gcov on all .gcda files found	in the binary tree and
       packages	 the resulting .gcov files into	a tar file.  This tarball also
       contains	the following:

       o data.json defines the source and build	directories for	use by CDash.

       o Labels.json indicates any LABELS that have been  set  on  the	source
	 files.

       o The  uncovered	directory holds	any uncovered files found by CTEST_EX-
	 TRA_COVERAGE_GLOB.

       After generating	this tar file, it can be sent  to  CDash  for  display
       with the	ctest_submit(CDASH_UPLOAD) command.

       ctest_coverage_collect_gcov

		 ctest_coverage_collect_gcov(TARBALL <tarfile>
		   [SOURCE <source_dir>][BUILD <build_dir>]
		   [GCOV_COMMAND <gcov_command>]
		   [GCOV_OPTIONS <options>...]
		   )

	      Run gcov and package a tar file for CDash.  The options are:

	      TARBALL <tarfile>
		     Specify  the  location of the .tar	file to	be created for
		     later upload to CDash.  Relative  paths  will  be	inter-
		     preted with respect to the	top-level build	directory.

	      TARBALL_COMPRESSION <option>
		     New in version 3.18.

		     Specify  a	 compression  algorithm	 for  the TARBALL data
		     file.  Using this option reduces the  size	 of  the  data
		     file  before  it is submitted to CDash.  <option> must be
		     one of GZIP, BZIP2, XZ, ZSTD, FROM_EXT, or	an  expression
		     that  CMake  evaluates  as	 FALSE.	 The  default value is
		     BZIP2.

		     If	FROM_EXT is specified, the resulting file will be com-
		     pressed  based  on	 the  file  extension of the <tarfile>
		     (i.e. .tar.gz will	use GZIP compression). File extensions
		     that  will	 produce  compressed  output  include .tar.gz,
		     .tgz, .tar.bzip2, .tbz, .tar.xz, and .txz.

	      SOURCE <source_dir>
		     Specify the top-level source  directory  for  the	build.
		     Default is	the value of CTEST_SOURCE_DIRECTORY.

	      BUILD <build_dir>
		     Specify the top-level build directory for the build.  De-
		     fault is the value	of CTEST_BINARY_DIRECTORY.

	      GCOV_COMMAND <gcov_command>
		     Specify the full path to the gcov command on the machine.
		     Default is	the value of CTEST_COVERAGE_COMMAND.

	      GCOV_OPTIONS <options>...
		     Specify  options  to be passed to gcov.  The gcov command
		     is	run as gcov <options>...  -o  <gcov-dir>  <file>.gcda.
		     If	not specified, the default option is just -b -x.

	      GLOB   New in version 3.6.

		     Recursively  search  for  .gcda files in build_dir	rather
		     than determining search locations by reading TargetDirec-
		     tories.txt.

	      DELETE New in version 3.6.

		     Delete  coverage  files  after they've been packaged into
		     the .tar.

	      QUIET  Suppress non-error	messages  that	otherwise  would  have
		     been printed out by this function.

	      New  in  version	3.3: Added support for the CTEST_CUSTOM_COVER-
	      AGE_EXCLUDE variable.

   CTestScriptMode
       This file is read by ctest in script mode (-S)

   CTestUseLaunchers
       Set the RULE_LAUNCH_* global properties when CTEST_USE_LAUNCHERS	is on.

       CTestUseLaunchers is automatically included  when  you  include(CTest).
       However,	 it  is	split out into its own module file so projects can use
       the CTEST_USE_LAUNCHERS functionality independently.

       To use launchers, set CTEST_USE_LAUNCHERS to ON in a ctest -S dashboard
       script,	and  then  also	set it in the cache of the configured project.
       Both cmake and ctest need to know the value of it for the launchers  to
       work  properly.	 CMake needs to	know in	order to generate proper build
       rules, and ctest, in order to produce  the  proper  error  and  warning
       analysis.

       For  convenience,  you may set the ENV variable CTEST_USE_LAUNCHERS_DE-
       FAULT in	your ctest -S script, too.  Then, as long as  your  CMakeLists
       uses  include(CTest)  or	 include(CTestUseLaunchers),  it  will use the
       value of	the ENV	variable to  initialize	 a  CTEST_USE_LAUNCHERS	 cache
       variable.    This   cache   variable   initialization  only  occurs  if
       CTEST_USE_LAUNCHERS is not already defined.

       New in version 3.8: If CTEST_USE_LAUNCHERS is on	in a ctest  -S	script
       the ctest_configure command will	add -DCTEST_USE_LAUNCHERS:BOOL=TRUE to
       the cmake command used to configure the project.

   Dart
       Configure a project for testing with CTest or old Dart Tcl Client

       This file is the	backwards-compatibility	version	of the	CTest  module.
       It  supports using the old Dart 1 Tcl client for	driving	dashboard sub-
       missions	as well	as testing with	CTest.	This module should be included
       in the CMakeLists.txt file at the top of	a project.  Typical usage:

	  include(Dart)
	  if(BUILD_TESTING)
	    # ... testing related CMake	code ...
	  endif()

       The  BUILD_TESTING  option  is  created by the Dart module to determine
       whether testing support should be enabled.  The default is ON.

   DeployQt4
       Functions to help assemble a standalone Qt4 executable.

       A collection of CMake utility functions useful for deploying  Qt4  exe-
       cutables.

       The following functions are provided by this module:

	  write_qt4_conf
	  resolve_qt4_paths
	  fixup_qt4_executable
	  install_qt4_plugin_path
	  install_qt4_plugin
	  install_qt4_executable

       Requires	 CMake	2.6  or	 greater  because  it  uses  function and PAR-
       ENT_SCOPE.  Also	depends	on BundleUtilities.cmake.

	  write_qt4_conf(<qt_conf_dir> <qt_conf_contents>)

       Writes a	qt.conf	file with the <qt_conf_contents> into <qt_conf_dir>.

	  resolve_qt4_paths(<paths_var>	[<executable_path>])

       Loop through <paths_var>	list and if any	don't exist resolve them rela-
       tive  to	 the <executable_path> (if supplied) or	the CMAKE_INSTALL_PRE-
       FIX.

	  fixup_qt4_executable(<executable>
	    [<qtplugins> <libs>	<dirs> <plugins_dir> <request_qt_conf>])

       Copies Qt plugins, writes a Qt configuration file (if needed) and fixes
       up  a  Qt4 executable using BundleUtilities so it is standalone and can
       be drag-and-drop	copied to another machine as long as all of the	system
       libraries are compatible.

       <executable> should point to the	executable to be fixed-up.

       <qtplugins> should contain a list of the	names or paths of any Qt plug-
       ins to be installed.

       <libs> will be passed to	BundleUtilities	and should be a	 list  of  any
       already	 installed  plugins,  libraries	 or  executables  to  also  be
       fixed-up.

       <dirs> will be passed to	BundleUtilities	and should contain and	direc-
       tories to be searched to	find library dependencies.

       <plugins_dir> allows an custom plugins directory	to be used.

       <request_qt_conf>  will	force a	qt.conf	file to	be written even	if not
       needed.

	  install_qt4_plugin_path(plugin executable copy installed_plugin_path_var
				  <plugins_dir>	<component> <configurations>)

       Install (or copy) a resolved <plugin> to	the default plugins  directory
       (or  <plugins_dir>)  relative  to  <executable> and store the result in
       <installed_plugin_path_var>.

       If <copy> is set	to TRUE	then the plugins will be  copied  rather  than
       installed.   This  is  to  allow	 this  module to be used at CMake time
       rather than install time.

       If <component> is set then anything installed will use this COMPONENT.

	  install_qt4_plugin(plugin executable copy installed_plugin_path_var
			     <plugins_dir> <component>)

       Install (or copy) an unresolved <plugin>	to the default plugins	direc-
       tory  (or  <plugins_dir>) relative to <executable> and store the	result
       in   <installed_plugin_path_var>.     See    documentation    of	   IN-
       STALL_QT4_PLUGIN_PATH.

	  install_qt4_executable(<executable>
	    [<qtplugins> <libs>	<dirs> <plugins_dir> <request_qt_conf> <component>])

       Installs	 Qt  plugins,  writes  a Qt configuration file (if needed) and
       fixes up	a Qt4 executable using BundleUtilities so it is	standalone and
       can  be	drag-and-drop  copied to another machine as long as all	of the
       system libraries	are compatible.	 The executable	will  be  fixed-up  at
       install	time.	<component> is the COMPONENT used for bundle fixup and
       plugin installation.  See documentation of FIXUP_QT4_BUNDLE.

   ExternalData
       Manage data files stored	outside	source tree

   Introduction
       Use this	module to unambiguously	reference data	files  stored  outside
       the  source  tree and fetch them	at build time from arbitrary local and
       remote content-addressed	locations.  Functions provided by this	module
       recognize  arguments  with the syntax DATA{<name>} as references	to ex-
       ternal data, replace them with full paths  to  local  copies  of	 those
       data, and create	build rules to fetch and update	the local copies.

       For example:

	  include(ExternalData)
	  set(ExternalData_URL_TEMPLATES "file:///local/%(algo)/%(hash)"
					 "file:////host/share/%(algo)/%(hash)"
					 "http://data.org/%(algo)/%(hash)")
	  ExternalData_Add_Test(MyData
	    NAME MyTest
	    COMMAND MyExe DATA{MyInput.png}
	    )
	  ExternalData_Add_Target(MyData)

       When  test  MyTest runs the DATA{MyInput.png} argument will be replaced
       by the full path	to a real instance of the  data	 file  MyInput.png  on
       disk.   If  the	source	tree  contains	a  content  link such as MyIn-
       put.png.md5 then	the MyData target creates a real  MyInput.png  in  the
       build tree.

   Module Functions
       ExternalData_Expand_Arguments
	      The ExternalData_Expand_Arguments	function evaluates DATA{} ref-
	      erences in its arguments and constructs a	new list of arguments:

		 ExternalData_Expand_Arguments(
		   <target>   #	Name of	data management	target
		   <outVar>   #	Output variable
		   [args...]  #	Input arguments, DATA{}	allowed
		   )

	      It replaces each DATA{} reference	in an argument with  the  full
	      path of a	real data file on disk that will exist after the <tar-
	      get> builds.

       ExternalData_Add_Test
	      The  ExternalData_Add_Test  function  wraps  around  the	 CMake
	      add_test()  command  but supports	DATA{} references in its argu-
	      ments:

		 ExternalData_Add_Test(
		   <target>   #	Name of	data management	target
		   ...	      #	Arguments of add_test(), DATA{}	allowed
		   )

	      It passes	its  arguments	through	 ExternalData_Expand_Arguments
	      and then invokes the add_test() command using the	results.

       ExternalData_Add_Target
	      The  ExternalData_Add_Target function creates a custom target to
	      manage local instances of	data files stored externally:

		 ExternalData_Add_Target(
		   <target>		     # Name of data management target
		   [SHOW_PROGRESS <ON|OFF>]  # Show progress during the	download
		   )

	      It creates custom	commands in the	target as  necessary  to  make
	      data files available for each DATA{} reference previously	evalu-
	      ated by other functions provided by this module.	Data files may
	      be fetched from one of the URL templates specified in the	Exter-
	      nalData_URL_TEMPLATES variable, or may be	found locally  in  one
	      of  the  paths specified in the ExternalData_OBJECT_STORES vari-
	      able.

	      New in version 3.20: The SHOW_PROGRESS argument may be passed to
	      suppress progress	information during the download	of objects. If
	      not provided, it defaults	to OFF for Ninja and Ninja  Multi-Con-
	      fig generators and ON otherwise.

	      Typically	 only one target is needed to manage all external data
	      within a project.	 Call this function once at the	end of config-
	      uration after all	data references	have been processed.

   Module Variables
       The  following variables	configure behavior.  They should be set	before
       calling any of the functions provided by	this module.

       ExternalData_BINARY_ROOT
	      The ExternalData_BINARY_ROOT variable may	be set to  the	direc-
	      tory to hold the real data files named by	expanded DATA{}	refer-
	      ences.  The default is CMAKE_BINARY_DIR.	The  directory	layout
	      will    mirror   that   of   content   links   under   External-
	      Data_SOURCE_ROOT.

       ExternalData_CUSTOM_SCRIPT_<key>
	      New in version 3.2.

	      Specify a	full path to a .cmake custom fetch  script  identified
	      by <key> in entries of the ExternalData_URL_TEMPLATES list.  See
	      Custom Fetch Scripts.

       ExternalData_LINK_CONTENT
	      The ExternalData_LINK_CONTENT variable may be set	to the name of
	      a	 supported  hash  algorithm  to	enable automatic conversion of
	      real data	files referenced by the	 DATA{}	 syntax	 into  content
	      links.  For each such <file> a content link named	<file><ext> is
	      created.	The original file is renamed to	 the  form  .External-
	      Data_<algo>_<hash> to stage it for future	transmission to	one of
	      the locations in the list	of URL templates (by means outside the
	      scope of this module).  The data fetch rule created for the con-
	      tent link	will use the staged object if it cannot	be found using
	      any URL template.

       ExternalData_NO_SYMLINKS
	      New in version 3.3.

	      The  real	 data files named by expanded DATA{} references	may be
	      made available  under  ExternalData_BINARY_ROOT  using  symbolic
	      links  on	some platforms.	 The ExternalData_NO_SYMLINKS variable
	      may be set to disable use	of symbolic links and  enable  use  of
	      copies instead.

       ExternalData_OBJECT_STORES
	      The  ExternalData_OBJECT_STORES variable may be set to a list of
	      local  directories  that	store	objects	  using	  the	layout
	      <dir>/%(algo)/%(hash).  These directories	will be	searched first
	      for a needed object.  If the object  is  not  available  in  any
	      store  then  it will be fetched remotely using the URL templates
	      and added	to the first local store listed.   If  no  stores  are
	      specified	the default is a location inside the build tree.

       ExternalData_SERIES_PARSE

       ExternalData_SERIES_PARSE_PREFIX

       ExternalData_SERIES_PARSE_NUMBER

       ExternalData_SERIES_PARSE_SUFFIX

       ExternalData_SERIES_MATCH
	      See Referencing File Series.

       ExternalData_SOURCE_ROOT
	      The  ExternalData_SOURCE_ROOT variable may be set	to the highest
	      source directory containing any path named by  a	DATA{}	refer-
	      ence.	The    default	  is	CMAKE_SOURCE_DIR.    External-
	      Data_SOURCE_ROOT and CMAKE_SOURCE_DIR must refer to  directories
	      within a single source distribution (e.g.	 they come together in
	      one tarball).

       ExternalData_TIMEOUT_ABSOLUTE
	      The ExternalData_TIMEOUT_ABSOLUTE	variable sets the download ab-
	      solute  timeout, in seconds, with	a default of 300 seconds.  Set
	      to 0 to disable enforcement.

       ExternalData_TIMEOUT_INACTIVITY
	      The ExternalData_TIMEOUT_INACTIVITY variable sets	 the  download
	      inactivity  timeout,  in	seconds, with a	default	of 60 seconds.
	      Set to 0 to disable enforcement.

       ExternalData_URL_ALGO_<algo>_<key>
	      New in version 3.3.

	      Specify a	custom URL component to	be substituted	for  URL  tem-
	      plate  placeholders  of the form %(algo:<key>), where <key> is a
	      valid C identifier, when fetching	an object referenced via  hash
	      algorithm	 <algo>.  If not defined, the default URL component is
	      just <algo> for any <key>.

       ExternalData_URL_TEMPLATES
	      The ExternalData_URL_TEMPLATES may be set	to provide a  list  of
	      URL templates using the placeholders %(algo) and %(hash) in each
	      template.	 Data fetch rules try each URL template	 in  order  by
	      substituting  the	 hash  algorithm name for %(algo) and the hash
	      value for	%(hash).  Alternatively	one may	use %(algo:<key>) with
	      ExternalData_URL_ALGO_<algo>_<key> variables to gain more	flexi-
	      bility in	remote URLs.

   Referencing Files
   Referencing Single Files
       The DATA{} syntax is literal and	the <name> is a	full or	relative  path
       within  the  source  tree.   The	source tree must contain either	a real
       data file at <name> or a	"content link"	at  <name><ext>	 containing  a
       hash  of	 the  real file	using a	hash algorithm corresponding to	<ext>.
       For example, the	argument DATA{img.png} may be satisfied	 by  either  a
       real img.png file in the	current	source directory or a img.png.md5 file
       containing its MD5 sum.

       New in version 3.8: Multiple content links of the same name  with  dif-
       ferent	hash   algorithms   are	 supported  (e.g.  img.png.sha256  and
       img.png.sha1) so	long as	they all correspond to	the  same  real	 file.
       This  allows  objects  to  be fetched from sources indexed by different
       hash algorithms.

   Referencing File Series
       The DATA{} syntax can be	told to	fetch a	file  series  using  the  form
       DATA{<name>,:},	where the : is literal.	 If the	source tree contains a
       group of	files or content links named like a series then	a reference to
       one  member adds	rules to fetch all of them.  Although all members of a
       series are fetched, only	the file originally named by the DATA{}	 argu-
       ment  is	substituted for	it.  The default configuration recognizes file
       series names ending with	#.ext, _#.ext, .#.ext, or -#.ext where # is  a
       sequence	of decimal digits and .ext is any single extension.  Configure
       it with a regex that parses <number> and	<suffix> parts from the	end of
       <name>:

	  ExternalData_SERIES_PARSE = regex of the form	(<number>)(<suffix>)$

       For more	complicated cases set:

	  ExternalData_SERIES_PARSE = regex with at least two () groups
	  ExternalData_SERIES_PARSE_PREFIX = <prefix> regex group number, if any
	  ExternalData_SERIES_PARSE_NUMBER = <number> regex group number
	  ExternalData_SERIES_PARSE_SUFFIX = <suffix> regex group number

       Configure series	number matching	with a regex that matches the <number>
       part of series members named <prefix><number><suffix>:

	  ExternalData_SERIES_MATCH = regex matching <number> in all series members

       Note that the <suffix> of a series does not  include  a	hash-algorithm
       extension.

   Referencing Associated Files
       The  DATA{}  syntax  can	 alternatively match files associated with the
       named file and contained	in the same directory.	Associated  files  may
       be	specified      by      options	    using      the	syntax
       DATA{<name>,<opt1>,<opt2>,...}.	Each option may	specify	 one  file  by
       name or specify a regular expression to match file names	using the syn-
       tax REGEX:<regex>.  For example,	the arguments:

	  DATA{MyData/MyInput.mhd,MyInput.img}			 # File	pair
	  DATA{MyData/MyFrames00.png,REGEX:MyFrames[0-9]+\\.png} # Series

       will pass MyInput.mha and MyFrames00.png	on the command line but	ensure
       that the	associated files are present next to them.

   Referencing Directories
       The  DATA{} syntax may reference	a directory using a trailing slash and
       a list of associated files.  The	 form  DATA{<name>/,<opt1>,<opt2>,...}
       adds  rules  to	fetch any files	in the directory that match one	of the
       associated  file	 options.   For	  example,   the   argument   DATA{My-
       DataDir/,REGEX:.*}  will	pass the full path to a	MyDataDir directory on
       the command line	and ensure that	the directory  contains	 files	corre-
       sponding	 to  every file	or content link	in the MyDataDir source	direc-
       tory.

       New in version 3.3: In order to match associated	files  in  subdirecto-
       ries,	specify	   a   RECURSE:	  option,   e.g.   DATA{MyDataDir/,RE-
       CURSE:,REGEX:.*}.

   Hash	Algorithms
       The following hash algorithms are supported:

	  %(algo)     <ext>	Description
	  -------     -----	-----------
	  MD5	      .md5	Message-Digest Algorithm 5, RFC	1321
	  SHA1	      .sha1	US Secure Hash Algorithm 1, RFC	3174
	  SHA224      .sha224	US Secure Hash Algorithms, RFC 4634
	  SHA256      .sha256	US Secure Hash Algorithms, RFC 4634
	  SHA384      .sha384	US Secure Hash Algorithms, RFC 4634
	  SHA512      .sha512	US Secure Hash Algorithms, RFC 4634
	  SHA3_224    .sha3-224	Keccak SHA-3
	  SHA3_256    .sha3-256	Keccak SHA-3
	  SHA3_384    .sha3-384	Keccak SHA-3
	  SHA3_512    .sha3-512	Keccak SHA-3

       New in version 3.8: Added the SHA3_* hash algorithms.

       Note that the hashes are	used only for unique data  identification  and
       download	verification.

   Custom Fetch	Scripts
       New in version 3.2.

       When  a	data file must be fetched from one of the URL templates	speci-
       fied in the ExternalData_URL_TEMPLATES variable,	it is  normally	 down-
       loaded  using  the  file(DOWNLOAD) command.  One	may specify usage of a
       custom fetch script by using a URL template of the  form	 ExternalData-
       CustomScript://<key>/<loc>.   The <key> must be a C identifier, and the
       <loc> must contain the %(algo) and %(hash)  placeholders.   A  variable
       corresponding to	the key, ExternalData_CUSTOM_SCRIPT_<key>, must	be set
       to the full path	to a .cmake script file.  The script will be  included
       to perform the actual fetch, and	provided with the following variables:

       ExternalData_CUSTOM_LOCATION
	      When  a  custom  fetch script is loaded, this variable is	set to
	      the location part	of the URL, which will contain the substituted
	      hash algorithm name and content hash value.

       ExternalData_CUSTOM_FILE
	      When  a  custom  fetch script is loaded, this variable is	set to
	      the full path to a file in  which	 the  script  must  store  the
	      fetched content.	The name of the	file is	unspecified and	should
	      not be interpreted in any	way.

       The custom fetch	script is expected to store  fetched  content  in  the
       file or set a variable:

       ExternalData_CUSTOM_ERROR
	      When a custom fetch script fails to fetch	the requested content,
	      it must set this variable	to a short one-line message describing
	      the reason for failure.

   ExternalProject
   Commands
   External Project Definition
       ExternalProject_Add
	      The  ExternalProject_Add()  function  creates a custom target to
	      drive download, update/patch, configure, build, install and test
	      steps of an external project:

		 ExternalProject_Add(<name> [<option>...])

	      The  individual  steps within the	process	can be driven indepen-
	      dently if	required (e.g. for CDash submission) and extra	custom
	      steps can	be defined, along with the ability to control the step
	      dependencies. The	directory structure used for the management of
	      the  external  project can also be customized. The function sup-
	      ports a large number of options which can	be used	to tailor  the
	      external project behavior.

	      Directory	Options:
		     Most  of the time,	the default directory layout is	suffi-
		     cient. It is largely an implementation  detail  that  the
		     main project usually doesn't need to change. In some cir-
		     cumstances, however, control over	the  directory	layout
		     can be useful or necessary. The directory options are po-
		     tentially more useful from	the point  of  view  that  the
		     main  build  can  use  the	ExternalProject_Get_Property()
		     command to	retrieve their values,	thereby	 allowing  the
		     main  project to refer to build artifacts of the external
		     project.

		     PREFIX <dir>
			    Root directory for the  external  project.	Unless
			    otherwise noted below, all other directories asso-
			    ciated with	the external project will  be  created
			    under here.

		     TMP_DIR <dir>
			    Directory in which to store	temporary files.

		     STAMP_DIR <dir>
			    Directory in which to store	the timestamps of each
			    step. Log files from  individual  steps  are  also
			    created  in	here unless overridden by LOG_DIR (see
			    Logging Options below).

		     LOG_DIR <dir>
			    New	in version 3.14.

			    Directory in which to store	the logs of each step.

		     DOWNLOAD_DIR <dir>
			    Directory in which to store	downloaded  files  be-
			    fore  unpacking  them. This	directory is only used
			    by the URL download	 method,  all  other  download
			    methods use	SOURCE_DIR directly instead.

		     SOURCE_DIR	<dir>
			    Source  directory  into  which downloaded contents
			    will be unpacked, or for non-URL download methods,
			    the	 directory  in	which the repository should be
			    checked out, cloned, etc. If no download method is
			    specified,	this  must point to an existing	direc-
			    tory where the external project has	 already  been
			    unpacked or	cloned/checked out.

			    NOTE:
			       If a download method is specified, any existing
			       contents	 of  the  source  directory   may   be
			       deleted.	 Only  the  URL	download method	checks
			       whether this directory  is  either  missing  or
			       empty  before initiating	the download, stopping
			       with an error if	it is  not  empty.  All	 other
			       download	 methods silently discard any previous
			       contents	of the source directory.

		     BINARY_DIR	<dir>
			    Specify the	build directory	location. This	option
			    is ignored if BUILD_IN_SOURCE is enabled.

		     INSTALL_DIR <dir>
			    Installation  prefix  to  be  placed  in  the <IN-
			    STALL_DIR> placeholder.  This  does	 not  actually
			    configure  the  external project to	install	to the
			    given prefix. That must be done by passing	appro-
			    priate  arguments to the external project configu-
			    ration step, e.g. using <INSTALL_DIR>.

		     If	any of the above ..._DIR options  are  not  specified,
		     their defaults are	computed as follows. If	the PREFIX op-
		     tion is given or the EP_PREFIX directory property is set,
		     then an external project is built and installed under the
		     specified prefix:

			TMP_DIR	     = <prefix>/tmp
			STAMP_DIR    = <prefix>/src/<name>-stamp
			DOWNLOAD_DIR = <prefix>/src
			SOURCE_DIR   = <prefix>/src/<name>
			BINARY_DIR   = <prefix>/src/<name>-build
			INSTALL_DIR  = <prefix>
			LOG_DIR	     = <STAMP_DIR>

		     Otherwise,	if the EP_BASE directory property is set  then
		     components	 of  an	 external project are stored under the
		     specified base:

			TMP_DIR	     = <base>/tmp/<name>
			STAMP_DIR    = <base>/Stamp/<name>
			DOWNLOAD_DIR = <base>/Download/<name>
			SOURCE_DIR   = <base>/Source/<name>
			BINARY_DIR   = <base>/Build/<name>
			INSTALL_DIR  = <base>/Install/<name>
			LOG_DIR	     = <STAMP_DIR>

		     If	no PREFIX, EP_PREFIX, or EP_BASE  is  specified,  then
		     the  default  is to set PREFIX to <name>-prefix. Relative
		     paths are interpreted with	respect	 to  CMAKE_CURRENT_BI-
		     NARY_DIR  at  the	point  where  ExternalProject_Add() is
		     called.

	      Download Step Options:
		     A download	method can be omitted if the SOURCE_DIR	option
		     is	used to	point to an existing non-empty directory. Oth-
		     erwise, one of the	download methods below must be	speci-
		     fied (multiple download methods should not	be given) or a
		     custom DOWNLOAD_COMMAND provided.

		     DOWNLOAD_COMMAND <cmd>...
			    Overrides the command used for the	download  step
			    (generator expressions are supported). If this op-
			    tion is specified, all other download options will
			    be	ignored.  Providing  an	empty string for <cmd>
			    effectively	disables the download step.

		     URL Download

			    URL	<url1> [<url2>...]
				   List	of paths and/or	URL(s) of the external
				   project's source. When more than one	URL is
				   given, they are tried  in  turn  until  one
				   succeeds.  A	URL may	be an ordinary path in
				   the local file system  (in  which  case  it
				   must	be the only URL	provided) or any down-
				   loadable URL	supported  by  the  file(DOWN-
				   LOAD)  command. A local filesystem path may
				   refer to either an existing directory or to
				   an  archive file, whereas a URL is expected
				   to point to a file which can	be treated  as
				   an  archive.	 When  an  archive is used, it
				   will	be unpacked automatically  unless  the
				   DOWNLOAD_NO_EXTRACT	option	is set to pre-
				   vent	it. The	archive	type is	determined  by
				   inspecting  the  actual content rather than
				   using logic based on	the file extension.

				   Changed in version 3.7: Multiple  URLs  are
				   allowed.

			    URL_HASH <algo>=<hashValue>
				   Hash	 of the	archive	file to	be downloaded.
				   The	argument  should  be   of   the	  form
				   <algo>=<hashValue> where algo can be	any of
				   the hashing	algorithms  supported  by  the
				   file()  command.  Specifying	this option is
				   strongly recommended	for URL	downloads,  as
				   it  ensures the integrity of	the downloaded
				   content. It is also used as a check	for  a
				   previously  downloaded  file, allowing con-
				   nection  to	the  remote  location  to   be
				   avoided  altogether	if the local directory
				   already has a file from an earlier download
				   that	matches	the specified hash.

			    URL_MD5 <md5>
				   Equivalent to URL_HASH MD5=<md5>.

			    DOWNLOAD_NAME <fname>
				   File	 name  to use for the downloaded file.
				   If not given, the end of the	URL is used to
				   determine  the  file	 name.	This option is
				   rarely needed, the default name  is	gener-
				   ally	suitable and is	not normally used out-
				   side	of code	internal to  the  ExternalPro-
				   ject	module.

			    DOWNLOAD_NO_EXTRACT	<bool>
				   New in version 3.6.

				   Allows  the extraction part of the download
				   step	to be disabled by  passing  a  boolean
				   true	 value for this	option.	If this	option
				   is not given, the downloaded	contents  will
				   be  unpacked	 automatically if required. If
				   extraction has been disabled, the full path
				   to  the  downloaded	file  is  available as
				   <DOWNLOADED_FILE> in	subsequent steps or as
				   the	 property   DOWNLOADED_FILE  with  the
				   ExternalProject_Get_Property() command.

			    DOWNLOAD_NO_PROGRESS <bool>
				   Can be used to disable logging the download
				   progress.  If  this	option	is  not	given,
				   download progress messages will be logged.

			    TIMEOUT <seconds>
				   Maximum time	allowed	for file download  op-
				   erations.

			    INACTIVITY_TIMEOUT <seconds>
				   New in version 3.19.

				   Terminate  the  operation after a period of
				   inactivity.

			    HTTP_USERNAME <username>
				   New in version 3.7.

				   Username for	the download operation if  au-
				   thentication	is required.

			    HTTP_PASSWORD <password>
				   New in version 3.7.

				   Password  for the download operation	if au-
				   thentication	is required.

			    HTTP_HEADER	<header1> [<header2>...]
				   New in version 3.7.

				   Provides an arbitrary list of HTTP  headers
				   for	the  download  operation.  This	can be
				   useful for  accessing  content  in  systems
				   like	AWS, etc.

			    TLS_VERIFY <bool>
				   Specifies  whether certificate verification
				   should be performed for https URLs. If this
				   option  is not provided, the	default	behav-
				   ior is determined by	 the  CMAKE_TLS_VERIFY
				   variable  (see  file(DOWNLOAD)). If that is
				   also	not set, certificate verification will
				   not	 be  performed.	 In  situations	 where
				   URL_HASH cannot be  provided,  this	option
				   can be an alternative verification measure.

				   Changed  in	version	 3.6: This option also
				   applies to git clone	invocations.

			    TLS_CAINFO <file>
				   Specify a custom certificate	authority file
				   to  use  if	TLS_VERIFY is enabled. If this
				   option is not specified, the	value  of  the
				   CMAKE_TLS_CAINFO  variable will be used in-
				   stead (see file(DOWNLOAD))

			    NETRC <level>
				   New in version 3.11.

				   Specify whether the .netrc file  is	to  be
				   used	 for operation.	 If this option	is not
				   specified, the  value  of  the  CMAKE_NETRC
				   variable   will   be	  used	 instead  (see
				   file(DOWNLOAD)) Valid levels	are:

				   IGNORED
					  The .netrc file is ignored.  This is
					  the default.

				   OPTIONAL
					  The .netrc file is optional, and in-
					  formation in the URL	is  preferred.
					  The  file  will  be  scanned to find
					  which	ever information is not	speci-
					  fied in the URL.

				   REQUIRED
					  The .netrc file is required, and in-
					  formation in the URL is ignored.

			    NETRC_FILE <file>
				   New in version 3.11.

				   Specify an alternative .netrc file  to  the
				   one	in  your  home	directory if the NETRC
				   level is OPTIONAL or	REQUIRED. If this  op-
				   tion	 is  not  specified,  the value	of the
				   CMAKE_NETRC_FILE variable will be used  in-
				   stead (see file(DOWNLOAD))

			    New	 in  version  3.1:  Added  support  for	 tbz2,
			    .tar.xz, .txz, and .7z extensions.

		     Git    NOTE: A git	version	of 1.6.5 or later is  required
			    if this download method is used.

			    GIT_REPOSITORY <url>
				   URL	of  the	git repository.	Any URL	under-
				   stood by the	git command may	be used.

			    GIT_TAG <tag>
				   Git branch name, tag	or commit  hash.  Note
				   that	branch names and tags should generally
				   be specified	as  remote  names  (i.e.  ori-
				   gin/myBranch	 rather	than simply myBranch).
				   This	ensures	that if	the remote end has its
				   tag	moved  or  branch  rebased  or history
				   rewritten, the local	clone  will  still  be
				   updated  correctly.	In  general,  however,
				   specifying a	commit	hash  should  be  pre-
				   ferred for a	number of reasons:

				   o If	the local clone	already	has the	commit
				     corresponding to the hash,	no  git	 fetch
				     needs   to	 be  performed	to  check  for
				     changes each time CMake is	 re-run.  This
				     can  result  in a significant speed up if
				     many external projects are	being used.

				   o Using a specific git  hash	 ensures  that
				     the  main	project's own history is fully
				     traceable to a specific point in the  ex-
				     ternal  project's	evolution. If a	branch
				     or	tag name is used instead, then	check-
				     ing  out  a  specific  commit of the main
				     project doesn't necessarily pin the whole
				     build  to a specific point	in the life of
				     the external project.  The	lack  of  such
				     deterministic  behavior  makes  the  main
				     project lose traceability and repeatabil-
				     ity.

				   If  GIT_SHALLOW  is	enabled	 then  GIT_TAG
				   works only with branch names	and  tags.   A
				   commit hash is not allowed.

			    GIT_REMOTE_NAME <name>
				   The	optional  name	of the remote. If this
				   option is not  specified,  it  defaults  to
				   origin.

			    GIT_SUBMODULES <module>...
				   Specific git	submodules that	should also be
				   updated. If this option  is	not  provided,
				   all git submodules will be updated.

				   Changed  in	version	 3.16: When CMP0097 is
				   set to NEW, if this	value  is  set	to  an
				   empty  string  then	no submodules are ini-
				   tialized or updated.

			    GIT_SUBMODULES_RECURSE <bool>
				   New in version 3.17.

				   Specify whether  git	 submodules  (if  any)
				   should  update  recursively	by passing the
				   --recursive flag to git  submodule  update.
				   If not specified, the default is on.

			    GIT_SHALLOW	<bool>
				   New in version 3.6.

				   When	 this option is	enabled, the git clone
				   operation will be given the --depth	1  op-
				   tion.  This performs	a shallow clone, which
				   avoids downloading the  whole  history  and
				   instead  retrieves  just the	commit denoted
				   by the GIT_TAG option.

			    GIT_PROGRESS <bool>
				   New in version 3.8.

				   When	enabled, this option instructs the git
				   clone  operation  to	report its progress by
				   passing it the --progress  option.  Without
				   this	 option,  the  clone  step  for	 large
				   projects  may  appear  to  make  the	 build
				   stall,  since  nothing will be logged until
				   the clone operation	finishes.  While  this
				   option  can	be used	to provide progress to
				   prevent the appearance of the build	having
				   stalled,  it	may also make the build	overly
				   noisy if  lots  of  external	 projects  are
				   used.

			    GIT_CONFIG <option1> [<option2>...]
				   New in version 3.8.

				   Specify a list of config options to pass to
				   git	clone.	Each  option  listed  will  be
				   transformed	into its own --config <option>
				   on the git clone command  line,  with  each
				   option   required   to   be	 in  the  form
				   key=value.

			    GIT_REMOTE_UPDATE_STRATEGY <strategy>
				   New in version 3.18.

				   When	GIT_TAG	refers	to  a  remote  branch,
				   this	 option	can be used to specify how the
				   update step behaves.	 The  <strategy>  must
				   be one of the following:

				   CHECKOUT
					  Ignore  the  local branch and	always
					  checkout  the	 branch	 specified  by
					  GIT_TAG.

				   REBASE Try  to rebase the current branch to
					  the one specified  by	 GIT_TAG.   If
					  there	are local uncommitted changes,
					  they	will  be  stashed  first   and
					  popped again after rebasing.	If re-
					  basing or  popping  stashed  changes
					  fail,	abort the rebase and halt with
					  an   error.	 When	GIT_REMOTE_UP-
					  DATE_STRATEGY	 is  not present, this
					  is the default strategy  unless  the
					  default  has	been  overridden  with
					  CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY
					  (see below).

				   REBASE_CHECKOUT
					  Same	as REBASE except if the	rebase
					  fails, an annotated tag will be cre-
					  ated	at  the	original HEAD position
					  from	before	the  rebase  and  then
					  checkout   GIT_TAG   just  like  the
					  CHECKOUT  strategy.	 The   message
					  stored  on  the  annotated  tag will
					  give information about what was  at-
					  tempted  and	the  tag name will in-
					  clude	 a  timestamp  so  that	  each
					  failed run will add a	new tag.  This
					  strategy ensures no changes will  be
					  lost,	but updates should always suc-
					  ceed if GIT_TAG refers  to  a	 valid
					  ref  unless  there  are  uncommitted
					  changes that cannot be  popped  suc-
					  cessfully.

				   The	   variable    CMAKE_EP_GIT_REMOTE_UP-
				   DATE_STRATEGY can be	set  to	 override  the
				   default strategy.  This variable should not
				   be set by a project,	it is intended for the
				   user	 to set.  It is	primarily intended for
				   use in continuous  integration  scripts  to
				   ensure  that	when history is	rewritten on a
				   remote branch, the  build  doesn't  end  up
				   with	 unintended  changes  or failed	builds
				   resulting from conflicts during rebase  op-
				   erations.

		     Subversion

			    SVN_REPOSITORY <url>
				   URL of the Subversion repository.

			    SVN_REVISION -r<rev>
				   Revision  to	 checkout  from	the Subversion
				   repository.

			    SVN_USERNAME <username>
				   Username for	the  Subversion	 checkout  and
				   update.

			    SVN_PASSWORD <password>
				   Password  for  the  Subversion checkout and
				   update.

			    SVN_TRUST_CERT <bool>
				   Specifies whether to	trust  the  Subversion
				   server  site	 certificate.  If enabled, the
				   --trust-server-cert option is passed	to the
				   svn checkout	and update commands.

		     Mercurial

			    HG_REPOSITORY <url>
				   URL of the mercurial	repository.

			    HG_TAG <tag>
				   Mercurial branch name, tag or commit	id.

		     CVS

			    CVS_REPOSITORY <cvsroot>
				   CVSROOT of the CVS repository.

			    CVS_MODULE <mod>
				   Module to checkout from the CVS repository.

			    CVS_TAG <tag>
				   Tag to checkout from	the CVS	repository.

	      Update/Patch Step	Options:
		     Whenever	CMake  is  re-run,  by	default	 the  external
		     project's sources will be updated if the download	method
		     supports  updates (e.g. a git repository would be checked
		     if	the GIT_TAG does not refer to a	specific commit).

		     UPDATE_COMMAND <cmd>...
			    Overrides the download method's update step	with a
			    custom command.  The command may use generator ex-
			    pressions.

		     UPDATE_DISCONNECTED <bool>
			    New	in version 3.2.

			    When enabled, this option causes the  update  step
			    to	be  skipped. It	does not, however, prevent the
			    download step. The update step can still be	 added
			    as	       a	step	    target	  (see
			    ExternalProject_Add_StepTargets()) and called man-
			    ually.  This is useful if you want to allow	devel-
			    opers to build the project when disconnected  from
			    the	 network  (the network may still be needed for
			    the	download step though).

			    When this option is	present, it is	generally  ad-
			    visable  to	 make the value	a cache	variable under
			    the	developer's control  rather  than  hard-coding
			    it.	 If  this  option  is not present, the default
			    value is taken from	the EP_UPDATE_DISCONNECTED di-
			    rectory property. If that is also not defined, up-
			    dates are performed	as normal. The	EP_UPDATE_DIS-
			    CONNECTED directory	property is intended as	a con-
			    venience for controlling  the  UPDATE_DISCONNECTED
			    behavior  for an entire section of a project's di-
			    rectory hierarchy and may  be  a  more  convenient
			    method  of	giving developers control over whether
			    or not to perform updates  (assuming  the  project
			    also  provides a cache variable or some other con-
			    venient method for	setting	 the  directory	 prop-
			    erty).

			    This  may  cause a step target to be created auto-
			    matically  for  the	 download  step.   See	policy
			    CMP0114.

		     PATCH_COMMAND <cmd>...
			    Specifies  a  custom  command to patch the sources
			    after an update. By	default, no patch  command  is
			    defined.  Note  that  it can be quite difficult to
			    define an appropriate patch	command	that  performs
			    robustly,  especially for download methods such as
			    git	where changing the GIT_TAG  will  not  discard
			    changes  from a previous patch, but	the patch com-
			    mand will be called	again after  updating  to  the
			    new	tag.

	      Configure	Step Options:
		     The  configure  step is run after the download and	update
		     steps. By default,	the external project is	assumed	to  be
		     a CMake project, but this can be overridden if required.

		     CONFIGURE_COMMAND <cmd>...
			    The	 default configure command runs	CMake with op-
			    tions based	on the main project. For non-CMake ex-
			    ternal projects, the CONFIGURE_COMMAND option must
			    be used to override	this behavior  (generator  ex-
			    pressions  are  supported).	 For projects that re-
			    quire no configure step, specify this option  with
			    an empty string as the command to execute.

		     CMAKE_COMMAND /.../cmake
			    Specify  an	 alternative  cmake executable for the
			    configure step (use	an  absolute  path).  This  is
			    generally not recommended, since it	is usually de-
			    sirable to use the same CMake  version  throughout
			    the	 whole build. This option is ignored if	a cus-
			    tom	configure command has been specified with CON-
			    FIGURE_COMMAND.

		     CMAKE_GENERATOR <gen>
			    Override  the CMake	generator used for the config-
			    ure	step. Without this option, the same  generator
			    as the main	build will be used. This option	is ig-
			    nored if a custom configure	command	has been spec-
			    ified with the CONFIGURE_COMMAND option.

		     CMAKE_GENERATOR_PLATFORM <platform>
			    New	in version 3.1.

			    Pass  a  generator-specific	 platform  name	to the
			    CMake command (see	CMAKE_GENERATOR_PLATFORM).  It
			    is	an  error  to  provide this option without the
			    CMAKE_GENERATOR option.

		     CMAKE_GENERATOR_TOOLSET <toolset>
			    Pass a  generator-specific	toolset	 name  to  the
			    CMake command (see CMAKE_GENERATOR_TOOLSET). It is
			    an	error  to  provide  this  option  without  the
			    CMAKE_GENERATOR option.

		     CMAKE_GENERATOR_INSTANCE <instance>
			    New	in version 3.11.

			    Pass  a  generator-specific	 instance selection to
			    the	CMake command (see  CMAKE_GENERATOR_INSTANCE).
			    It	is an error to provide this option without the
			    CMAKE_GENERATOR option.

		     CMAKE_ARGS	<arg>...
			    The	specified arguments are	passed	to  the	 cmake
			    command  line.  They can be	any argument the cmake
			    command understands, not just cache	values defined
			    by -D... arguments (see also CMake Options).

			    New	 in  version  3.3: Arguments may use generator
			    expressions.

		     CMAKE_CACHE_ARGS <arg>...
			    This is an alternate way of	specifying cache vari-
			    ables  where command line length issues may	become
			    a problem. The arguments are expected to be	in the
			    form  -Dvar:STRING=value,  which  are  then	trans-
			    formed into	CMake set() commands  with  the	 FORCE
			    option used. These set() commands are written to a
			    pre-load script which is then  applied  using  the
			    cmake -C command line option.

			    New	 in  version  3.3: Arguments may use generator
			    expressions.

		     CMAKE_CACHE_DEFAULT_ARGS <arg>...
			    New	in version 3.2.

			    This is the	same as	 the  CMAKE_CACHE_ARGS	option
			    except the set() commands do not include the FORCE
			    keyword. This means	the values act as initial  de-
			    faults  only  and  will not	override any variables
			    already set	from a previous	run. Use  this	option
			    with  care,	 as  it	can lead to different behavior
			    depending on whether the build starts from a fresh
			    build  directory  or  re-uses  previous build con-
			    tents.

			    New	in version 3.15: If the	CMake generator	is the
			    Green  Hills  MULTI	 and  not  overridden then the
			    original project's settings	for  the  GHS  toolset
			    and	 target	 system	 customization cache variables
			    are	propagated into	the external project.

		     SOURCE_SUBDIR <dir>
			    New	in version 3.7.

			    When no CONFIGURE_COMMAND option is	specified, the
			    configure  step assumes the	external project has a
			    CMakeLists.txt file	at the top of its source  tree
			    (i.e. in SOURCE_DIR). The SOURCE_SUBDIR option can
			    be used  to	 point	to  an	alternative  directory
			    within  the	 source	 tree to use as	the top	of the
			    CMake source tree instead. This must be a relative
			    path  and it will be interpreted as	being relative
			    to SOURCE_DIR.

			    New	in version 3.14: When  BUILD_IN_SOURCE	option
			    is	enabled, the BUILD_COMMAND is used to point to
			    an alternative directory within the	source tree.

		     CONFIGURE_HANDLED_BY_BUILD	<bool>
			    New	in version 3.20.

			    Enabling this option relaxes the  dependencies  of
			    the	 configure  step on other external projects to
			    order-only.	This means the configure step will  be
			    executed  after  its external project dependencies
			    are	built but it will not be marked	dirty when one
			    of	its  external project dependencies is rebuilt.
			    This option	can be enabled when the	build step  is
			    smart  enough  to figure out if the	configure step
			    needs to be	rerun. CMake and Meson are examples of
			    build  systems whose build step is smart enough to
			    know if the	configure step needs to	be rerun.

	      Build Step Options:
		     If	the configure step assumed the external	 project  uses
		     CMake as its build	system,	the build step will also. Oth-
		     erwise, the build step will assume	a Makefile-based build
		     and  simply  run  make  with  no arguments	as the default
		     build step. This can be overridden	with custom build com-
		     mands if required.

		     BUILD_COMMAND <cmd>...
			    Overrides the default build	command	(generator ex-
			    pressions are supported). If this  option  is  not
			    given, the default build command will be chosen to
			    integrate with the main build in the  most	appro-
			    priate way (e.g. using recursive make for Makefile
			    generators or cmake	--build	if the project uses  a
			    CMake build). This option can be specified with an
			    empty string as the	command	to make	the build step
			    do nothing.

		     BUILD_IN_SOURCE <bool>
			    When  this	option	is  enabled, the build will be
			    done directly within the external project's	source
			    tree. This should generally	be avoided, the	use of
			    a separate build directory is  usually  preferred,
			    but	it can be useful when the external project as-
			    sumes an in-source build.  The  BINARY_DIR	option
			    should not be specified if building	in-source.

		     BUILD_ALWAYS <bool>
			    Enabling  this option forces the build step	to al-
			    ways be run. This can be the easiest  way  to  ro-
			    bustly  ensure  that  the  external	 project's own
			    build dependencies are evaluated rather than rely-
			    ing	on the default success timestamp-based method.
			    This option	is not normally	needed unless develop-
			    ers	 are expected to modify	something the external
			    project's build depends on in a way	 that  is  not
			    detectable	via the	step target dependencies (e.g.
			    SOURCE_DIR is used without a download  method  and
			    developers	  might	   modify   the	  sources   in
			    SOURCE_DIR).

		     BUILD_BYPRODUCTS <file>...
			    New	in version 3.2.

			    Specifies files that  will	be  generated  by  the
			    build  command  but	 which might or	might not have
			    their  modification	 time  updated	by  subsequent
			    builds.  These  ultimately	get  passed through as
			    BYPRODUCTS to the build step's own underlying call
			    to add_custom_command().

	      Install Step Options:
		     If	 the  configure	step assumed the external project uses
		     CMake as its build	system,	the install  step  will	 also.
		     Otherwise,	 the install step will assume a	Makefile-based
		     build and simply run make install as  the	default	 build
		     step. This	can be overridden with custom install commands
		     if	required.

		     INSTALL_COMMAND <cmd>...
			    The	external project's own install step is invoked
			    as	part  of  the main project's build. It is done
			    after the external project's build step and	may be
			    before  or	after the external project's test step
			    (see the TEST_BEFORE_INSTALL  option  below).  The
			    external  project's	 install rules are not part of
			    the	main project's install rules, so  if  anything
			    from  the  external	project	should be installed as
			    part of the	main build, these need to be specified
			    in	the  main  build  as additional	install() com-
			    mands. The default install step builds the install
			    target  of	the  external project, but this	can be
			    overridden with a custom command using this	option
			    (generator	expressions are	supported). Passing an
			    empty string as the	<cmd> makes the	 install  step
			    do nothing.

	      Test Step	Options:
		     The test step is only defined if at least one of the fol-
		     lowing TEST_...  options are provided.

		     TEST_COMMAND <cmd>...
			    Overrides the default test command (generator  ex-
			    pressions  are  supported).	 If this option	is not
			    given, the default behavior	of the test step is to
			    build the external project's own test target. This
			    option can be specified with  <cmd>	 as  an	 empty
			    string, which allows the test step to still	be de-
			    fined, but it will do nothing. Do not specify  any
			    of	the  other  TEST_...  options  if providing an
			    empty string as the	test command,  but  prefer  to
			    omit  all  TEST_...	options	altogether if the test
			    step target	is not needed.

		     TEST_BEFORE_INSTALL <bool>
			    When this option is	enabled, the test step will be
			    executed  before the install step. The default be-
			    havior is for the test step	to run after  the  in-
			    stall step.

		     TEST_AFTER_INSTALL	<bool>
			    This  option is mainly useful as a way to indicate
			    that the test step is desired but all default  be-
			    havior  is sufficient. Specifying this option with
			    a boolean true value ensures the test step is  de-
			    fined and that it comes after the install step. If
			    both  TEST_BEFORE_INSTALL  and  TEST_AFTER_INSTALL
			    are	enabled, the latter is silently	ignored.

		     TEST_EXCLUDE_FROM_MAIN <bool>
			    New	in version 3.2.

			    If	enabled,  the  main build's default ALL	target
			    will not depend on the test	step. This  can	 be  a
			    useful  way	 of  ensuring the test step is defined
			    but	only gets  invoked  when  manually  requested.
			    This  may  cause a step target to be created auto-
			    matically for either the install  or  build	 step.
			    See	policy CMP0114.

	      Output Logging Options:
		     Each of the following LOG_... options can be used to wrap
		     the relevant step in a script to capture  its  output  to
		     files.  The  log files will be created in LOG_DIR if sup-
		     plied or otherwise	the STAMP_DIR directory	with step-spe-
		     cific file	names.

		     LOG_DOWNLOAD <bool>
			    When  enabled,  the	output of the download step is
			    logged to files.

		     LOG_UPDATE	<bool>
			    When enabled, the output of	 the  update  step  is
			    logged to files.

		     LOG_PATCH <bool>
			    New	in version 3.14.

			    When  enabled,  the	 output	 of  the patch step is
			    logged to files.

		     LOG_CONFIGURE <bool>
			    When enabled, the output of	the configure step  is
			    logged to files.

		     LOG_BUILD <bool>
			    When  enabled,  the	 output	 of  the build step is
			    logged to files.

		     LOG_INSTALL <bool>
			    When enabled, the output of	the  install  step  is
			    logged to files.

		     LOG_TEST <bool>
			    When  enabled,  the	 output	 of  the  test step is
			    logged to files.

		     LOG_MERGED_STDOUTERR <bool>
			    New	in version 3.14.

			    When enabled, stdout and stderr will be merged for
			    any	step whose output is being logged to files.

		     LOG_OUTPUT_ON_FAILURE <bool>
			    New	in version 3.14.

			    This  option only has an effect if at least	one of
			    the	other LOG_<step> options is  enabled.	If  an
			    error  occurs for a	step which has logging to file
			    enabled, that step's output	will be	printed	to the
			    console  if	 LOG_OUTPUT_ON_FAILURE is set to true.
			    For	cases  where  a	 large	amount	of  output  is
			    recorded,  just  the  end  of  that	 output	may be
			    printed to the console.

	      Terminal Access Options:
		     New in version 3.4.

		     Steps can be given	direct access to the terminal in  some
		     cases.  Giving a step access to the terminal may allow it
		     to	receive	terminal input if required, such  as  for  au-
		     thentication details not provided by other	options.  With
		     the Ninja generator, these	options	place the steps	in the
		     console  job  pool.  Each step can	be given access	to the
		     terminal individually via the following options:

		     USES_TERMINAL_DOWNLOAD <bool>
			    Give the download step access to the terminal.

		     USES_TERMINAL_UPDATE <bool>
			    Give the update step access	to the terminal.

		     USES_TERMINAL_CONFIGURE <bool>
			    Give the configure step access to the terminal.

		     USES_TERMINAL_BUILD <bool>
			    Give the build step	access to the terminal.

		     USES_TERMINAL_INSTALL <bool>
			    Give the install step access to the	terminal.

		     USES_TERMINAL_TEST	<bool>
			    Give the test step access to the terminal.

	      Target Options:

		     DEPENDS <targets>...
			    Specify  other  targets  on	 which	the   external
			    project depends. The other targets will be brought
			    up to date before any of  the  external  project's
			    steps  are	executed. Because the external project
			    uses additional custom targets internally for each
			    step,  the	DEPENDS	 option	is the most convenient
			    way	to ensure all of those	steps  depend  on  the
			    other   targets.	Simply	 doing	 add_dependen-
			    cies(<name>	<targets>) will	not make  any  of  the
			    steps dependent on <targets>.

		     EXCLUDE_FROM_ALL <bool>
			    When  enabled,  this  option excludes the external
			    project from the default ALL target	 of  the  main
			    build.

		     STEP_TARGETS <step-target>...
			    Generate  custom  targets for the specified	steps.
			    This is required if	the steps need to be triggered
			    manually  or  if they need to be used as dependen-
			    cies of other targets. If this option is not spec-
			    ified,   the  default  value  is  taken  from  the
			    EP_STEP_TARGETS    directory    property.	   See
			    ExternalProject_Add_StepTargets()  below  for fur-
			    ther discussion of the effects of this option.

		     INDEPENDENT_STEP_TARGETS <step-target>...
			    Deprecated since version  3.19:  This  is  allowed
			    only if policy CMP0114 is not set to NEW.

			    Generates  custom  targets for the specified steps
			    and	prevent	these targets from  having  the	 usual
			    dependencies  applied  to  them. If	this option is
			    not	specified, the default value is	taken from the
			    EP_INDEPENDENT_STEP_TARGETS	  directory  property.
			    This option	is mostly useful for allowing individ-
			    ual	 steps to be driven independently, such	as for
			    a CDash setup where	each step should be  initiated
			    and	reported individually rather than as one whole
			    build. See ExternalProject_Add_StepTargets() below
			    for	 further discussion of the effects of this op-
			    tion.

	      Miscellaneous Options:

		     LIST_SEPARATOR <sep>
			    For	any of the various  ..._COMMAND	 options,  re-
			    place ; with <sep> in the specified	command	lines.
			    This can be	useful where  list  variables  may  be
			    given  in  commands	 where	they  should end up as
			    space-separated arguments (<sep> would be a	single
			    space character string in this case).

		     COMMAND <cmd>...
			    Any	 of the	other ..._COMMAND options can have ad-
			    ditional commands appended to  them	 by  following
			    them  with	as  many COMMAND ... options as	needed
			    (generator expressions are supported).  For	 exam-
			    ple:

			       ExternalProject_Add(example
				 ... # Download	options, etc.
				 BUILD_COMMAND ${CMAKE_COMMAND}	-E echo	"Starting $<CONFIG> build"
				 COMMAND       ${CMAKE_COMMAND}	--build	<BINARY_DIR> --config $<CONFIG>
				 COMMAND       ${CMAKE_COMMAND}	-E echo	"$<CONFIG> build complete"
			       )

	      It  should  also	be noted that each build step is created via a
	      call to ExternalProject_Add_Step(). See that command's  documen-
	      tation  for  the	automatic substitutions	that are supported for
	      some options.

   Obtaining Project Properties
       ExternalProject_Get_Property
	      The ExternalProject_Get_Property() function  retrieves  external
	      project target properties:

		 ExternalProject_Get_Property(<name> <prop1> [<prop2>...])

	      The  function  stores  property  values in variables of the same
	      name. Property names correspond to the keyword argument names of
	      ExternalProject_Add().   For example, the	source directory might
	      be retrieved like	so:

		 ExternalProject_Get_property(myExtProj	SOURCE_DIR)
		 message("Source dir of	myExtProj = ${SOURCE_DIR}")

   Explicit Step Management
       The ExternalProject_Add() function on its own is	often  sufficient  for
       incorporating  an external project into the main	build. Certain scenar-
       ios require additional work to  implement  desired  behavior,  such  as
       adding  in a custom step	or making steps	available as manually trigger-
       able targets. The ExternalProject_Add_Step(), ExternalProject_Add_Step-
       Targets()  and  ExternalProject_Add_StepDependencies  functions provide
       the lower level control needed to implement such	 step-level  capabili-
       ties.

       ExternalProject_Add_Step
	      The  ExternalProject_Add_Step() function specifies an additional
	      custom step for an external project defined by an	 earlier  call
	      to ExternalProject_Add():

		 ExternalProject_Add_Step(<name> <step>	[<option>...])

	      <name>  is  the  same as the name	passed to the original call to
	      ExternalProject_Add(). The specified <step> must not be  one  of
	      the  pre-defined	steps (mkdir, download,	update,	patch, config-
	      ure, build, install or test). The	supported options are:

	      COMMAND <cmd>...
		     The command line to be executed by	this custom step (gen-
		     erator expressions	are supported).	This option can	be re-
		     peated multiple times to specify multiple commands	to  be
		     executed in order.

	      COMMENT <text>...
		     Text to be	printed	when the custom	step executes.

	      DEPENDEES	<step>...
		     Other  steps  (custom  or pre-defined) on which this step
		     depends.

	      DEPENDERS	<step>...
		     Other steps (custom or pre-defined) that depend  on  this
		     new custom	step.

	      DEPENDS <file>...
		     Files on which this custom	step depends.

	      INDEPENDENT <bool>
		     New in version 3.19.

		     Specifies	whether	this step is independent of the	exter-
		     nal dependencies specified	by the ExternalProject_Add()'s
		     DEPENDS  option.	The default is FALSE.  Steps marked as
		     independent may depend only on other steps	 marked	 inde-
		     pendent.  See policy CMP0114.

		     Note  that	this use of the	term "independent" refers only
		     to	independence from external targets  specified  by  the
		     DEPENDS option and	is orthogonal to a step's dependencies
		     on	other steps.

		     If	a step target is created for an	 independent  step  by
		     the  ExternalProject_Add()	 STEP_TARGETS option or	by the
		     ExternalProject_Add_StepTargets() function, it  will  not
		     depend on the external targets, but may depend on targets
		     for other steps.

	      BYPRODUCTS <file>...
		     New in version 3.2.

		     Files that	will be	generated  by  this  custom  step  but
		     which might or might not have their modification time up-
		     dated by subsequent builds. This list of files will ulti-
		     mately  be	passed through as the BYPRODUCTS option	to the
		     add_custom_command() used to implement  the  custom  step
		     internally.

	      ALWAYS <bool>
		     When  enabled, this option	specifies that the custom step
		     should always be run (i.e.	that it	is  always  considered
		     out of date).

	      EXCLUDE_FROM_MAIN	<bool>
		     When  enabled,  this  option  specifies that the external
		     project's main target does	not depend on the custom step.
		     This  may	cause step targets to be created automatically
		     for the steps on which this  step	depends.   See	policy
		     CMP0114.

	      WORKING_DIRECTORY	<dir>
		     Specifies the working directory to	set before running the
		     custom step's command. If this option is  not  specified,
		     the  directory will be the	value of the CMAKE_CURRENT_BI-
		     NARY_DIR at the  point  where  ExternalProject_Add_Step()
		     was called.

	      LOG <bool>
		     If	set, this causes the output from the custom step to be
		     captured to files in the external	project's  LOG_DIR  if
		     supplied or STAMP_DIR.

	      USES_TERMINAL <bool>
		     If	 enabled,  this	gives the custom step direct access to
		     the terminal if possible.

	      The command line,	comment, working directory and	byproducts  of
	      every  standard and custom step are processed to replace the to-
	      kens <SOURCE_DIR>, <SOURCE_SUBDIR>, <BINARY_DIR>,	 <INSTALL_DIR>
	      <TMP_DIR>,  <DOWNLOAD_DIR> and <DOWNLOADED_FILE> with their cor-
	      responding property values  defined  in  the  original  call  to
	      ExternalProject_Add().

	      New in version 3.3: Token	replacement is extended	to byproducts.

	      New in version 3.11: The <DOWNLOAD_DIR> substitution token.

       ExternalProject_Add_StepTargets
	      The ExternalProject_Add_StepTargets() function generates targets
	      for the steps listed. The	name of	each created target will be of
	      the form <name>-<step>:

		 ExternalProject_Add_StepTargets(<name>	<step1>	[<step2>...])

	      Creating	a  target  for a step allows it	to be used as a	depen-
	      dency of another target or to be triggered manually. Having tar-
	      gets  for	 specific steps	also allows them to be driven indepen-
	      dently of	each other by  specifying  targets  on	build  command
	      lines. For example, you may be submitting	to a sub-project based
	      dashboard	where you want to drive	the configure portion  of  the
	      build,  then submit to the dashboard, followed by	the build por-
	      tion, followed by	tests. If you invoke a custom target that  de-
	      pends  on	a step halfway through the step	dependency chain, then
	      all the previous steps will also run to ensure everything	is  up
	      to date.

	      Internally,	       ExternalProject_Add()		 calls
	      ExternalProject_Add_Step() to create each	step. If any STEP_TAR-
	      GETS were	specified, then	ExternalProject_Add_StepTargets() will
	      also be called after ExternalProject_Add_Step().	Even if	a step
	      is  not  mentioned  in  the  STEP_TARGETS	 option,  ExternalPro-
	      ject_Add_StepTargets() can still be called later to manually de-
	      fine a target for	the step.

	      The  STEP_TARGETS	 option	for ExternalProject_Add() is generally
	      the easiest way to ensure	targets	are created for	specific steps
	      of  interest.   For  custom  steps, ExternalProject_Add_StepTar-
	      gets() must be called explicitly if a target should also be cre-
	      ated  for	that custom step.  An alternative to these two options
	      is to populate the EP_STEP_TARGETS directory property.  It  acts
	      as  a default for	the step target	options	and can	save having to
	      repeatedly specify the same set of step  targets	when  multiple
	      external projects	are being defined.

	      New  in version 3.19: If CMP0114 is set to NEW, step targets are
	      fully responsible	for holding the	custom	commands  implementing
	      their  steps.  The primary target	created	by ExternalProject_Add
	      depends on the step targets, and the step	targets	depend on each
	      other.   The  target-level dependencies match the	file-level de-
	      pendencies used by the custom commands for each step.  The  tar-
	      gets  for	 steps created with ExternalProject_Add_Step()'s INDE-
	      PENDENT option do	not depend on the external  targets  specified
	      by ExternalProject_Add()'s DEPENDS option.  The predefined steps
	      mkdir, download, update, and patch are independent.

	      If CMP0114 is not	NEW,  the  following  deprecated  behavior  is
	      available:

	      o	A  deprecated  NO_DEPENDS  option may be specified immediately
		after the <name> and before the	first step.  If	the NO_DEPENDS
		option	is  specified,	the step target	will not depend	on the
		dependencies of	the external project (i.e. on any dependencies
		of the <name> custom target created by ExternalProject_Add()).
		This is	usually	safe for the download, update and patch	steps,
		since  they do not typically require that the dependencies are
		updated	and built. Using  NO_DEPENDS  for  any	of  the	 other
		pre-defined  steps,  however,  may break parallel builds. Only
		use NO_DEPENDS where it	is certain that	the named  steps  gen-
		uinely	do  not	 have dependencies. For	custom steps, consider
		whether	or not the custom commands require the dependencies to
		be configured, built and installed.

	      o	The INDEPENDENT_STEP_TARGETS option for	ExternalProject_Add(),
		or the EP_INDEPENDENT_STEP_TARGETS directory  property,	 tells
		the  function to call ExternalProject_Add_StepTargets()	inter-
		nally using the	NO_DEPENDS option for the specified steps.

       ExternalProject_Add_StepDependencies
	      New in version 3.2.

	      The ExternalProject_Add_StepDependencies() function can be  used
	      to  add  dependencies  to	a step.	The dependencies added must be
	      targets CMake already knows about	(these can  be	ordinary  exe-
	      cutable  or library targets, custom targets or even step targets
	      of another external project):

		 ExternalProject_Add_StepDependencies(<name> <step> <target1> [<target2>...])

	      This function takes care to set both target and file  level  de-
	      pendencies  and will ensure that parallel	builds will not	break.
	      It should	be used	instead	of add_dependencies() whenever	adding
	      a	 dependency  for some of the step targets generated by the Ex-
	      ternalProject module.

   Examples
       The following example shows how to download and	build  a  hypothetical
       project called FooBar from github:

	  include(ExternalProject)
	  ExternalProject_Add(foobar
	    GIT_REPOSITORY    git@github.com:FooCo/FooBar.git
	    GIT_TAG	      origin/release/1.2.3
	  )

       For the sake of the example, also define	a second hypothetical external
       project called SecretSauce, which is downloaded from a web server.  Two
       URLs are	given to take advantage	of a faster internal network if	avail-
       able, with a fallback to	a slower external server.  The	project	 is  a
       typical Makefile	project	with no	configure step,	so some	of the default
       commands	are overridden.	The build is only required to build the	 sauce
       target:

	  find_program(MAKE_EXE	NAMES gmake nmake make)
	  ExternalProject_Add(secretsauce
	    URL		      http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
			      https://www.somecompany.com/downloads/sauce-2.7.zip
	    URL_HASH	      MD5=d41d8cd98f00b204e9800998ecf8427e
	    CONFIGURE_COMMAND ""
	    BUILD_COMMAND     ${MAKE_EXE} sauce
	  )

       Suppose the build step of secretsauce requires that foobar must already
       be built. This could be enforced	like so:

	  ExternalProject_Add_StepDependencies(secretsauce build foobar)

       Another alternative would be to create a	 custom	 target	 for  foobar's
       build  step  and	 make secretsauce depend on that rather	than the whole
       foobar project. This would mean foobar  only  needs  to	be  built,  it
       doesn't need to run its install or test steps before secretsauce	can be
       built. The dependency can also be defined along	with  the  secretsauce
       project:

	  ExternalProject_Add_StepTargets(foobar build)
	  ExternalProject_Add(secretsauce
	    URL		      http://intranet.somecompany.com/artifacts/sauce-2.7.tgz
			      https://www.somecompany.com/downloads/sauce-2.7.zip
	    URL_HASH	      MD5=d41d8cd98f00b204e9800998ecf8427e
	    CONFIGURE_COMMAND ""
	    BUILD_COMMAND     ${MAKE_EXE} sauce
	    DEPENDS	      foobar-build
	  )

       Instead	of calling ExternalProject_Add_StepTargets(), the target could
       be defined along	with the foobar	project	itself:

	  ExternalProject_Add(foobar
	    GIT_REPOSITORY git@github.com:FooCo/FooBar.git
	    GIT_TAG	   origin/release/1.2.3
	    STEP_TARGETS   build
	  )

       If many external	projects should	have the same  set  of	step  targets,
       setting	a  directory  property	may be more convenient.	The build step
       target could be created automatically by	 setting  the  EP_STEP_TARGETS
       directory   property   before   creating	 the  external	projects  with
       ExternalProject_Add():

	  set_property(DIRECTORY PROPERTY EP_STEP_TARGETS build)

       Lastly, suppose that secretsauce	provides a script called makedoc which
       can be used to generate its own documentation. Further suppose that the
       script expects the output directory to be provided as the only  parame-
       ter  and	that it	should be run from the secretsauce source directory. A
       custom step and a custom	target to trigger the script  can  be  defined
       like so:

	  ExternalProject_Add_Step(secretsauce docs
	    COMMAND	      <SOURCE_DIR>/makedoc <BINARY_DIR>
	    WORKING_DIRECTORY <SOURCE_DIR>
	    COMMENT	      "Building	secretsauce docs"
	    ALWAYS	      TRUE
	    EXCLUDE_FROM_MAIN TRUE
	  )
	  ExternalProject_Add_StepTargets(secretsauce docs)

       The custom step could then be triggered from the	main build like	so:

	  cmake	--build	. --target secretsauce-docs

   FeatureSummary
       Functions for generating	a summary of enabled/disabled features.

       These  functions	 can be	used to	generate a summary of enabled and dis-
       abled packages and/or feature for a build tree such as:

	  -- The following OPTIONAL packages have been found:
	  LibXml2 (required version >= 2.4), XML processing lib, <http://xmlsoft.org>
	     * Enables HTML-import in MyWordProcessor
	     * Enables odt-export in MyWordProcessor
	  PNG, A PNG image library., <http://www.libpng.org/pub/png/>
	     * Enables saving screenshots
	  -- The following OPTIONAL packages have not been found:
	  Lua51, The Lua scripting language., <http://www.lua.org>
	     * Enables macros in MyWordProcessor
	  Foo, Foo provides cool stuff.

   Global Properties
       FeatureSummary_PKG_TYPES

       The global property FeatureSummary_PKG_TYPES defines the	type of	 pack-
       ages used by FeatureSummary.

       The order in this list is important, the	first package type in the list
       is the least important, the last	is the most important. the of a	 pack-
       age can only be changed to higher types.

       The  default package types are ,	RUNTIME, OPTIONAL, RECOMMENDED and RE-
       QUIRED, and their importance is RUNTIME < OPTIONAL < RECOMMENDED	<  RE-
       QUIRED.

       FeatureSummary_REQUIRED_PKG_TYPES

       The  global  property  FeatureSummary_REQUIRED_PKG_TYPES	 defines which
       package types are required.

       If one or more package in this categories has  not  been	 found,	 CMake
       will  abort  when  calling  feature_summary()  with the 'FATAL_ON_MISS-
       ING_REQUIRED_PACKAGES' option enabled.

       The default value for this global property is REQUIRED.

       FeatureSummary_DEFAULT_PKG_TYPE

       The global property FeatureSummary_DEFAULT_PKG_TYPE defines which pack-
       age  type  is  the default one.	When calling feature_summary(),	if the
       user did	not set	the package type explicitly, the package will  be  as-
       signed to this category.

       This    value   must   be   one	 of   the   types   defined   in   the
       FeatureSummary_PKG_TYPES	global property	unless the package type	is set
       for all the packages.

       The default value for this global property is OPTIONAL.

       FeatureSummary_<TYPE>_DESCRIPTION

       New in version 3.9.

       The  global  property  FeatureSummary__TYPE__DESCRIPTION	can be defined
       for each	type to	replace	the type name with the specified string	 when-
       ever the	package	type is	used in	an output string.

       If not set, the string "<TYPE> packages"	is used.

   Functions
       feature_summary

		 feature_summary( [FILENAME <file>]
				  [APPEND]
				  [VAR <variable_name>]
				  [INCLUDE_QUIET_PACKAGES]
				  [FATAL_ON_MISSING_REQUIRED_PACKAGES]
				  [DESCRIPTION "<description>" | DEFAULT_DESCRIPTION]
				  [QUIET_ON_EMPTY]
				  WHAT (ALL
				       | PACKAGES_FOUND	| PACKAGES_NOT_FOUND
				       | <TYPE>_PACKAGES_FOUND | <TYPE>_PACKAGES_NOT_FOUND
				       | ENABLED_FEATURES | DISABLED_FEATURES)
				)

	      The  feature_summary()  macro  can  be used to print information
	      about enabled or disabled	packages or features of	a project.  By
	      default, only the	names of the features/packages will be printed
	      and  their  required  version  when  one	was  specified.	   Use
	      set_package_properties()	to  add	 more useful information, like
	      e.g.  a download URL for the respective package or their purpose
	      in the project.

	      The  WHAT	option is the only mandatory option.  Here you specify
	      what information will be printed:

	      ALL    print everything

	      ENABLED_FEATURES
		     the list of all features which are	enabled

	      DISABLED_FEATURES
		     the list of all features which are	disabled

	      PACKAGES_FOUND
		     the list of all packages which have been found

	      PACKAGES_NOT_FOUND
		     the list of all packages which have not been found

	      For    each    package	type	<TYPE>	  defined    by	   the
	      FeatureSummary_PKG_TYPES global property,	the following informa-
	      tion can also be used:

	      <TYPE>_PACKAGES_FOUND
		     only those	packages which have been found which have  the
		     type <TYPE>

	      <TYPE>_PACKAGES_NOT_FOUND
		     only  those packages which	have not been found which have
		     the type <TYPE>

	      Changed in version 3.1: With the exception  of  the  ALL	value,
	      these  values  can be combined in	order to customize the output.
	      For example:

		 feature_summary(WHAT ENABLED_FEATURES DISABLED_FEATURES)

	      If a FILENAME is given, the information  is  printed  into  this
	      file.  If	APPEND is used,	it is appended to this file, otherwise
	      the file is overwritten if it already existed.  If the  VAR  op-
	      tion  is	used,  the information is "printed" into the specified
	      variable.	 If FILENAME is	not used, the information  is  printed
	      to  the terminal.	 Using the DESCRIPTION option a	description or
	      headline can be set which	will be	printed	above the actual  con-
	      tent.   If  only	one type of package was	requested, no title is
	      printed, unless it is explicitly set using either	DESCRIPTION to
	      use a custom string, or DEFAULT_DESCRIPTION to use a default ti-
	      tle for the requested type.  If INCLUDE_QUIET_PACKAGES is	given,
	      packages	which  have been searched with find_package(...	QUIET)
	      will also	be listed.  By	default	 they  are  skipped.   If  FA-
	      TAL_ON_MISSING_REQUIRED_PACKAGES is given, CMake will abort if a
	      package which is marked as one of	the package  types  listed  in
	      the  FeatureSummary_REQUIRED_PKG_TYPES  global  property has not
	      been     found.	   The	   default     value	  for	   the
	      FeatureSummary_REQUIRED_PKG_TYPES	global property	is REQUIRED.

	      New in version 3.9: The DEFAULT_DESCRIPTION option.

	      The FeatureSummary_DEFAULT_PKG_TYPE global property can be modi-
	      fied to change the default package type assigned	when  not  ex-
	      plicitly assigned	by the user.

	      New  in  version	3.8:  If the QUIET_ON_EMPTY option is used, if
	      only one type of package was requested, and no packages  belong-
	      ing  to  that category were found, then no output	(including the
	      DESCRIPTION) is printed or added to the VAR variable.

	      Example 1, append	everything to a	file:

		 include(FeatureSummary)
		 feature_summary(WHAT ALL
				 FILENAME ${CMAKE_BINARY_DIR}/all.log APPEND)

	      Example 2, print the enabled features into the variable enabled-
	      FeaturesText, including QUIET packages:

		 include(FeatureSummary)
		 feature_summary(WHAT ENABLED_FEATURES
				 INCLUDE_QUIET_PACKAGES
				 DESCRIPTION "Enabled Features:"
				 VAR enabledFeaturesText)
		 message(STATUS	"${enabledFeaturesText}")

	      Example 3, change	default	package	types and print	only the cate-
	      gories that are not empty:

		 include(FeatureSummary)
		 set_property(GLOBAL APPEND PROPERTY FeatureSummary_PKG_TYPES BUILD)
		 find_package(FOO)
		 set_package_properties(FOO PROPERTIES TYPE BUILD)
		 feature_summary(WHAT BUILD_PACKAGES_FOUND
				 Description "Build tools found:"
				 QUIET_ON_EMPTY)
		 feature_summary(WHAT BUILD_PACKAGES_NOT_FOUND
				 Description "Build tools not found:"
				 QUIET_ON_EMPTY)

       set_package_properties

		 set_package_properties(<name> PROPERTIES
					[ URL <url> ]
					[ DESCRIPTION <description> ]
					[ TYPE (RUNTIME|OPTIONAL|RECOMMENDED|REQUIRED) ]
					[ PURPOSE <purpose> ]
				       )

	      Use this macro to	set up information about  the  named  package,
	      which  can then be displayed via FEATURE_SUMMARY().  This	can be
	      done either directly in the Find-module or in the	project	 which
	      uses the module after the	find_package() call.  The features for
	      which information	can be set  are	 added	automatically  by  the
	      find_package() command.

	      URL <url>
		     This  should be the homepage of the package, or something
		     similar.  Ideally this is set  already  directly  in  the
		     Find-module.

	      DESCRIPTION <description>
		     A	short  description  what  that package is, at most one
		     sentence.	Ideally	this is	set already  directly  in  the
		     Find-module.

	      TYPE <type>
		     What  type	 of  dependency	 has the using project on that
		     package.  Default is OPTIONAL.  In	 this  case  it	 is  a
		     package  which  can be used by the	project	when available
		     at	buildtime, but it also work without.   RECOMMENDED  is
		     similar  to OPTIONAL, i.e.	 the project will build	if the
		     package is	not present, but the functionality of the  re-
		     sulting binaries will be severely limited.	 If a REQUIRED
		     package is	not available at buildtime,  the  project  may
		     not  even	build.	 This  can  be	combined  with the FA-
		     TAL_ON_MISSING_REQUIRED_PACKAGES	argument   for	  fea-
		     ture_summary().   Last,  a	 RUNTIME  package is a package
		     which is actually not used	at all during the  build,  but
		     which  is required	for actually running the resulting bi-
		     naries.  So if such a package is missing, the project can
		     still  be	built,	but  it	 may  not  work	 later on.  If
		     set_package_properties() is called	multiple times for the
		     same  package  with  different  TYPEs,  the  TYPE is only
		     changed to	higher TYPEs (RUNTIME <	OPTIONAL < RECOMMENDED
		     <	REQUIRED), lower TYPEs are ignored.  The TYPE property
		     is	project-specific, so it	cannot be set by the Find-mod-
		     ule,  but	must be	set in the project.  Type accepted can
		     be	changed	by setting the FeatureSummary_PKG_TYPES	global
		     property.

	      PURPOSE <purpose>
		     This describes which features this	package	enables	in the
		     project, i.e.  it tells the user  what  functionality  he
		     gets  in  the resulting binaries.	If set_package_proper-
		     ties() is called multiple times for a package,  all  PUR-
		     POSE properties are appended to a list of purposes	of the
		     package in	the project.  As the TYPE property,  also  the
		     PURPOSE property is project-specific, so it cannot	be set
		     by	the Find-module, but must be set in the	project.

	      Example for setting the info for a package:

		 find_package(LibXml2)
		 set_package_properties(LibXml2	PROPERTIES
					DESCRIPTION "A XML processing library."
					URL "http://xmlsoft.org/")
		 # or
		 set_package_properties(LibXml2	PROPERTIES
					TYPE RECOMMENDED
					PURPOSE	"Enables HTML-import in	MyWordProcessor")
		 # or
		 set_package_properties(LibXml2	PROPERTIES
					TYPE OPTIONAL
					PURPOSE	"Enables odt-export in MyWordProcessor")

		 find_package(DBUS)
		 set_package_properties(DBUS PROPERTIES
		   TYPE	RUNTIME
		   PURPOSE "Necessary to disable the screensaver during	a presentation")

       add_feature_info

		 add_feature_info(<name> <enabled> <description>)

	      Use this macro to	add information	about a	feature	with the given
	      <name>.	<enabled>  contains whether this feature is enabled or
	      not. It can be a variable	or a list  of  conditions.   <descrip-
	      tion>  is	a text describing the feature.	The information	can be
	      displayed	using feature_summary()	for ENABLED_FEATURES and  DIS-
	      ABLED_FEATURES respectively.

	      Changed in version 3.8: <enabled>	can be a list of conditions.

	      Example for setting the info for a feature:

		 option(WITH_FOO "Help for foo"	ON)
		 add_feature_info(Foo WITH_FOO "The Foo	feature	provides very cool stuff.")

   Legacy Macros
       The following macros are	provided for compatibility with	previous CMake
       versions:

       set_package_info

		 set_package_info(<name> <description> [ <url> [<purpose>] ])

	      Use this macro to	set up information about  the  named  package,
	      which  can then be displayed via feature_summary().  This	can be
	      done either directly in the Find-module or in the	project	 which
	      uses the module after the	find_package() call.  The features for
	      which information	can be set  are	 added	automatically  by  the
	      find_package() command.

       set_feature_info

		 set_feature_info(<name> <description> [<url>])

	      Does the same as:

		 set_package_info(<name> <description> <url>)

       print_enabled_features

		 print_enabled_features()

	      Does the same as

		 feature_summary(WHAT ENABLED_FEATURES DESCRIPTION "Enabled features:")

       print_disabled_features

		 print_disabled_features()

	      Does the same as

		 feature_summary(WHAT DISABLED_FEATURES	DESCRIPTION "Disabled features:")

   FetchContent
       New in version 3.11.

   Overview
       This module enables populating content at configure time	via any	method
       supported by the	ExternalProject	module.	 Whereas ExternalProject_Add()
       downloads  at  build time, the FetchContent module makes	content	avail-
       able immediately, allowing the configure	step to	 use  the  content  in
       commands	like add_subdirectory(), include() or file() operations.

       Content	population  details  would normally be defined separately from
       the command that	performs the actual population.	 This  separation  en-
       sures  that  all	 of the	dependency details are defined before anything
       may try to use those details to populate	content.  This is particularly
       important in more complex project hierarchies where dependencies	may be
       shared between multiple projects.

       The following shows a typical example of	declaring content details:

	  FetchContent_Declare(
	    googletest
	    GIT_REPOSITORY https://github.com/google/googletest.git
	    GIT_TAG	   release-1.8.0
	  )

       For most	typical	cases, populating the content can then be done with  a
       single command like so:

	  FetchContent_MakeAvailable(googletest)

       The  above  command  not	only populates the content, it also adds it to
       the main	build (if possible) so that the	main build can use  the	 popu-
       lated project's targets,	etc.  In some cases, the main project may need
       to have more precise control over the population	or may be required  to
       explicitly  define the population steps (e.g. if	CMake versions earlier
       than 3.14 need to be supported).	 The typical pattern  of  such	custom
       steps looks like	this:

	  FetchContent_GetProperties(googletest)
	  if(NOT googletest_POPULATED)
	    FetchContent_Populate(googletest)
	    add_subdirectory(${googletest_SOURCE_DIR} ${googletest_BINARY_DIR})
	  endif()

       Regardless  of  which  population  method  is  used, when using the de-
       clare-populate  pattern	with  a	 hierarchical	project	  arrangement,
       projects	 at  higher  levels  in	the hierarchy are able to override the
       population details of content specified anywhere	lower in  the  project
       hierarchy.  The ability to detect whether content has already been pop-
       ulated ensures that even	if multiple child projects want	 certain  con-
       tent  to	 be  available,	 the first one to populate it wins.  The other
       child project can simply	make use of the	already	available content  in-
       stead of	repeating the population for itself.  See the Examples section
       which demonstrates this scenario.

       The FetchContent	module also supports defining and  populating  content
       in  a single call, with no check	for whether the	content	has been popu-
       lated elsewhere in the project already.	This is	a more low level oper-
       ation  and  would not normally be the way the module is used, but it is
       sometimes useful	as part	of implementing	some higher level  feature  or
       to populate some	content	in CMake's script mode.

       Changed in version 3.14:	FetchContent commands can access the terminal.
       This is necessary for password prompts and real-time progress  displays
       to work.

   Commands
   Declaring Content Details
       FetchContent_Declare

		 FetchContent_Declare(<name> <contentOptions>...)

	      The FetchContent_Declare() function records the options that de-
	      scribe how to populate the specified content, but	 if  such  de-
	      tails  have  already  been recorded earlier in this project (re-
	      gardless of where	in the project hierarchy), this	and all	 later
	      calls  for  the same content <name> are ignored.	This "first to
	      record, wins" approach is	what allows hierarchical  projects  to
	      have parent projects override content details of child projects.

	      The  content  <name>  can	be any string without spaces, but good
	      practice would be	to use only letters, numbers and  underscores.
	      The name will be treated case-insensitively and it should	be ob-
	      vious for	the content it represents, often being the name	of the
	      child project or the value given to its top level	project() com-
	      mand  (if	 it  is	 a  CMake  project).   For  well-known	public
	      projects,	 the name should generally be the official name	of the
	      project.	Choosing an unusual name makes it unlikely that	 other
	      projects needing that same content will use the same name, lead-
	      ing to the content being populated multiple times.

	      The <contentOptions> can be any of the download or  update/patch
	      options that the ExternalProject_Add() command understands.  The
	      configure, build,	install	and test steps are explicitly disabled
	      and  therefore  options  related	to  them will be ignored.  The
	      SOURCE_SUBDIR	option	   is	   an	   exception,	   see
	      FetchContent_MakeAvailable() for details on how that affects be-
	      havior.

	      In most cases, <contentOptions> will just	be a couple of options
	      defining	the download method and	method-specific	details	like a
	      commit tag or archive hash.  For example:

		 FetchContent_Declare(
		   googletest
		   GIT_REPOSITORY https://github.com/google/googletest.git
		   GIT_TAG	  release-1.8.0
		 )

		 FetchContent_Declare(
		   myCompanyIcons
		   URL	    https://intranet.mycompany.com/assets/iconset_1.12.tar.gz
		   URL_HASH 5588a7b18261c20068beabfb4f530b87
		 )

		 FetchContent_Declare(
		   myCompanyCertificates
		   SVN_REPOSITORY svn+ssh://svn.mycompany.com/srv/svn/trunk/certs
		   SVN_REVISION	  -r12345
		 )

   Populating The Content
       For most	common scenarios, population means making content available to
       the main	build according	to previously declared details for that	depen-
       dency.  There are two main patterns for populating content,  one	 based
       on calling FetchContent_GetProperties() and FetchContent_Populate() for
       more    precise	  control     and     the     other	on     calling
       FetchContent_MakeAvailable()  for  a  simpler, more automated approach.
       The former generally follows this canonical pattern:

	  # Check if population	has already been performed
	  FetchContent_GetProperties(<name>)
	  string(TOLOWER "<name>" lcName)
	  if(NOT ${lcName}_POPULATED)
	    # Fetch the	content	using previously declared details
	    FetchContent_Populate(<name>)

	    # Set custom variables, policies, etc.
	    # ...

	    # Bring the	populated content into the build
	    add_subdirectory(${${lcName}_SOURCE_DIR} ${${lcName}_BINARY_DIR})
	  endif()

       The above is such a common pattern that,	 where	no  custom  steps  are
       needed  between	the calls to FetchContent_Populate() and add_subdirec-
       tory(),	 equivalent    logic	can    be    obtained	 by    calling
       FetchContent_MakeAvailable()  instead.  Where it	meets the needs	of the
       project,	FetchContent_MakeAvailable() should be	preferred,  as	it  is
       simpler and provides additional features	over the pattern above.

       FetchContent_Populate

		 FetchContent_Populate(	<name> )

	      In  most	cases,	the  only argument given to FetchContent_Popu-
	      late() is	the <name>.  When used this way, the  command  assumes
	      the  content  details  have  been	recorded by an earlier call to
	      FetchContent_Declare().  The details  are	 stored	 in  a	global
	      property,	 so they are unaffected	by things like variable	or di-
	      rectory scope.   Therefore,  it  doesn't	matter	where  in  the
	      project  the  details  were previously declared, as long as they
	      have been	declared before	the call  to  FetchContent_Populate().
	      Those  saved details are then used to construct a	call to	Exter-
	      nalProject_Add() in a private sub-build to perform  the  content
	      population  immediately.	 The  implementation  of  ExternalPro-
	      ject_Add() ensures that if the content has  already  been	 popu-
	      lated  in	 a  previous  CMake  run,  that	content	will be	reused
	      rather than repopulating them again.  For	the common case	 where
	      population  involves  downloading	content, the cost of the down-
	      load is only paid	once.

	      An internal global property records when	a  particular  content
	      population  request  has	been processed.	 If FetchContent_Popu-
	      late() is	called more than once for the same content name	within
	      a	 configure  run,  the  second  call  will  halt	with an	error.
	      Projects can and should check whether content population has al-
	      ready  been processed with the FetchContent_GetProperties() com-
	      mand before calling FetchContent_Populate().

	      FetchContent_Populate() will set three variables in the scope of
	      the  caller;  <lcName>_POPULATED,	 <lcName>_SOURCE_DIR  and <lc-
	      Name>_BINARY_DIR,	where <lcName> is the lowercased <name>.  <lc-
	      Name>_POPULATED  will  always  be	set to True by the call.  <lc-
	      Name>_SOURCE_DIR is the location where the content can be	 found
	      upon  return  (it	 will have already been	populated), while <lc-
	      Name>_BINARY_DIR is a directory intended for  use	 as  a	corre-
	      sponding	build directory.  The main use case for	the two	direc-
	      tory variables is	to call	add_subdirectory()  immediately	 after
	      population, i.e.:

		 FetchContent_Populate(FooBar ...)
		 add_subdirectory(${foobar_SOURCE_DIR} ${foobar_BINARY_DIR})

	      The  values  of  the  three variables can	also be	retrieved from
	      anywhere	  in	the    project	   hierarchy	 using	   the
	      FetchContent_GetProperties() command.

	      A	 number	 of cache variables influence the behavior of all con-
	      tent  population	performed   using   details   saved   from   a
	      FetchContent_Declare() call:

	      FETCHCONTENT_BASE_DIR
		     In	 most  cases, the saved	details	do not specify any op-
		     tions relating to the directories to use for the internal
		     sub-build,	final source and build areas.  It is generally
		     best to leave these decisions up to the FetchContent mod-
		     ule  to  handle  on  the project's	behalf.	 The FETCHCON-
		     TENT_BASE_DIR cache variable  controls  the  point	 under
		     which  all	 content population directories	are collected,
		     but in most cases developers would	 not  need  to	change
		     this.  The	default	location is ${CMAKE_BINARY_DIR}/_deps,
		     but if developers change this value, they should  aim  to
		     keep  the	path short and just below the top level	of the
		     build tree	to avoid running into path length problems  on
		     Windows.

	      FETCHCONTENT_QUIET
		     The  logging  output  during population can be quite ver-
		     bose, making the configure	stage quite noisy.  This cache
		     option (ON	by default) hides all population output	unless
		     an	error is encountered.  If experiencing	problems  with
		     hung downloads, temporarily switching this	option off may
		     help diagnose which content population is causing the is-
		     sue.

	      FETCHCONTENT_FULLY_DISCONNECTED
		     When  this	option is enabled, no attempt is made to down-
		     load or update any	content.  It is	assumed	that all  con-
		     tent  has already been populated in a previous run	or the
		     source directories	have been pointed at existing contents
		     the  developer  has  provided manually (using options de-
		     scribed further below).  When the developer knows that no
		     changes  have  been  made to any content details, turning
		     this option ON can	significantly speed up	the  configure
		     stage.  It	is OFF by default.

	      FETCHCONTENT_UPDATES_DISCONNECTED
		     This is a less severe download/update control compared to
		     FETCHCONTENT_FULLY_DISCONNECTED.	Instead	 of  bypassing
		     all  download  and	 update	 logic,	 the  FETCHCONTENT_UP-
		     DATES_DISCONNECTED	 only  disables	 the   update	stage.
		     Therefore,	if content has not been	downloaded previously,
		     it	will still be downloaded when this option is  enabled.
		     This can speed up the configure stage, but	not as much as
		     FETCHCONTENT_FULLY_DISCONNECTED.  It is OFF by default.

	      In addition to the above cache variables,	 the  following	 cache
	      variables	 are  also  defined for	each content name (<ucName> is
	      the uppercased value of <name>):

	      FETCHCONTENT_SOURCE_DIR_<ucName>
		     If	this is	set, no	download or update steps are performed
		     for  the  specified  content  and the <lcName>_SOURCE_DIR
		     variable returned to the caller is	pointed	at this	 loca-
		     tion.   This  gives  developers  a	way to have a separate
		     checkout of the content that they can modify freely with-
		     out  interference	from the build.	 The build simply uses
		     that existing source, but it still	 defines  <lcName>_BI-
		     NARY_DIR  to point	inside its own build area.  Developers
		     are strongly encouraged to	use this mechanism rather than
		     editing the sources populated in the default location, as
		     changes to	sources	in the default location	 can  be  lost
		     when  content  population	details	 are  changed  by  the
		     project.

	      FETCHCONTENT_UPDATES_DISCONNECTED_<ucName>
		     This is the per-content  equivalent  of  FETCHCONTENT_UP-
		     DATES_DISCONNECTED.  If  the global option	or this	option
		     is	ON, then updates will be disabled for the  named  con-
		     tent.   Disabling	updates	 for individual	content	can be
		     useful for	content	whose  details	rarely	change,	 while
		     still  leaving other frequently changing content with up-
		     dates enabled.

	      The FetchContent_Populate() command also supports	a  syntax  al-
	      lowing  the content details to be	specified directly rather than
	      using any	saved details.	This is	more low-level and use of this
	      form is generally	to be avoided in favour	of using saved content
	      details as outlined above.  Nevertheless,	in certain  situations
	      it can be	useful to invoke the content population	as an isolated
	      operation	(typically as part of implementing some	 other	higher
	      level feature or when using CMake	in script mode):

		 FetchContent_Populate(	<name>
		   [QUIET]
		   [SUBBUILD_DIR <subBuildDir>]
		   [SOURCE_DIR <srcDir>]
		   [BINARY_DIR <binDir>]
		   ...
		 )

	      This  form  has  a  number of key	differences to that where only
	      <name> is	provided:

	      o	All required population	details	are assumed to have been  pro-
		vided  directly	 in  the  call to FetchContent_Populate(). Any
		saved details for <name> are ignored.

	      o	No check is made for whether content for  <name>  has  already
		been populated.

	      o	No  global  property  is set to	record that the	population has
		occurred.

	      o	No global properties record the	source or  binary  directories
		used for the populated content.

	      o	The   FETCHCONTENT_FULLY_DISCONNECTED	and   FETCHCONTENT_UP-
		DATES_DISCONNECTED cache variables are ignored.

	      The <lcName>_SOURCE_DIR and  <lcName>_BINARY_DIR	variables  are
	      still  returned to the caller, but since these locations are not
	      stored as	global properties when this form  is  used,  they  are
	      only  available  to  the calling scope and below rather than the
	      entire project hierarchy.	 No <lcName>_POPULATED variable	is set
	      in the caller's scope with this form.

	      The  supported  options for FetchContent_Populate() are the same
	      as those for FetchContent_Declare().  Those  few	options	 shown
	      just  above  are	either	specific to FetchContent_Populate() or
	      their  behavior  is  slightly  modified  from  how  ExternalPro-
	      ject_Add() treats	them.

	      QUIET  The  QUIET	option can be given to hide the	output associ-
		     ated with populating the specified	content.  If the popu-
		     lation  fails,  the  output  will	be shown regardless of
		     whether this option was given or not so that the cause of
		     the  failure  can	be  diagnosed.	 The  global FETCHCON-
		     TENT_QUIET	cache variable	has  no	 effect	 on  FetchCon-
		     tent_Populate()  calls where the content details are pro-
		     vided directly.

	      SUBBUILD_DIR
		     The SUBBUILD_DIR argument can be provided to  change  the
		     location  of the sub-build	created	to perform the popula-
		     tion.    The   default   value   is   ${CMAKE_CURRENT_BI-
		     NARY_DIR}/<lcName>-subbuild  and  it  would be unusual to
		     need to override this default.  If	 a  relative  path  is
		     specified,	  it   will  be	 interpreted  as  relative  to
		     CMAKE_CURRENT_BINARY_DIR.	This option should not be con-
		     fused  with  the  SOURCE_SUBDIR option which only affects
		     the FetchContent_MakeAvailable() command.

	      SOURCE_DIR, BINARY_DIR
		     The SOURCE_DIR and	BINARY_DIR arguments are supported  by
		     ExternalProject_Add(),  but  different default values are
		     used by FetchContent_Populate().  SOURCE_DIR defaults  to
		     ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-src  and  BINARY_DIR
		     defaults  to  ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-build.
		     If	 a  relative path is specified,	it will	be interpreted
		     as	relative to CMAKE_CURRENT_BINARY_DIR.

	      In addition to the above explicit	options,  any  other  unrecog-
	      nized  options  are  passed  through  unmodified to ExternalPro-
	      ject_Add() to perform the	download, patch	and update steps.  The
	      following	 options  are explicitly prohibited (they are disabled
	      by the FetchContent_Populate() command):

	      o	CONFIGURE_COMMAND

	      o	BUILD_COMMAND

	      o	INSTALL_COMMAND

	      o	TEST_COMMAND

	      If using FetchContent_Populate() within CMake's script mode,  be
	      aware  that  the implementation sets up a	sub-build which	there-
	      fore requires a CMake generator and build	tool to	be  available.
	      If  these	 cannot	 be found by default, then the CMAKE_GENERATOR
	      and/or CMAKE_MAKE_PROGRAM	variables will need to be  set	appro-
	      priately on the command line invoking the	script.

	      New  in  version 3.18: Added support for DOWNLOAD_NO_EXTRACT and
	      SOURCE_SUBDIR options.

       FetchContent_GetProperties
	      When    using    saved	content	   details,    a    call    to
	      FetchContent_Populate() records information in global properties
	      which can	be queried at any time.	 This information includes the
	      source  and  binary  directories associated with the content and
	      also whether or not the content population  has  been  processed
	      during the current configure run.

		 FetchContent_GetProperties( <name>
		   [SOURCE_DIR <srcDirVar>]
		   [BINARY_DIR <binDirVar>]
		   [POPULATED <doneVar>]
		 )

	      The  SOURCE_DIR, BINARY_DIR and POPULATED	options	can be used to
	      specify which properties should be retrieved.  Each  option  ac-
	      cepts  a	value  which  is  the name of the variable in which to
	      store that property.  Most of the	time though,  only  <name>  is
	      given,  in  which	case the call will then	set the	same variables
	      as a call	to FetchContent_Populate(name).	 This allows the  fol-
	      lowing canonical pattern to be used, which ensures that the rel-
	      evant variables will always be defined regardless	of whether  or
	      not  the	population has been performed elsewhere	in the project
	      already:

		 FetchContent_GetProperties(foobar)
		 if(NOT	foobar_POPULATED)
		   FetchContent_Populate(foobar)
		   ...
		 endif()

	      The above	pattern	allows other parts of the overall project  hi-
	      erarchy  to  re-use  the same content and	ensure that it is only
	      populated	once.

       FetchContent_MakeAvailable

		 FetchContent_MakeAvailable( <name1> [<name2>...] )

	      New in version 3.14.

	      This command implements the common pattern typically needed  for
	      most dependencies.  It iterates over each	of the named dependen-
	      cies in turn and for each	one it loosely follows	the  canonical
	      pattern  as  presented at	the beginning of this section.	An im-
	      portant difference  is  that  add_subdirectory()	will  only  be
	      called  on  the  populated  content if there is a	CMakeLists.txt
	      file in its top level source directory.  This allows the command
	      to  be used for dependencies that	make downloaded	content	avail-
	      able at a	known location but which do not	need or	support	 being
	      added directly to	the build.

	      The SOURCE_SUBDIR	option can be given in the declared details to
	      instruct	FetchContent_MakeAvailable()  to  look	for  a	CMake-
	      Lists.txt	 file  in a subdirectory below the top level (i.e. the
	      same way that SOURCE_SUBDIR is used by the ExternalProject_Add()
	      command).	  SOURCE_SUBDIR	 must  always be a relative path.  See
	      the next section for an example of this option.

   Examples
       This first fairly straightforward example  ensures  that	 some  popular
       testing frameworks are available	to the main build:

	  include(FetchContent)
	  FetchContent_Declare(
	    googletest
	    GIT_REPOSITORY https://github.com/google/googletest.git
	    GIT_TAG	   release-1.8.0
	  )
	  FetchContent_Declare(
	    Catch2
	    GIT_REPOSITORY https://github.com/catchorg/Catch2.git
	    GIT_TAG	   v2.5.0
	  )

	  # After the following	call, the CMake	targets	defined	by googletest and
	  # Catch2 will	be defined and available to the	rest of	the build
	  FetchContent_MakeAvailable(googletest	Catch2)

       If the sub-project's CMakeLists.txt file	is not at the top level	of its
       source tree, the	SOURCE_SUBDIR option can be used to tell  FetchContent
       where  to  find it.  The	following example shows	how to use that	option
       and it also sets	a variable which is meaningful to the  subproject  be-
       fore pulling it into the	main build:

	  include(FetchContent)
	  FetchContent_Declare(
	    protobuf
	    GIT_REPOSITORY https://github.com/protocolbuffers/protobuf.git
	    GIT_TAG	   v3.12.0
	    SOURCE_SUBDIR  cmake
	  )
	  set(protobuf_BUILD_TESTS OFF)
	  FetchContent_MakeAvailable(protobuf)

       In  more	 complex project hierarchies, the dependency relationships can
       be more complicated.  Consider a	hierarchy where	projA is the top level
       project	and  it	 depends  directly  on projects	projB and projC.  Both
       projB and projC can be built standalone and they	also  both  depend  on
       another	project	projD.	projB additionally depends on projE.  This ex-
       ample assumes that all five projects are	available  on  a  company  git
       server.	 The  CMakeLists.txt  of each project might have sections like
       the following:

       projA:

	  include(FetchContent)
	  FetchContent_Declare(
	    projB
	    GIT_REPOSITORY git@mycompany.com:git/projB.git
	    GIT_TAG	   4a89dc7e24ff212a7b5167bef7ab079d
	  )
	  FetchContent_Declare(
	    projC
	    GIT_REPOSITORY git@mycompany.com:git/projC.git
	    GIT_TAG	   4ad4016bd1d8d5412d135cf8ceea1bb9
	  )
	  FetchContent_Declare(
	    projD
	    GIT_REPOSITORY git@mycompany.com:git/projD.git
	    GIT_TAG	   origin/integrationBranch
	  )
	  FetchContent_Declare(
	    projE
	    GIT_REPOSITORY git@mycompany.com:git/projE.git
	    GIT_TAG	   origin/release/2.3-rc1
	  )

	  # Order is important,	see notes in the discussion further below
	  FetchContent_MakeAvailable(projD projB projC)

       projB:

	  include(FetchContent)
	  FetchContent_Declare(
	    projD
	    GIT_REPOSITORY git@mycompany.com:git/projD.git
	    GIT_TAG	   20b415f9034bbd2a2e8216e9a5c9e632
	  )
	  FetchContent_Declare(
	    projE
	    GIT_REPOSITORY git@mycompany.com:git/projE.git
	    GIT_TAG	   68e20f674a48be38d60e129f600faf7d
	  )

	  FetchContent_MakeAvailable(projD projE)

       projC:

	  include(FetchContent)
	  FetchContent_Declare(
	    projD
	    GIT_REPOSITORY git@mycompany.com:git/projD.git
	    GIT_TAG	   7d9a17ad2c962aa13e2fbb8043fb6b8a
	  )

	  # This particular version of projD requires workarounds
	  FetchContent_GetProperties(projD)
	  if(NOT projd_POPULATED)
	    FetchContent_Populate(projD)

	    # Copy an additional/replacement file into the populated source
	    file(COPY someFile.c DESTINATION ${projd_SOURCE_DIR}/src)

	    add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR})
	  endif()

       A few key points	should be noted	in the above:

       o projB and projC define	different content details for projD, but projA
	 also  defines a set of	content	details	for projD.  Because projA will
	 define	them first, the	details	from projB and projC will not be used.
	 The  override	details	defined	by projA are not required to match ei-
	 ther of those from projB or projC, but	it is up to the	 higher	 level
	 project  to  ensure  that the details it does define still make sense
	 for the child projects.

       o In the	projA call to FetchContent_MakeAvailable(),  projD  is	listed
	 ahead	of  projB  and projC to	ensure that projA is in	control	of how
	 projD is populated.

       o While projA defines content details for projE,	it does	 not  need  to
	 explicitly   call   FetchContent_MakeAvailable(projE)	 or  FetchCon-
	 tent_Populate(projD) itself.  Instead,	it leaves that	to  the	 child
	 projB.	  For higher level projects, it	is often enough	to just	define
	 the override content details and leave	the actual population  to  the
	 child projects.  This saves repeating the same	thing at each level of
	 the project hierarchy unnecessarily.

       Projects	don't always need to add the populated content to  the	build.
       Sometimes  the project just wants to make the downloaded	content	avail-
       able at a predictable location.	The next example ensures that a	set of
       standard	 company  toolchain  files (and	potentially even the toolchain
       binaries	themselves) is available early enough to be used for that same
       build.

	  cmake_minimum_required(VERSION 3.14)

	  include(FetchContent)
	  FetchContent_Declare(
	    mycom_toolchains
	    URL	 https://intranet.mycompany.com//toolchains_1.3.2.tar.gz
	  )
	  FetchContent_MakeAvailable(mycom_toolchains)

	  project(CrossCompileExample)

       The project could be configured to use one of the downloaded toolchains
       like so:

	  cmake	-DCMAKE_TOOLCHAIN_FILE=_deps/mycom_toolchains-src/toolchain_arm.cmake /path/to/src

       When CMake processes the	CMakeLists.txt file, it	will download and  un-
       pack  the  tarball  into	_deps/mycompany_toolchains-src relative	to the
       build directory.	 The CMAKE_TOOLCHAIN_FILE variable is not  used	 until
       the  project()  command	is reached, at which point CMake looks for the
       named toolchain file relative to	the build directory.  Because the tar-
       ball  has  already  been	downloaded and unpacked	by then, the toolchain
       file will be in place, even the very first time that cmake  is  run  in
       the build directory.

       Lastly,	the  following example demonstrates how	one might download and
       unpack a	firmware tarball using	CMake's	 script	 mode.	 The  call  to
       FetchContent_Populate()	specifies  all the content details and the un-
       packed firmware will be placed in a firmware directory below  the  cur-
       rent working directory.

       getFirmware.cmake:

	  # NOTE: Intended to be run in	script mode with cmake -P
	  include(FetchContent)
	  FetchContent_Populate(
	    firmware
	    URL	       https://mycompany.com/assets/firmware-1.23-arm.tar.gz
	    URL_HASH   MD5=68247684da89b608d466253762b0ff11
	    SOURCE_DIR firmware
	  )

   FindPackageHandleStandardArgs
       This  module provides functions intended	to be used in Find Modules im-
       plementing find_package(<PackageName>) calls.

       find_package_handle_standard_args
	      This command handles the REQUIRED, QUIET and version-related ar-
	      guments of find_package().  It also sets the <PackageName>_FOUND
	      variable.	 The package is	 considered  found  if	all  variables
	      listed contain valid results, e.g. valid filepaths.

	      There are	two signatures:

		 find_package_handle_standard_args(<PackageName>
		   (DEFAULT_MSG|<custom-failure-message>)
		   <required-var>...
		   )

		 find_package_handle_standard_args(<PackageName>
		   [FOUND_VAR <result-var>]
		   [REQUIRED_VARS <required-var>...]
		   [VERSION_VAR	<version-var>]
		   [HANDLE_VERSION_RANGE]
		   [HANDLE_COMPONENTS]
		   [CONFIG_MODE]
		   [NAME_MISMATCHED]
		   [REASON_FAILURE_MESSAGE <reason-failure-message>]
		   [FAIL_MESSAGE <custom-failure-message>]
		   )

	      The  <PackageName>_FOUND variable	will be	set to TRUE if all the
	      variables	<required-var>... are  valid  and  any	optional  con-
	      straints are satisfied, and FALSE	otherwise.  A success or fail-
	      ure message may be displayed based on the	results	and on whether
	      the REQUIRED and/or QUIET	option was given to the	find_package()
	      call.

	      The options are:

	      (DEFAULT_MSG|<custom-failure-message>)
		     In	the simple signature this specifies the	 failure  mes-
		     sage.  Use	DEFAULT_MSG to ask for a default message to be
		     computed (recommended).  Not valid	in the full signature.

	      FOUND_VAR	<result-var>
		     Deprecated	since version 3.3.

		     Specifies	 either	  <PackageName>_FOUND	or   <PACKAGE-
		     NAME>_FOUND as the	result variable.  This exists only for
		     compatibility with	older versions of CMake	and is now ig-
		     nored.  Result variables of both names are	always set for
		     compatibility.

	      REQUIRED_VARS <required-var>...
		     Specify the variables which are required for  this	 pack-
		     age.  These may be	named in the generated failure message
		     asking the	user  to  set  the  missing  variable  values.
		     Therefore these should typically be cache entries such as
		     FOO_LIBRARY and not output	variables like FOO_LIBRARIES.

		     Changed in	version	3.18: If HANDLE_COMPONENTS  is	speci-
		     fied, this	option can be omitted.

	      VERSION_VAR <version-var>
		     Specify  the name of a variable that holds	the version of
		     the package that has been found.  This  version  will  be
		     checked against the (potentially) specified required ver-
		     sion given	to the find_package() call, including its  EX-
		     ACT  option.   The	 default  messages include information
		     about the required	version	and the	version	which has been
		     actually found, both if the version is ok or not.

	      HANDLE_VERSION_RANGE
		     New in version 3.19.

		     Enable  handling of a version range, if one is specified.
		     Without this option, a developer  warning	will  be  dis-
		     played if a version range is specified.

	      HANDLE_COMPONENTS
		     Enable handling of	package	components.  In	this case, the
		     command will report which components have been found  and
		     which  are	 missing, and the <PackageName>_FOUND variable
		     will be set to FALSE if any of  the  required  components
		     (i.e.  not	 the ones listed after the OPTIONAL_COMPONENTS
		     option of find_package()) are missing.

	      CONFIG_MODE
		     Specify that the calling find module is a wrapper	around
		     a	call  to  find_package(<PackageName> NO_MODULE).  This
		     implies a	VERSION_VAR  value  of	<PackageName>_VERSION.
		     The  command will automatically check whether the package
		     configuration file	was found.

	      REASON_FAILURE_MESSAGE <reason-failure-message>
		     New in version 3.16.

		     Specify a custom message of the reason  for  the  failure
		     which will	be appended to the default generated message.

	      FAIL_MESSAGE <custom-failure-message>
		     Specify a custom failure message instead of using the de-
		     fault generated message.  Not recommended.

	      NAME_MISMATCHED
		     New in version 3.17.

		     Indicate  that   the   <PackageName>   does   not	 match
		     ${CMAKE_FIND_PACKAGE_NAME}. This is usually a mistake and
		     raises a warning, but it may be intentional for usage  of
		     the command for components	of a larger package.

       Example for the simple signature:

	  find_package_handle_standard_args(LibXml2 DEFAULT_MSG
	    LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)

       The  LibXml2  package is	considered to be found if both LIBXML2_LIBRARY
       and LIBXML2_INCLUDE_DIR are valid.  Then	also LibXml2_FOUND is  set  to
       TRUE.   If  it is not found and REQUIRED	was used, it fails with	a mes-
       sage(FATAL_ERROR), independent whether QUIET was	used or	not.  If it is
       found,  success	will  be  reported, including the content of the first
       <required-var>.	On repeated CMake runs,	the same message will  not  be
       printed again.

       NOTE:
	  If  <PackageName>  does  not	match  CMAKE_FIND_PACKAGE_NAME for the
	  calling module, a warning that there is a  mismatch  is  given.  The
	  FPHSA_NAME_MISMATCHED	 variable  may be set to bypass	the warning if
	  using	the old	signature and the NAME_MISMATCHED argument  using  the
	  new signature. To avoid forcing the caller to	require	newer versions
	  of CMake for usage, the variable's value will	 be  used  if  defined
	  when	the  NAME_MISMATCHED argument is not passed for	the new	signa-
	  ture (but using both is an error)..

       Example for the full signature:

	  find_package_handle_standard_args(LibArchive
	    REQUIRED_VARS LibArchive_LIBRARY LibArchive_INCLUDE_DIR
	    VERSION_VAR	LibArchive_VERSION)

       In this case, the LibArchive package is considered to be	found if  both
       LibArchive_LIBRARY and LibArchive_INCLUDE_DIR are valid.	 Also the ver-
       sion of LibArchive will be checked by using the	version	 contained  in
       LibArchive_VERSION.   Since  no FAIL_MESSAGE is given, the default mes-
       sages will be printed.

       Another example for the full signature:

	  find_package(Automoc4	QUIET NO_MODULE	HINTS /opt/automoc4)
	  find_package_handle_standard_args(Automoc4  CONFIG_MODE)

       In this case, a FindAutmoc4.cmake module	wraps  a  call	to  find_pack-
       age(Automoc4 NO_MODULE) and adds	an additional search directory for au-
       tomoc4.	Then the call to find_package_handle_standard_args produces  a
       proper success/failure message.

       find_package_check_version
	      New in version 3.19.

	      Helper  function	which  can  be used to check if	a <version> is
	      valid against version-related arguments of find_package().

		 find_package_check_version(<version> <result-var>
		   [HANDLE_VERSION_RANGE]
		   [RESULT_MESSAGE_VARIABLE <message-var>]
		   )

	      The <result-var> will hold a boolean value giving	the result  of
	      the check.

	      The options are:

	      HANDLE_VERSION_RANGE
		     Enable  handling of a version range, if one is specified.
		     Without this option, a developer  warning	will  be  dis-
		     played if a version range is specified.

	      RESULT_MESSAGE_VARIABLE <message-var>
		     Specify  a	 variable to get back a	message	describing the
		     result of the check.

       Example for the usage:

	  find_package_check_version(1.2.3 result HANDLE_VERSION_RANGE
	    RESULT_MESSAGE_VARIABLE reason)
	  if (result)
	    message (STATUS "${reason}")
	  else()
	    message (FATAL_ERROR "${reason}")
	  endif()

   FindPackageMessage
	  find_package_message(<name> "message for user" "find result details")

       This function is	intended to be used in	FindXXX.cmake  modules	files.
       It will print a message once for	each unique find result.  This is use-
       ful for telling the user	where a	package	was found.  The	first argument
       specifies the name (XXX)	of the package.	 The second argument specifies
       the message to display.	The third argument  lists  details  about  the
       find result so that if they change the message will be displayed	again.
       The macro also obeys the	QUIET argument to the find_package command.

       Example:

	  if(X11_FOUND)
	    find_package_message(X11 "Found X11: ${X11_X11_LIB}"
	      "[${X11_X11_LIB}][${X11_INCLUDE_DIR}]")
	  else()
	   ...
	  endif()

   FortranCInterface
       Fortran/C Interface Detection

       This module automatically detects the API by which C and	 Fortran  lan-
       guages interact.

   Module Variables
       Variables that indicate if the mangling is found:

       FortranCInterface_GLOBAL_FOUND
	      Global subroutines and functions.

       FortranCInterface_MODULE_FOUND
	      Module  subroutines  and	functions  (declared by	"MODULE	PROCE-
	      DURE").

       This module also	provides the following variables to  specify  the  de-
       tected  mangling,  though a typical use case does not need to reference
       them and	can use	the Module Functions below.

       FortranCInterface_GLOBAL_PREFIX
	      Prefix for a global symbol without an underscore.

       FortranCInterface_GLOBAL_SUFFIX
	      Suffix for a global symbol without an underscore.

       FortranCInterface_GLOBAL_CASE
	      The case for a global symbol without an underscore, either UPPER
	      or LOWER.

       FortranCInterface_GLOBAL__PREFIX
	      Prefix for a global symbol with an underscore.

       FortranCInterface_GLOBAL__SUFFIX
	      Suffix for a global symbol with an underscore.

       FortranCInterface_GLOBAL__CASE
	      The case for a global symbol with	an underscore, either UPPER or
	      LOWER.

       FortranCInterface_MODULE_PREFIX
	      Prefix for a module symbol without an underscore.

       FortranCInterface_MODULE_MIDDLE
	      Middle of	a module symbol	without	an underscore that appears be-
	      tween the	name of	the module and the name	of the symbol.

       FortranCInterface_MODULE_SUFFIX
	      Suffix for a module symbol without an underscore.

       FortranCInterface_MODULE_CASE
	      The case for a module symbol without an underscore, either UPPER
	      or LOWER.

       FortranCInterface_MODULE__PREFIX
	      Prefix for a module symbol with an underscore.

       FortranCInterface_MODULE__MIDDLE
	      Middle of	a module symbol	with an	underscore  that  appears  be-
	      tween the	name of	the module and the name	of the symbol.

       FortranCInterface_MODULE__SUFFIX
	      Suffix for a module symbol with an underscore.

       FortranCInterface_MODULE__CASE
	      The case for a module symbol with	an underscore, either UPPER or
	      LOWER.

   Module Functions
       FortranCInterface_HEADER
	      The FortranCInterface_HEADER function is provided	to generate  a
	      C	header file containing macros to mangle	symbol names:

		 FortranCInterface_HEADER(<file>
					  [MACRO_NAMESPACE <macro-ns>]
					  [SYMBOL_NAMESPACE <ns>]
					  [SYMBOLS [<module>:]<function> ...])

	      It generates in <file> definitions of the	following macros:

		 #define FortranCInterface_GLOBAL (name,NAME) ...
		 #define FortranCInterface_GLOBAL_(name,NAME) ...
		 #define FortranCInterface_MODULE (mod,name, MOD,NAME) ...
		 #define FortranCInterface_MODULE_(mod,name, MOD,NAME) ...

	      These  macros mangle four	categories of Fortran symbols, respec-
	      tively:

	      o	Global symbols without '_': call mysub()

	      o	Global symbols with '_'	  : call my_sub()

	      o	Module symbols without '_': use	mymod; call mysub()

	      o	Module symbols with '_'	  : use	mymod; call my_sub()

	      If mangling for a	category is not	known, its macro is left unde-
	      fined.   All macros require raw names in both lower case and up-
	      per case.

	      The options are:

	      MACRO_NAMESPACE
		     Replace the  default  FortranCInterface_  prefix  with  a
		     given namespace <macro-ns>.

	      SYMBOLS
		     List  symbols to mangle automatically with	C preprocessor
		     definitions:

			<function>	    ==>	#define	<ns><function> ...
			<module>:<function> ==>	#define	<ns><module>_<function>	...

		     If	the mangling for some symbol is	not known then no pre-
		     processor	definition  is	created, and a warning is dis-
		     played.

	      SYMBOL_NAMESPACE
		     Prefix all	preprocessor definitions generated by the SYM-
		     BOLS option with a	given namespace	<ns>.

       FortranCInterface_VERIFY
	      The FortranCInterface_VERIFY function is provided	to verify that
	      the Fortran and C/C++ compilers work together:

		 FortranCInterface_VERIFY([CXX]	[QUIET])

	      It tests whether a simple	test executable	using  Fortran	and  C
	      (and  C++	 when the CXX option is	given) compiles	and links suc-
	      cessfully.  The result is	stored in the cache entry  FortranCIn-
	      terface_VERIFIED_C  (or FortranCInterface_VERIFIED_CXX if	CXX is
	      given) as	a boolean.  If the check fails and QUIET is not	 given
	      the  function  terminates	 with a	fatal error message describing
	      the problem.  The	purpose	of this	check is to stop a build early
	      for  incompatible	 compiler  combinations.  The test is built in
	      the Release configuration.

   Example Usage
	  include(FortranCInterface)
	  FortranCInterface_HEADER(FC.h	MACRO_NAMESPACE	"FC_")

       This creates a "FC.h" header that defines mangling macros  FC_GLOBAL(),
       FC_GLOBAL_(), FC_MODULE(), and FC_MODULE_().

	  include(FortranCInterface)
	  FortranCInterface_HEADER(FCMangle.h
				   MACRO_NAMESPACE "FC_"
				   SYMBOL_NAMESPACE "FC_"
				   SYMBOLS mysub mymod:my_sub)

       This  creates  a	 "FCMangle.h" header that defines the same FC_*() man-
       gling macros as the previous example plus preprocessor symbols FC_mysub
       and FC_mymod_my_sub.

   Additional Manglings
       FortranCInterface  is aware of possible GLOBAL and MODULE manglings for
       many Fortran compilers, but it also provides an	interface  to  specify
       new possible manglings.	Set the	variables:

	  FortranCInterface_GLOBAL_SYMBOLS
	  FortranCInterface_MODULE_SYMBOLS

       before  including FortranCInterface to specify manglings	of the symbols
       MySub, My_Sub, MyModule:MySub, and My_Module:My_Sub.  For example,  the
       code:

	  set(FortranCInterface_GLOBAL_SYMBOLS mysub_ my_sub__ MYSUB_)
	    #				       ^^^^^  ^^^^^^   ^^^^^
	  set(FortranCInterface_MODULE_SYMBOLS
	      __mymodule_MOD_mysub __my_module_MOD_my_sub)
	    #	^^^^^^^^     ^^^^^   ^^^^^^^^^	   ^^^^^^
	  include(FortranCInterface)

       tells FortranCInterface to try given GLOBAL and MODULE manglings.  (The
       carets point at raw symbol names	for clarity in this  example  but  are
       not needed.)

   GenerateExportHeader
       Function	for generation of export macros	for libraries

       This module provides the	function GENERATE_EXPORT_HEADER().

       New  in	version	3.12: Added support for	C projects.  Previous versions
       supported C++ project only.

       The GENERATE_EXPORT_HEADER function can be  used	 to  generate  a  file
       suitable	 for preprocessor inclusion which contains EXPORT macros to be
       used in library classes:

	  GENERATE_EXPORT_HEADER( LIBRARY_TARGET
		    [BASE_NAME <base_name>]
		    [EXPORT_MACRO_NAME <export_macro_name>]
		    [EXPORT_FILE_NAME <export_file_name>]
		    [DEPRECATED_MACRO_NAME <deprecated_macro_name>]
		    [NO_EXPORT_MACRO_NAME <no_export_macro_name>]
		    [INCLUDE_GUARD_NAME	<include_guard_name>]
		    [STATIC_DEFINE <static_define>]
		    [NO_DEPRECATED_MACRO_NAME <no_deprecated_macro_name>]
		    [DEFINE_NO_DEPRECATED]
		    [PREFIX_NAME <prefix_name>]
		    [CUSTOM_CONTENT_FROM_VARIABLE <variable>]
	  )

       The target properties CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HID-
       DEN  can	be used	to add the appropriate compile flags for targets.  See
       the documentation of those target properties, and the convenience vari-
       ables CMAKE_CXX_VISIBILITY_PRESET and CMAKE_VISIBILITY_INLINES_HIDDEN.

       By  default  GENERATE_EXPORT_HEADER()  generates	 macro names in	a file
       name determined by the name of the library.  This  means	 that  in  the
       simplest	case, users of GenerateExportHeader will be equivalent to:

	  set(CMAKE_CXX_VISIBILITY_PRESET hidden)
	  set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)
	  add_library(somelib someclass.cpp)
	  generate_export_header(somelib)
	  install(TARGETS somelib DESTINATION ${LIBRARY_INSTALL_DIR})
	  install(FILES
	   someclass.h
	   ${PROJECT_BINARY_DIR}/somelib_export.h DESTINATION ${INCLUDE_INSTALL_DIR}
	  )

       And in the ABI header files:

	  #include "somelib_export.h"
	  class	SOMELIB_EXPORT SomeClass {
	    ...
	  };

       The  CMake  fragment  will  generate  a file in the ${CMAKE_CURRENT_BI-
       NARY_DIR} called	somelib_export.h containing the	macros SOMELIB_EXPORT,
       SOMELIB_NO_EXPORT,  SOMELIB_DEPRECATED,	SOMELIB_DEPRECATED_EXPORT  and
       SOMELIB_DEPRECATED_NO_EXPORT.  They will	be followed by	content	 taken
       from the	variable specified by the CUSTOM_CONTENT_FROM_VARIABLE option,
       if any.	The resulting file should be installed with other  headers  in
       the library.

       The  BASE_NAME  argument	 can be	used to	override the file name and the
       names used for the macros:

	  add_library(somelib someclass.cpp)
	  generate_export_header(somelib
	    BASE_NAME other_name
	  )

       Generates a  file  called  other_name_export.h  containing  the	macros
       OTHER_NAME_EXPORT, OTHER_NAME_NO_EXPORT and OTHER_NAME_DEPRECATED etc.

       The  BASE_NAME  may  be	overridden  by specifying other	options	in the
       function.  For example:

	  add_library(somelib someclass.cpp)
	  generate_export_header(somelib
	    EXPORT_MACRO_NAME OTHER_NAME_EXPORT
	  )

       creates the macro  OTHER_NAME_EXPORT  instead  of  SOMELIB_EXPORT,  but
       other macros and	the generated file name	is as default:

	  add_library(somelib someclass.cpp)
	  generate_export_header(somelib
	    DEPRECATED_MACRO_NAME KDE_DEPRECATED
	  )

       creates the macro KDE_DEPRECATED	instead	of SOMELIB_DEPRECATED.

       If  LIBRARY_TARGET is a static library, macros are defined without val-
       ues.

       If the same sources are used to create both a shared and	a  static  li-
       brary,  the uppercased symbol ${BASE_NAME}_STATIC_DEFINE	should be used
       when building the static	library:

	  add_library(shared_variant SHARED ${lib_SRCS})
	  add_library(static_variant ${lib_SRCS})
	  generate_export_header(shared_variant	BASE_NAME libshared_and_static)
	  set_target_properties(static_variant PROPERTIES
	    COMPILE_FLAGS -DLIBSHARED_AND_STATIC_STATIC_DEFINE)

       This will cause the export macros to expand to  nothing	when  building
       the static library.

       If DEFINE_NO_DEPRECATED is specified, then a macro ${BASE_NAME}_NO_DEP-
       RECATED will be defined This macro can be  used	to  remove  deprecated
       code from preprocessor output:

	  option(EXCLUDE_DEPRECATED "Exclude deprecated	parts of the library" FALSE)
	  if (EXCLUDE_DEPRECATED)
	    set(NO_BUILD_DEPRECATED DEFINE_NO_DEPRECATED)
	  endif()
	  generate_export_header(somelib ${NO_BUILD_DEPRECATED})

       And then	in somelib:

	  class	SOMELIB_EXPORT SomeClass
	  {
	  public:
	  #ifndef SOMELIB_NO_DEPRECATED
	    SOMELIB_DEPRECATED void oldMethod();
	  #endif
	  };

	  #ifndef SOMELIB_NO_DEPRECATED
	  void SomeClass::oldMethod() {	 }
	  #endif

       If  PREFIX_NAME	is specified, the argument will	be used	as a prefix to
       all generated macros.

       For example:

	  generate_export_header(somelib PREFIX_NAME VTK_)

       Generates the macros VTK_SOMELIB_EXPORT etc.

       New in version 3.1: Library target can be an OBJECT library.

       New in version 3.7: Added the CUSTOM_CONTENT_FROM_VARIABLE option.

       New in version 3.11: Added the INCLUDE_GUARD_NAME option.

	  ADD_COMPILER_EXPORT_FLAGS( [<output_variable>] )

       Deprecated since	version	3.0: Set the  target  properties  CXX_VISIBIL-
       ITY_PRESET and VISIBILITY_INLINES_HIDDEN	instead.

       The  ADD_COMPILER_EXPORT_FLAGS  function	 adds  -fvisibility=hidden  to
       CMAKE_CXX_FLAGS if supported, and is a no-op on Windows which does  not
       need  extra  compiler  flags for	exporting support.  You	may optionally
       pass a single argument to ADD_COMPILER_EXPORT_FLAGS that	will be	 popu-
       lated  with the CXX_FLAGS required to enable visibility support for the
       compiler/architecture in	use.

   GetPrerequisites
       Deprecated since	version	3.16: Use  file(GET_RUNTIME_DEPENDENCIES)  in-
       stead.

       Functions to analyze and	list executable	file prerequisites.

       This  module  provides  functions to list the .dll, .dylib or .so files
       that an executable or shared library file depends on.   (Its  prerequi-
       sites.)

       It  uses	 various  tools	 to obtain the list of required	shared library
       files:

	  dumpbin (Windows)
	  objdump (MinGW on Windows)
	  ldd (Linux/Unix)
	  otool	(Mac OSX)

       Changed in version 3.16:	The tool specified by  CMAKE_OBJDUMP  will  be
       used, if	set.

       The following functions are provided by this module:

	  get_prerequisites
	  list_prerequisites
	  list_prerequisites_by_glob
	  gp_append_unique
	  is_file_executable
	  gp_item_default_embedded_path
	    (projects can override with	gp_item_default_embedded_path_override)
	  gp_resolve_item
	    (projects can override with	gp_resolve_item_override)
	  gp_resolved_file_type
	    (projects can override with	gp_resolved_file_type_override)
	  gp_file_type

	  GET_PREREQUISITES(<target> <prerequisites_var> <exclude_system> <recurse>
			    <exepath> <dirs> [<rpaths>])

       Get the list of shared library files required by	<target>.  The list in
       the variable named <prerequisites_var> should be	empty on  first	 entry
       to  this	 function.  On exit, <prerequisites_var> will contain the list
       of required shared library files.

       <target>	is the full path to an executable  file.   <prerequisites_var>
       is  the name of a CMake variable	to contain the results.	 <exclude_sys-
       tem> must be 0 or 1 indicating whether to include or  exclude  "system"
       prerequisites.	If  <recurse>  is  set	to 1 all prerequisites will be
       found recursively, if set to 0 only direct  prerequisites  are  listed.
       <exepath>  is  the  path	 to  the  top  level executable	used for @exe-
       cutable_path replacement	on the Mac.  <dirs> is a list of  paths	 where
       libraries  might	be found: these	paths are searched first when a	target
       without any path	info is	given.	Then  standard	system	locations  are
       also searched: PATH, Framework locations, /usr/lib...

       New  in version 3.14: The variable GET_PREREQUISITES_VERBOSE can	be set
       to true to enable verbose output.

	  LIST_PREREQUISITES(<target> [<recurse> [<exclude_system> [<verbose>]]])

       Print a message listing the prerequisites of <target>.

       <target>	is the name of a shared	library	or executable  target  or  the
       full  path to a shared library or executable file.  If <recurse>	is set
       to 1 all	prerequisites will be found recursively, if set	to 0 only  di-
       rect  prerequisites  are	listed.	 <exclude_system> must be 0 or 1 indi-
       cating whether to include  or  exclude  "system"	 prerequisites.	  With
       <verbose>  set  to  0 only the full path	names of the prerequisites are
       printed,	set to 1 extra informatin will be displayed.

	  LIST_PREREQUISITES_BY_GLOB(<glob_arg>	<glob_exp>)

       Print the prerequisites of shared library and executable	files matching
       a  globbing pattern.  <glob_arg>	is GLOB	or GLOB_RECURSE	and <glob_exp>
       is a globbing expression	used with "file(GLOB"  or  "file(GLOB_RECURSE"
       to  retrieve  a	list  of  matching  files.  If a matching file is exe-
       cutable,	its prerequisites are listed.

       Any additional (optional) arguments provided are	passed	along  as  the
       optional	arguments to the list_prerequisites calls.

	  GP_APPEND_UNIQUE(<list_var> <value>)

       Append <value> to the list variable <list_var> only if the value	is not
       already in the list.

	  IS_FILE_EXECUTABLE(<file> <result_var>)

       Return 1	in <result_var>	if <file> is a binary executable, 0 otherwise.

	  GP_ITEM_DEFAULT_EMBEDDED_PATH(<item> <default_embedded_path_var>)

       Return the path that others should refer	to the item by when  the  item
       is embedded inside a bundle.

       Override	 on  a	per-project  basis  by	providing  a  project-specific
       gp_item_default_embedded_path_override function.

	  GP_RESOLVE_ITEM(<context> <item> <exepath> <dirs> <resolved_item_var>
			  [<rpaths>])

       Resolve an item into an existing	full path file.

       Override	on a per-project basis by providing a project-specific	gp_re-
       solve_item_override function.

	  GP_RESOLVED_FILE_TYPE(<original_file>	<file> <exepath> <dirs>	<type_var>
				[<rpaths>])

       Return  the type	of <file> with respect to <original_file>.  String de-
       scribing	type of	prerequisite is	returned in variable named <type_var>.

       Use <exepath> and <dirs>	if necessary to	 resolve  non-absolute	<file>
       values -- but only for non-embedded items.

       Possible	types are:

	  system
	  local
	  embedded
	  other

       Override	 on a per-project basis	by providing a project-specific	gp_re-
       solved_file_type_override function.

	  GP_FILE_TYPE(<original_file> <file> <type_var>)

       Return the type of <file> with respect to <original_file>.  String  de-
       scribing	type of	prerequisite is	returned in variable named <type_var>.

       Possible	types are:

	  system
	  local
	  embedded
	  other

   GNUInstallDirs
       Define GNU standard installation	directories

       Provides	install	directory variables as defined by the GNU Coding Stan-
       dards.

   Result Variables
       Inclusion of this module	defines	the following variables:

       CMAKE_INSTALL_<dir>
	  Destination for files	of a given type.  This value may be passed  to
	  the  DESTINATION options of install()	commands for the corresponding
	  file type.  It should	typically be a path relative to	the  installa-
	  tion prefix so that it can be	converted to an	absolute path in a re-
	  locatable way	(see CMAKE_INSTALL_FULL_<dir>).	 However, an  absolute
	  path is also allowed.

       CMAKE_INSTALL_FULL_<dir>
	  The	absolute  path	generated  from	 the  corresponding  CMAKE_IN-
	  STALL_<dir> value.  If the value is not already an absolute path, an
	  absolute  path  is  constructed typically by prepending the value of
	  the CMAKE_INSTALL_PREFIX variable.  However, there are some  special
	  cases	as documented below.

       where <dir> is one of:

       BINDIR user executables (bin)

       SBINDIR
	      system admin executables (sbin)

       LIBEXECDIR
	      program executables (libexec)

       SYSCONFDIR
	      read-only	single-machine data (etc)

       SHAREDSTATEDIR
	      modifiable architecture-independent data (com)

       LOCALSTATEDIR
	      modifiable single-machine	data (var)

       RUNSTATEDIR
	      New in version 3.9: run-time variable data (LOCALSTATEDIR/run)

       LIBDIR object  code libraries (lib or lib64 or lib/<multiarch-tuple> on
	      Debian)

       INCLUDEDIR
	      C	header files (include)

       OLDINCLUDEDIR
	      C	header files for non-gcc (/usr/include)

       DATAROOTDIR
	      read-only	architecture-independent data root (share)

       DATADIR
	      read-only	architecture-independent data (DATAROOTDIR)

       INFODIR
	      info documentation (DATAROOTDIR/info)

       LOCALEDIR
	      locale-dependent data (DATAROOTDIR/locale)

       MANDIR man documentation	(DATAROOTDIR/man)

       DOCDIR documentation root (DATAROOTDIR/doc/PROJECT_NAME)

       If the includer does not	define a value the above-shown default will be
       used and	the value will appear in the cache for editing by the user.

   Special Cases
       New in version 3.4.

       The following values of CMAKE_INSTALL_PREFIX are	special:

       /
	  For  <dir> other than	the SYSCONFDIR,	LOCALSTATEDIR and RUNSTATEDIR,
	  the value of CMAKE_INSTALL_<dir> is prefixed with usr/ if it is  not
	  user-specified  as  an  absolute  path.  For example,	the INCLUDEDIR
	  value	include	becomes	usr/include.  This is required by the GNU Cod-
	  ing Standards, which state:
	      When  building the complete GNU system, the prefix will be empty
	      and /usr will be a symbolic link to /.

       /usr
	  For <dir> equal to SYSCONFDIR,  LOCALSTATEDIR	 or  RUNSTATEDIR,  the
	  CMAKE_INSTALL_FULL_<dir>  is	computed  by  prepending just /	to the
	  value	of CMAKE_INSTALL_<dir> if it is	not user-specified as an abso-
	  lute	path.	For  example,  the  SYSCONFDIR value etc becomes /etc.
	  This is required by the GNU Coding Standards.

       /opt/...
	  For <dir> equal to SYSCONFDIR,  LOCALSTATEDIR	 or  RUNSTATEDIR,  the
	  CMAKE_INSTALL_FULL_<dir>  is computed	by appending the prefix	to the
	  value	of CMAKE_INSTALL_<dir> if it is	not user-specified as an abso-
	  lute	 path.	  For	example,  the  SYSCONFDIR  value  etc  becomes
	  /etc/opt/....	 This is defined by the	Filesystem Hierarchy Standard.

   Macros
       GNUInstallDirs_get_absolute_install_dir

		 GNUInstallDirs_get_absolute_install_dir(absvar	var dirname)

	      New in version 3.7.

	      Set the given variable absvar to	the  absolute  path  contained
	      within the variable var.	This is	to allow the computation of an
	      absolute path, accounting	for all	the special  cases  documented
	      above.   While  this  macro  is  used  to	 compute  the  various
	      CMAKE_INSTALL_FULL_<dir> variables, it is	 exposed  publicly  to
	      allow users who create additional	path variables to also compute
	      absolute paths where necessary, using the	same  logic.   dirname
	      is the directory name to get, e.g. BINDIR.

	      Changed  in version 3.20:	Added the <dirname> parameter.	Previ-
	      ous versions of CMake passed this	 value	through	 the  variable
	      ${dir}.

   GoogleTest
       New in version 3.9.

       This  module  defines functions to help use the Google Test infrastruc-
       ture.  Two mechanisms for adding	tests are provided.  gtest_add_tests()
       has  been  around  for  some  time, originally via find_package(GTest).
       gtest_discover_tests() was introduced in	CMake 3.10.

       The (older) gtest_add_tests() scans source  files  to  identify	tests.
       This  is	 usually effective, with some caveats, including in cross-com-
       piling environments, and	makes setting additional properties  on	 tests
       more  convenient.  However, its handling	of parameterized tests is less
       comprehensive, and it requires re-running CMake to  detect  changes  to
       the list	of tests.

       The  (newer)  gtest_discover_tests() discovers tests by asking the com-
       piled test executable to	enumerate its tests.  This is more robust  and
       provides	 better	 handling of parameterized tests, and does not require
       CMake to	be re-run when tests change.  However, it may not  work	 in  a
       cross-compiling environment, and	setting	test properties	is less	conve-
       nient.

       More details can	be found in the	documentation of the respective	 func-
       tions.

       Both  commands  are  intended  to replace use of	add_test() to register
       tests, and will create a	separate CTest test for	each Google Test  test
       case.  Note that	this is	in some	cases less efficient, as common	set-up
       and tear-down logic cannot be shared by multiple	test  cases  executing
       in the same instance.  However, it provides more	fine-grained pass/fail
       information to CTest, which is usually considered as  more  beneficial.
       By  default,  the  CTest	 test name is the same as the Google Test name
       (i.e. suite.testcase); see also TEST_PREFIX and TEST_SUFFIX.

       gtest_add_tests
	      Automatically add	tests with CTest by scanning source  code  for
	      Google Test macros:

		 gtest_add_tests(TARGET	target
				 [SOURCES src1...]
				 [EXTRA_ARGS arg1...]
				 [WORKING_DIRECTORY dir]
				 [TEST_PREFIX prefix]
				 [TEST_SUFFIX suffix]
				 [SKIP_DEPENDENCY]
				 [TEST_LIST outVar]
		 )

	      gtest_add_tests  attempts	 to  identify tests by scanning	source
	      files.  Although this is generally effective, it uses only a ba-
	      sic  regular expression match, which can be defeated by atypical
	      test declarations, and is	unable to fully	"split"	 parameterized
	      tests.   Additionally,  it requires that CMake be	re-run to dis-
	      cover any	newly added, removed or	 renamed  tests	 (by  default,
	      this  means  that	 CMake	is re-run when any test	source file is
	      changed, but see SKIP_DEPENDENCY).  However, it has  the	advan-
	      tage of declaring	tests at CMake time, which somewhat simplifies
	      setting additional properties on tests, and always  works	 in  a
	      cross-compiling environment.

	      The options are:

	      TARGET target
		     Specifies	the  Google  Test  executable, which must be a
		     known CMake executable target.  CMake will	substitute the
		     location of the built executable when running the test.

	      SOURCES src1...
		     When  provided, only the listed files will	be scanned for
		     test cases.  If this option is  not  given,  the  SOURCES
		     property  of  the specified target	will be	used to	obtain
		     the list of sources.

	      EXTRA_ARGS arg1...
		     Any extra arguments to pass on the	command	line  to  each
		     test case.

	      WORKING_DIRECTORY	dir
		     Specifies	the  directory	in which to run	the discovered
		     test cases.  If this option is not	provided, the  current
		     binary directory is used.

	      TEST_PREFIX prefix
		     Specifies	a  prefix  to be prepended to the name of each
		     discovered	test case.  This can be	useful when  the  same
		     source   files  are  being	 used  in  multiple  calls  to
		     gtest_add_test() but with different EXTRA_ARGS.

	      TEST_SUFFIX suffix
		     Similar to	TEST_PREFIX except the suffix is  appended  to
		     the name of every discovered test case.  Both TEST_PREFIX
		     and TEST_SUFFIX may be specified.

	      SKIP_DEPENDENCY
		     Normally, the function creates a  dependency  which  will
		     cause  CMake  to  be  re-run  if any of the sources being
		     scanned are changed.  This	is to ensure that the list  of
		     discovered	tests is updated.  If this behavior is not de-
		     sired (as may be the case while actually writing the test
		     cases), this option can be	used to	prevent	the dependency
		     from being	added.

	      TEST_LIST	outVar
		     The variable named	by outVar will	be  populated  in  the
		     calling  scope  with  the	list of	discovered test	cases.
		     This allows the caller to do things like manipulate  test
		     properties	of the discovered tests.

	      Usage example:

		 include(GoogleTest)
		 add_executable(FooTest	FooUnitTest.cxx)
		 gtest_add_tests(TARGET	     FooTest
				 TEST_SUFFIX .noArgs
				 TEST_LIST   noArgsTests
		 )
		 gtest_add_tests(TARGET	     FooTest
				 EXTRA_ARGS  --someArg someValue
				 TEST_SUFFIX .withArgs
				 TEST_LIST   withArgsTests
		 )
		 set_tests_properties(${noArgsTests}   PROPERTIES TIMEOUT 10)
		 set_tests_properties(${withArgsTests} PROPERTIES TIMEOUT 20)

	      For  backward  compatibility,  the  following  form is also sup-
	      ported:

		 gtest_add_tests(exe args files...)

	      exe    The path to the test executable or	the name  of  a	 CMake
		     target.

	      args   A	;-list	of extra arguments to be passed	to executable.
		     The entire	list must be passed as a single	argument.  En-
		     close it in quotes, or pass "" for	no arguments.

	      files...
		     A	list of	source files to	search for tests and test fix-
		     tures.  Alternatively, use	AUTO to	specify	 that  exe  is
		     the  name	of  a  CMake  executable  target whose sources
		     should be scanned.

		 include(GoogleTest)
		 set(FooTestArgs --foo 1 --bar 2)
		 add_executable(FooTest	FooUnitTest.cxx)
		 gtest_add_tests(FooTest "${FooTestArgs}" AUTO)

       gtest_discover_tests
	      Automatically add	tests with CTest by querying the compiled test
	      executable for available tests:

		 gtest_discover_tests(target
				      [EXTRA_ARGS arg1...]
				      [WORKING_DIRECTORY dir]
				      [TEST_PREFIX prefix]
				      [TEST_SUFFIX suffix]
				      [NO_PRETTY_TYPES]	[NO_PRETTY_VALUES]
				      [PROPERTIES name1	value1...]
				      [TEST_LIST var]
				      [DISCOVERY_TIMEOUT seconds]
				      [XML_OUTPUT_DIR dir]
				      [DISCOVERY_MODE <POST_BUILD|PRE_TEST>]
		 )

	      New in version 3.10.

	      gtest_discover_tests()  sets up a	post-build command on the test
	      executable that generates	the list of tests by parsing the  out-
	      put  from	running	the test with the --gtest_list_tests argument.
	      Compared to the source parsing  approach	of  gtest_add_tests(),
	      this  ensures  that the full list	of tests, including instantia-
	      tions of parameterized tests, is obtained.  Since	test discovery
	      occurs  at  build	time, it is not	necessary to re-run CMake when
	      the list of tests	changes.  However, it requires that  CROSSCOM-
	      PILING_EMULATOR  is  properly  set  in  order  to	 function in a
	      cross-compiling environment.

	      Additionally, setting properties on tests	is somewhat less  con-
	      venient, since the tests are not available at CMake time.	 Addi-
	      tional test properties may be assigned to	the set	of tests as  a
	      whole  using  the	 PROPERTIES option.  If	more fine-grained test
	      control is needed, custom	content	may be provided	through	an ex-
	      ternal CTest script using	the TEST_INCLUDE_FILES directory prop-
	      erty.  The set of	discovered tests is made accessible to such  a
	      script via the <target>_TESTS variable.

	      The options are:

	      target Specifies	the  Google  Test  executable, which must be a
		     known CMake executable target.  CMake will	substitute the
		     location of the built executable when running the test.

	      EXTRA_ARGS arg1...
		     Any  extra	 arguments to pass on the command line to each
		     test case.

	      WORKING_DIRECTORY	dir
		     Specifies the directory in	which to  run  the  discovered
		     test  cases.  If this option is not provided, the current
		     binary directory is used.

	      TEST_PREFIX prefix
		     Specifies a prefix	to be prepended	to the	name  of  each
		     discovered	 test  case.  This can be useful when the same
		     test executable  is  being	 used  in  multiple  calls  to
		     gtest_discover_tests() but	with different EXTRA_ARGS.

	      TEST_SUFFIX suffix
		     Similar  to  TEST_PREFIX except the suffix	is appended to
		     the name of every discovered test case.  Both TEST_PREFIX
		     and TEST_SUFFIX may be specified.

	      NO_PRETTY_TYPES
		     By	default, the type index	of type-parameterized tests is
		     replaced by the actual type name in the CTest test	 name.
		     If	 this  behavior	 is undesirable	(e.g. because the type
		     names are unwieldy), this option will suppress  this  be-
		     havior.

	      NO_PRETTY_VALUES
		     By	 default, the value index of value-parameterized tests
		     is	replaced by the	actual value in	the CTest  test	 name.
		     If	 this  behavior	is undesirable (e.g. because the value
		     strings are unwieldy), this option	will suppress this be-
		     havior.

	      PROPERTIES name1 value1...
		     Specifies	additional  properties	to be set on all tests
		     discovered	by this	invocation of gtest_discover_tests().

	      TEST_LIST	var
		     Make the list of tests available  in  the	variable  var,
		     rather than the default <target>_TESTS.  This can be use-
		     ful when the same test executable is being	used in	multi-
		     ple  calls	 to  gtest_discover_tests().   Note  that this
		     variable is only available	in CTest.

	      DISCOVERY_TIMEOUT	num
		     New in version 3.10.3.

		     Specifies how long	(in seconds) CMake will	wait  for  the
		     test  to  enumerate  available  tests.  If	the test takes
		     longer than this, discovery (and your build)  will	 fail.
		     Most  test	 executables  will  enumerate their tests very
		     quickly, but under	some exceptional circumstances,	a test
		     may  require  a  longer  timeout.	The default is 5.  See
		     also the TIMEOUT option of	execute_process().

		     NOTE:
			In CMake versions 3.10.1 and 3.10.2, this  option  was
			called	TIMEOUT.   This	 clashed with the TIMEOUT test
			property, which	is one of the common  properties  that
			would  be  set	with  the  PROPERTIES keyword, usually
			leading	to legal but unintended	behavior.  The keyword
			was  changed  to  DISCOVERY_TIMEOUT in CMake 3.10.3 to
			address	this problem.  The ambiguous behavior  of  the
			TIMEOUT	keyword	in 3.10.1 and 3.10.2 has not been pre-
			served.

	      XML_OUTPUT_DIR dir
		     New in version 3.18.

		     If	 specified,  the  parameter  is	 passed	  along	  with
		     --gtest_output=xml:  to  test executable. The actual file
		     name is the same as the test target, including prefix and
		     suffix.   This  should  be	 used  instead	of  EXTRA_ARGS
		     --gtest_output=xml	to avoid race conditions  writing  the
		     XML result	output when using parallel test	execution.

	      DISCOVERY_MODE
		     New in version 3.18.

		     Provides greater control over when	gtest_discover_tests()
		     performs test discovery. By default, POST_BUILD sets up a
		     post-build	 command  to  perform  test discovery at build
		     time. In certain scenarios,  like	cross-compiling,  this
		     POST_BUILD	 behavior  is  not  desirable.	 By  contrast,
		     PRE_TEST delays test discovery until just prior  to  test
		     execution.	 This  way test	discovery occurs in the	target
		     environment where the test	has a better chance at finding
		     appropriate runtime dependencies.

		     DISCOVERY_MODE    defaults	   to	the   value   of   the
		     CMAKE_GTEST_DISCOVER_TESTS_DISCOVERY_MODE variable	if  it
		     is	 not  passed when calling gtest_discover_tests(). This
		     provides a	mechanism for globally selecting  a  preferred
		     test  discovery  behavior	without	 having	to modify each
		     call site.

   InstallRequiredSystemLibraries
       Include this module to search for compiler-provided system runtime  li-
       braries and add install rules for them.	Some optional variables	may be
       set prior to including the module to adjust behavior:

       CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS
	      Specify additional runtime libraries that	may not	 be  detected.
	      After inclusion any detected libraries will be appended to this.

       CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP
	      Set to TRUE to skip calling the install(PROGRAMS)	command	to al-
	      low the includer to specify its  own  install  rule,  using  the
	      value  of	 CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS  to get the list of
	      libraries.

       CMAKE_INSTALL_DEBUG_LIBRARIES
	      Set to TRUE to install the debug runtime libraries  when	avail-
	      able with	MSVC tools.

       CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY
	      Set  to  TRUE  to	 install only the debug	runtime	libraries with
	      MSVC tools even if the release runtime libraries are also	avail-
	      able.

       CMAKE_INSTALL_UCRT_LIBRARIES
	      New in version 3.6.

	      Set  to  TRUE to install the Windows Universal CRT libraries for
	      app-local	deployment (e.g. to Windows XP).  This	is  meaningful
	      only with	MSVC from Visual Studio	2015 or	higher.

	      New  in version 3.9: One may set a CMAKE_WINDOWS_KITS_10_DIR en-
	      vironment	variable to an absolute	path to	tell CMake to look for
	      Windows  10  SDKs	in a custom location.  The specified directory
	      is expected to contain Redist/ucrt/DLLs/*	directories.

       CMAKE_INSTALL_MFC_LIBRARIES
	      Set to TRUE to install the MSVC MFC runtime libraries.

       CMAKE_INSTALL_OPENMP_LIBRARIES
	      Set to TRUE to install the MSVC OpenMP runtime libraries

       CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION
	      Specify the install(PROGRAMS) command  DESTINATION  option.   If
	      not specified, the default is bin	on Windows and lib elsewhere.

       CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS
	      Set  to  TRUE  to	 disable warnings about	required library files
	      that do not exist.  (For example,	Visual Studio Express editions
	      may not provide the redistributable files.)

       CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT
	      New in version 3.3.

	      Specify  the install(PROGRAMS) command COMPONENT option.	If not
	      specified, no such option	will be	used.

       New in version 3.10: Support for	installing Intel compiler runtimes.

   ProcessorCount
       ProcessorCount(var)

       Determine the number of processors/cores	and save value in ${var}

       Sets the	variable named ${var} to the number of physical	 cores	avail-
       able on the machine if the information can be determined.  Otherwise it
       is set to 0.  Currently this functionality is implemented for AIX, cyg-
       win, FreeBSD, HPUX, Linux, macOS, QNX, Sun and Windows.

       Changed	in version 3.15: On Linux, returns the container CPU count in-
       stead of	the host CPU count.

       This function is	guaranteed to return a positive	integer	 (>=1)	if  it
       succeeds.   It returns 0	if there's a problem determining the processor
       count.

       Example use, in a ctest -S dashboard script:

	  include(ProcessorCount)
	  ProcessorCount(N)
	  if(NOT N EQUAL 0)
	    set(CTEST_BUILD_FLAGS -j${N})
	    set(ctest_test_args	${ctest_test_args} PARALLEL_LEVEL ${N})
	  endif()

       This function is	intended to offer an approximation of the value	of the
       number of compute cores available on the	current	machine, such that you
       may use that value for parallel building	and parallel testing.	It  is
       meant  to  help utilize as much of the machine as seems reasonable.  Of
       course, knowledge of what else might be running on the machine simulta-
       neously	should	be  used  when deciding	whether	to request a machine's
       full capacity all for yourself.

   SelectLibraryConfigurations
	  select_library_configurations(basename)

       This macro takes	a library base name as an argument,  and  will	choose
       good values for the variables

	  basename_LIBRARY
	  basename_LIBRARIES
	  basename_LIBRARY_DEBUG
	  basename_LIBRARY_RELEASE

       depending on what has been found	and set.

       If  only	 basename_LIBRARY_RELEASE is defined, basename_LIBRARY will be
       set to the release value, and basename_LIBRARY_DEBUG  will  be  set  to
       basename_LIBRARY_DEBUG-NOTFOUND.	 If only basename_LIBRARY_DEBUG	is de-
       fined, then basename_LIBRARY will  take	the  debug  value,  and	 base-
       name_LIBRARY_RELEASE will be set	to basename_LIBRARY_RELEASE-NOTFOUND.

       If  the	generator  supports configuration types, then basename_LIBRARY
       and basename_LIBRARIES will be set with debug and optimized flags spec-
       ifying the library to be	used for the given configuration.  If no build
       type has	been set or the	generator in use does not  support  configura-
       tion types, then	basename_LIBRARY and basename_LIBRARIES	will take only
       the release value, or the debug value if	the release one	is not set.

   SquishTestScript
       This script launches a GUI test using Squish.  You should not call  the
       script  directly; instead, you should access it via the SQUISH_ADD_TEST
       macro that is defined in	FindSquish.cmake.

       This script starts the Squish server, launches the test on the  client,
       and  finally  stops the squish server.  If any of these steps fail (in-
       cluding if the tests do not pass) then a	fatal error is raised.

   TestBigEndian
       Deprecated since	version	3.20: Supserseded by the CMAKE_<LANG>_BYTE_OR-
       DER variable.

       Check if	the target architecture	is big endian or little	endian.

       test_big_endian

		 test_big_endian(<var>)

	      Stores  in  variable  <var> either 1 or 0	indicating whether the
	      target architecture is big or little endian.

   TestForANSIForScope
       Check for ANSI for scope	support

       Check if	the compiler restricts the scope of variables  declared	 in  a
       for-init-statement to the loop body.

	  CMAKE_NO_ANSI_FOR_SCOPE - holds result

   TestForANSIStreamHeaders
       Test for	compiler support of ANSI stream	headers	iostream, etc.

       check if	the compiler supports the standard ANSI	iostream header	(with-
       out the .h)

	  CMAKE_NO_ANSI_STREAM_HEADERS - defined by the	results

   TestForSSTREAM
       Test for	compiler support of ANSI sstream header

       check if	the compiler supports the standard ANSI	sstream	header

	  CMAKE_NO_ANSI_STRING_STREAM -	defined	by the results

   TestForSTDNamespace
       Test for	std:: namespace	support

       check if	the compiler supports std:: on stl classes

	  CMAKE_NO_STD_NAMESPACE - defined by the results

   UseEcos
       This module defines variables and macros	required to build eCos	appli-
       cation.

       This file contains the following	macros:	ECOS_ADD_INCLUDE_DIRECTORIES()
       - add  the  eCos	 include  dirs	ECOS_ADD_EXECUTABLE(name  source1  ...
       sourceN ) - create an eCos executable ECOS_ADJUST_DIRECTORY(VAR source1
       ...  sourceN ) -	adjusts	the path of the	source files and puts the  re-
       sult into VAR

       Macros  for  selecting the toolchain: ECOS_USE_ARM_ELF_TOOLS() -	enable
       the  ARM	 ELF  toolchain	 for  the  directory  where   it   is	called
       ECOS_USE_I386_ELF_TOOLS()  -  enable the	i386 ELF toolchain for the di-
       rectory where it	is called ECOS_USE_PPC_EABI_TOOLS() - enable the  Pow-
       erPC toolchain for the directory	where it is called

       It  contains  the following variables: ECOS_DEFINITIONS ECOSCONFIG_EXE-
       CUTABLE ECOS_CONFIG_FILE	- defaults to ecos.ecc,	if your	eCos  configu-
       ration file has a different name, adjust	this variable for internal use
       only:

	  ECOS_ADD_TARGET_LIB

   UseJava
       Use Module for Java

       This file provides functions for	Java.  It is assumed that FindJava has
       already	been loaded.  See FindJava for information on how to load Java
       into your CMake project.

   Creating And	Installing JARs
	  add_jar(<target_name>
		  [SOURCES] <source1> [<source2>...] [<resource1>...]
		  [INCLUDE_JARS	<jar1> [<jar2>...]]
		  [ENTRY_POINT <entry>]
		  [VERSION <version>]
		  [OUTPUT_NAME <name>]
		  [OUTPUT_DIR <dir>]
		  [GENERATE_NATIVE_HEADERS <target>
				     [DESTINATION (<dir>|INSTALL <dir> [BUILD <dir>])]]
		  )

       This command  creates  a	 <target_name>.jar.   It  compiles  the	 given
       <source>	 files	and  adds  the given <resource>	files to the jar file.
       Source files can	be java	files or listing files (prefixed  by  @).   If
       only  resource  files  are  given then just a jar file is created.  The
       list of INCLUDE_JARS are	added to the classpath when compiling the java
       sources	and also to the	dependencies of	the target.  INCLUDE_JARS also
       accepts other target names created by add_jar().	 For backwards compat-
       ibility,	 jar  files  listed  as	sources	are ignored (as	they have been
       since the first version of this module).

       New in version 3.4: Support for response	files (prefixed	by @)  in  the
       SOURCES list.

       The  default  OUTPUT_DIR	 can  also  be changed by setting the variable
       CMAKE_JAVA_TARGET_OUTPUT_DIR.

       New in version 3.11: Optionally,	using option  GENERATE_NATIVE_HEADERS,
       native  header  files  can be generated for methods declared as native.
       These files provide the connective glue that allow your Java and	C code
       to  interact.  An INTERFACE target will be created for an easy usage of
       generated files.	 Sub-option DESTINATION	can be	used  to  specify  the
       output directory	for generated header files.

       GENERATE_NATIVE_HEADERS	option	requires, at least, version 1.8	of the
       JDK.

       New in version 3.20: DESTINATION	sub-option now supports	the  possibil-
       ity  to	specify	 different  output  directories	 for BUILD and INSTALL
       steps. This is required to export the  interface	 target	 generated  by
       GENERATE_NATIVE_HEADERS option.	If BUILD directory is not specified, a
       default directory will be used.

       The add_jar() function sets the following target	 properties  on	 <tar-
       get_name>:

       INSTALL_FILES
	      The  files  which	 should	 be  installed.	  This	is used	by in-
	      stall_jar().

       JNI_SYMLINK
	      The JNI symlink which should be installed.  This is used by  in-
	      stall_jni_symlink().

       JAR_FILE
	      The location of the jar file so that you can include it.

       CLASSDIR
	      The  directory  where the	class files can	be found.  For example
	      to use them with javah.

       New in version  3.20:  The  target  generated  by  option  GENERATE_NA-
       TIVE_HEADERS  has  the  property	NATIVE_HEADERS_DIRECTORY which specify
       the directory holding the native	headers.

	  install_jar(<target_name> <destination>)
	  install_jar(<target_name> DESTINATION	<destination> [COMPONENT <component>])

       This command installs the <target_name> files to	 the  given  <destina-
       tion>.	It  should be called in	the same scope as add_jar() or it will
       fail.

       The install_jar() function sets the INSTALL_DESTINATION target property
       on  jars	 so  installed.	  This property	holds the <destination>	as de-
       scribed above, and is used by install_jar_exports().  You can get  this
       information  with  get_property()  and the INSTALL_DESTINATION property
       key.

       New in version 3.4: The second signature	with DESTINATION and COMPONENT
       options.

	  install_jni_symlink(<target_name> <destination>)
	  install_jni_symlink(<target_name> DESTINATION	<destination> [COMPONENT <component>])

       This command installs the <target_name> JNI symlinks to the given <des-
       tination>.  It should be	called in the same scope as  add_jar()	or  it
       will fail.

       New in version 3.4: The second signature	with DESTINATION and COMPONENT
       options.

   Exporting JAR Targets
       New in version 3.7.

	  install_jar_exports(TARGETS <jars>...
			      [NAMESPACE <namespace>]
			      FILE <filename>
			      DESTINATION <destination>	[COMPONENT <component>])

       This command installs a target export file <filename> for the named jar
       targets	to the given <destination> directory.  Its function is similar
       to that of install(EXPORTS).

       New in version 3.9: The NAMESPACE option.

	  export_jars(TARGETS <jars>...
		      [NAMESPACE <namespace>]
		      FILE <filename>)

       This command writes a target  export  file  <filename>  for  the	 named
       <jars> targets.	Its function is	similar	to that	of export().

       New in version 3.9: The NAMESPACE option.

   Examples
       To  add	compile	 flags	to the target you can set these	flags with the
       following variable:

	  set(CMAKE_JAVA_COMPILE_FLAGS -nowarn)

       To add a	path or	a jar file to the class	path you can do	this with  the
       CMAKE_JAVA_INCLUDE_PATH variable.

	  set(CMAKE_JAVA_INCLUDE_PATH /usr/share/java/shibboleet.jar)

       To use a	different output name for the target you can set it with:

	  add_jar(foobar foobar.java OUTPUT_NAME shibboleet.jar)

       To  use	a different output directory than CMAKE_CURRENT_BINARY_DIR you
       can set it with:

	  add_jar(foobar foobar.java OUTPUT_DIR	${PROJECT_BINARY_DIR}/bin)

       To define an entry point	in your	jar  you  can  set  it	with  the  EN-
       TRY_POINT named argument:

	  add_jar(example ENTRY_POINT com/examples/MyProject/Main)

       To  define a custom manifest for	the jar, you can set it	with the MANI-
       FEST named argument:

	  add_jar(example MANIFEST /path/to/manifest)

       To add a	version	to the target output name you can  set	it  using  the
       VERSION named argument to add_jar().  The following example will	create
       a jar file with the name	shibboleet-1.0.0.jar and will create a symlink
       shibboleet.jar pointing to the jar with the version information.

	  add_jar(shibboleet shibbotleet.java VERSION 1.2.0)

       If  the target is a JNI library,	utilize	the following commands to cre-
       ate a JNI symbolic link:

	  set(CMAKE_JNI_TARGET TRUE)
	  add_jar(shibboleet shibbotleet.java VERSION 1.2.0)
	  install_jar(shibboleet ${LIB_INSTALL_DIR}/shibboleet)
	  install_jni_symlink(shibboleet ${JAVA_LIB_INSTALL_DIR})

       If a single target needs	to produce more	than one  jar  from  its  java
       source  code,  to  prevent the accumulation of duplicate	class files in
       subsequent jars,	set/reset CMAKE_JAR_CLASSES_PREFIX  prior  to  calling
       the add_jar() function:

	  set(CMAKE_JAR_CLASSES_PREFIX com/redhat/foo)
	  add_jar(foo foo.java)

	  set(CMAKE_JAR_CLASSES_PREFIX com/redhat/bar)
	  add_jar(bar bar.java)

       For  an	optimum	 usage of option GENERATE_NATIVE_HEADERS, it is	recom-
       mended to include module	JNI before any call to add_jar(). The produced
       target  for  native  headers  can then be used to compile C/C++ sources
       with the	target_link_libraries()	command.

	  find_package(JNI)
	  add_jar(foo foo.java GENERATE_NATIVE_HEADERS foo-native)
	  add_library(bar bar.cpp)
	  target_link_libraries(bar PRIVATE foo-native)

       New in version 3.20: It is now possible to export the target  generated
       by GENERATE_NATIVE_HEADERS option.

	  add_jar(foo foo.java GENERATE_NATIVE_HEADERS foo-native
						       DESTINATION INSTALL include)
	  install(TARGETS foo-native EXPORT native)
	  install(DIRECTORY "$<TARGET_PROPERTY:foo-native,NATIVE_HEADERS_DIRECTORY>/"
		  DESTINATION include)
	  install(EXPORT native	DESTINATION /to/export NAMESPACE foo)

   Finding JARs
	  find_jar(<VAR>
		   <name> | NAMES <name1> [<name2>...]
		   [PATHS <path1> [<path2>... ENV <var>]]
		   [VERSIONS <version1>	[<version2>]]
		   [DOC	"cache documentation string"]
		  )

       This command is used to find a full path	to the named jar.  A cache en-
       try named by <VAR> is created to	store the result of this command.   If
       the  full  path	to a jar is found the result is	stored in the variable
       and the search will not repeated	unless the variable  is	 cleared.   If
       nothing	is  found,  the	 result	will be	<VAR>-NOTFOUND,	and the	search
       will be attempted again next time find_jar() 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 NAMES argument.  Additional	search
       locations  can  be  specified after the PATHS argument.	If you require
       special a version of a jar file you can specify it  with	 the  VERSIONS
       argument.   The	argument  after	DOC will be used for the documentation
       string in the cache.

   Javadoc
       The create_javadoc() command can	be used	to create  java	 documentation
       based  on  files	or packages.  For more details please read the javadoc
       manpage.

       There are two main signatures for create_javadoc().  The	 first	signa-
       ture works with package names on	a path with source files.

	  create_javadoc(<VAR>
			 PACKAGES <pkg1> [<pkg2>...]
			 [SOURCEPATH <sourcepath>]
			 [CLASSPATH <classpath>]
			 [INSTALLPATH <install path>]
			 [DOCTITLE "the	documentation title"]
			 [WINDOWTITLE "the title of the	document"]
			 [AUTHOR TRUE|FALSE]
			 [USE TRUE|FALSE]
			 [VERSION TRUE|FALSE]
			 )

       For example:

	  create_javadoc(my_example_doc
	    PACKAGES com.example.foo com.example.bar
	    SOURCEPATH "${CMAKE_CURRENT_SOURCE_DIR}"
	    CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
	    WINDOWTITLE	"My example"
	    DOCTITLE "<h1>My example</h1>"
	    AUTHOR TRUE
	    USE	TRUE
	    VERSION TRUE
	  )

       The  second  signature  for  create_javadoc()  works on a given list of
       files.

	  create_javadoc(<VAR>
			 FILES <file1> [<file2>...]
			 [CLASSPATH <classpath>]
			 [INSTALLPATH <install path>]
			 [DOCTITLE "the	documentation title"]
			 [WINDOWTITLE "the title of the	document"]
			 [AUTHOR TRUE|FALSE]
			 [USE TRUE|FALSE]
			 [VERSION TRUE|FALSE]
			)

       For example:

	  create_javadoc(my_example_doc
	    FILES ${example_SRCS}
	    CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
	    WINDOWTITLE	"My example"
	    DOCTITLE "<h1>My example</h1>"
	    AUTHOR TRUE
	    USE	TRUE
	    VERSION TRUE
	  )

       Both signatures share most of the options.  These options are the  same
       as  what	 you can find in the javadoc manpage.  Please look at the man-
       page for	CLASSPATH, DOCTITLE, WINDOWTITLE, AUTHOR, USE and VERSION.

       If you don't set	the INSTALLPATH, then  by  default  the	 documentation
       will be installed to :

	  ${CMAKE_INSTALL_PREFIX}/share/javadoc/<VAR>

   Header Generation
	  create_javah(TARGET <target> | GENERATED_FILES <VAR>
		       CLASSES <class>...
		       [CLASSPATH <classpath>...]
		       [DEPENDS	<depend>...]
		       [OUTPUT_NAME <path>|OUTPUT_DIR <path>]
		       )

       New in version 3.4.

       Deprecated since	version	3.11: This command will	no longer be supported
       starting	with version 10	of the JDK due to  the	suppression  of	 javah
       tool.   The add_jar(GENERATE_NATIVE_HEADERS) command should be used in-
       stead.

       Create C	header files from java classes.	These files provide  the  con-
       nective glue that allow your Java and C code to interact.

       There  are two main signatures for create_javah().  The first signature
       returns generated  files	 through  variable  specified  by  the	GENER-
       ATED_FILES option.  For example:

	  create_javah(GENERATED_FILES files_headers
	    CLASSES org.cmake.HelloWorld
	    CLASSPATH hello.jar
	  )

       The second signature for	create_javah() creates a target	which encapsu-
       lates header files generation. E.g.

	  create_javah(TARGET target_headers
	    CLASSES org.cmake.HelloWorld
	    CLASSPATH hello.jar
	  )

       Both signatures share same options.

       CLASSES <class>...
	      Specifies	Java classes used to generate headers.

       CLASSPATH <classpath>...
	      Specifies	various	paths to look up classes. Here	.class	files,
	      jar files	or targets created by command add_jar can be used.

       DEPENDS <depend>...
	      Targets on which the javah target	depends.

       OUTPUT_NAME <path>
	      Concatenates  the	 resulting  header  files  for all the classes
	      listed by	option CLASSES into <path>.  Same behavior  as	option
	      -o of javah tool.

       OUTPUT_DIR <path>
	      Sets  the	 directory  where  the header files will be generated.
	      Same behavior as option -d of javah  tool.   If  not  specified,
	      CMAKE_CURRENT_BINARY_DIR is used as the output directory.

   UseSWIG
       This file provides support for SWIG. It is assumed that FindSWIG	module
       has already been	loaded.

       Defines the following command for use with SWIG:

       swig_add_library
	      New in version 3.8.

	      Define swig module with given name and specified language:

		 swig_add_library(<name>
				  [TYPE	<SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>]
				  LANGUAGE <language>
				  [NO_PROXY]
				  [OUTPUT_DIR <directory>]
				  [OUTFILE_DIR <directory>]
				  SOURCES <file>...
				 )

	      Targets created with the swig_add_library	command	have the  same
	      capabilities  as targets created with the	add_library() command,
	      so those targets can be used with	any command expecting a	target
	      (e.g.  target_link_libraries()).

	      Changed  in version 3.13:	This command creates a target with the
	      specified	<name> when policy CMP0078 is set to NEW.   Otherwise,
	      the  legacy  behavior  will  choose  a different target name and
	      store it in the SWIG_MODULE_<name>_REAL_NAME variable.

	      Changed in version 3.15: Alternate library name  (set  with  the
	      OUTPUT_NAME  property,  for example) will	be passed on to	Python
	      and CSharp wrapper libraries.

	      NOTE:
		 For multi-config generators, this  module  does  not  support
		 configuration-specific	 files	generated  by  SWIG. All build
		 configurations	must result in the same	generated source file.

	      NOTE:
		 For  Makefile	Generators,  if,   for	 some	sources,   the
		 USE_SWIG_DEPENDENCIES	property  is  FALSE,  swig_add_library
		 does  not  track  file	 dependencies,	so  depending  on  the
		 <name>_swig_compilation custom	target is required for targets
		 which require the swig-generated files	to exist. Other	gener-
		 ators	may depend on the source files that would be generated
		 by SWIG.

	      TYPE   SHARED, MODULE and	STATIC have the	same semantic  as  for
		     the  add_library()	 command.  If USE_BUILD_SHARED_LIBS is
		     specified,	the library type  will	be  STATIC  or	SHARED
		     based    on    whether   the   current   value   of   the
		     BUILD_SHARED_LIBS variable	is ON. If no  type  is	speci-
		     fied, MODULE will be used.

	      LANGUAGE
		     Specify the target	language.

		     New in version 3.1: Go and	Lua language support.

		     New in version 3.2: R language support.

		     New in version 3.18: Fortran language support.

	      NO_PROXY
		     New in version 3.12.

		     Prevent  the  generation  of the wrapper layer (swig -no-
		     proxy option).

	      OUTPUT_DIR
		     New in version 3.12.

		     Specify where to write the	language specific files	 (swig
		     -outdir  option).	If  not	 given,	 the CMAKE_SWIG_OUTDIR
		     variable will be used.  If	neither	is specified, the  de-
		     fault  depends on the value of the	UseSWIG_MODULE_VERSION
		     variable as follows:

		     o If UseSWIG_MODULE_VERSION is 1 or is undefined,	output
		       is written to the CMAKE_CURRENT_BINARY_DIR directory.

		     o If  UseSWIG_MODULE_VERSION  is 2, a dedicated directory
		       will be used.  The path of this directory  can  be  re-
		       trieved	from  the  SWIG_SUPPORT_FILES_DIRECTORY	target
		       property.

	      OUTFILE_DIR
		     New in version 3.12.

		     Specify an	output	directory  name	 where	the  generated
		     source file will be placed	(swig -o option). If not spec-
		     ified, the	SWIG_OUTFILE_DIR variable  will	 be  used.  If
		     neither  is specified, OUTPUT_DIR or CMAKE_SWIG_OUTDIR is
		     used instead.

	      SOURCES
		     List of sources for the library. Files with extension  .i
		     will  be  identified  as sources for the SWIG tool. Other
		     files will	be handled in the standard way.

		     New in version 3.14: This behavior	can be	overridden  by
		     specifying	the variable SWIG_SOURCE_FILE_EXTENSIONS.

	      NOTE:
		 If  UseSWIG_MODULE_VERSION is set to 2, it is strongly	recom-
		 mended	to use a dedicated directory unique to the target when
		 either	 the  OUTPUT_DIR option	or the CMAKE_SWIG_OUTDIR vari-
		 able are specified.  The output directory contents are	erased
		 as  part  of the target build,	so to prevent interference be-
		 tween targets or losing other important  files,  each	target
		 should	have its own dedicated output directory.

       swig_link_libraries
	      Link libraries to	swig module:

		 swig_link_libraries(<name> <item>...)

	      This  command  has  same capabilities as target_link_libraries()
	      command.

	      NOTE:
		 If variable UseSWIG_TARGET_NAME_PREFERENCE is	set  to	 STAN-
		 DARD,	this command is	deprecated and target_link_libraries()
		 command must be used instead.

       Source file properties on module	files must be set before  the  invoca-
       tion  of	 the  swig_add_library	command	to specify special behavior of
       SWIG and	ensure generated files will receive the	required settings.

       CPLUSPLUS
	      Call SWIG	in c++ mode.  For example:

		 set_property(SOURCE mymod.i PROPERTY CPLUSPLUS	ON)
		 swig_add_library(mymod	LANGUAGE python	SOURCES	mymod.i)

       SWIG_FLAGS
	      Deprecated since version 3.12: Replaced  with  the  fine-grained
	      properties that follow.

	      Pass custom flags	to the SWIG executable.

       INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS	and COMPILE_OPTIONS
	      New in version 3.12.

	      Add  custom  flags  to  SWIG  compiler and have same semantic as
	      properties  INCLUDE_DIRECTORIES,	COMPILE_DEFINITIONS  and  COM-
	      PILE_OPTIONS.

       USE_TARGET_INCLUDE_DIRECTORIES
	      New in version 3.13.

	      If  set to TRUE, contents	of target property INCLUDE_DIRECTORIES
	      will be forwarded	to SWIG	compiler.   If	set  to	 FALSE	target
	      property INCLUDE_DIRECTORIES will	be ignored. If not set,	target
	      property SWIG_USE_TARGET_INCLUDE_DIRECTORIES will	be considered.

       GENERATED_INCLUDE_DIRECTORIES, GENERATED_COMPILE_DEFINITIONS and	GENER-
       ATED_COMPILE_OPTIONS
	      New in version 3.12.

	      Add  custom flags	to the C/C++ generated source. They will fill,
	      respectively,  properties	 INCLUDE_DIRECTORIES,  COMPILE_DEFINI-
	      TIONS and	COMPILE_OPTIONS	of generated C/C++ file.

       DEPENDS
	      New in version 3.12.

	      Specify additional dependencies to the source file.

       USE_SWIG_DEPENDENCIES
	      New in version 3.20.

	      If  set to TRUE, implicit	dependencies are generated by the swig
	      tool itself. This	property is only meaningful for	 Makefile  and
	      Ninja generators.	Default	value is FALSE.

       SWIG_MODULE_NAME
	      Specify  the actual import name of the module in the target lan-
	      guage.  This is required if it cannot be	scanned	 automatically
	      from source or different from the	module file basename.  For ex-
	      ample:

		 set_property(SOURCE mymod.i PROPERTY SWIG_MODULE_NAME mymod_realname)

	      Changed in version 3.14: If policy CMP0086 is set	to NEW,	 -mod-
	      ule <module_name>	is passed to SWIG compiler.

       OUTPUT_DIR
	      New in version 3.19.

	      Specify where to write the language specific files (swig -outdir
	      option) for the considered source	file. If  not  specified,  the
	      other  ways  to  define  the  output directory applies (see OUT-
	      PUT_DIR option of	swig_add_library() command).

       OUTFILE_DIR
	      New in version 3.19.

	      Specify an output	directory where	the generated source file will
	      be  placed  (swig	 -o option) for	the considered source file. If
	      not specified, OUTPUT_DIR	source property	will be	used. If  nei-
	      ther  are	specified, the other ways to define output file	direc-
	      tory applies (see	OUTFILE_DIR option of swig_add_library()  com-
	      mand).

       Target library properties can be	set to apply same configuration	to all
       SWIG input files.

       SWIG_INCLUDE_DIRECTORIES, SWIG_COMPILE_DEFINITIONS and SWIG_COMPILE_OP-
       TIONS
	      New in version 3.12.

	      These  properties	 will  be  applied to all SWIG input files and
	      have same	semantic  as  target  properties  INCLUDE_DIRECTORIES,
	      COMPILE_DEFINITIONS and COMPILE_OPTIONS.

		 set (UseSWIG_TARGET_NAME_PREFERENCE STANDARD)
		 swig_add_library(mymod	LANGUAGE python	SOURCES	mymod.i)
		 set_property(TARGET mymod PROPERTY SWIG_COMPILE_DEFINITIONS MY_DEF1 MY_DEF2)
		 set_property(TARGET mymod PROPERTY SWIG_COMPILE_OPTIONS -bla -blb)

       SWIG_USE_TARGET_INCLUDE_DIRECTORIES
	      New in version 3.13.

	      If  set to TRUE, contents	of target property INCLUDE_DIRECTORIES
	      will be forwarded	to SWIG	compiler.  If set to FALSE or not  de-
	      fined, target property INCLUDE_DIRECTORIES will be ignored. This
	      behavior	can  be	 overridden  by	 specifying  source   property
	      USE_TARGET_INCLUDE_DIRECTORIES.

       SWIG_GENERATED_INCLUDE_DIRECTORIES,  SWIG_GENERATED_COMPILE_DEFINITIONS
       and SWIG_GENERATED_COMPILE_OPTIONS
	      New in version 3.12.

	      These properties will  populate,	respectively,  properties  IN-
	      CLUDE_DIRECTORIES,  COMPILE_DEFINITIONS and COMPILE_FLAGS	of all
	      generated	C/C++ files.

       SWIG_DEPENDS
	      New in version 3.12.

	      Add dependencies to all SWIG input files.

       The following target properties are output properties and can  be  used
       to get information about	support	files generated	by SWIG	interface com-
       pilation.

       SWIG_SUPPORT_FILES
	      New in version 3.12.

	      This output property list	of wrapper files generated during SWIG
	      compilation.

		 set (UseSWIG_TARGET_NAME_PREFERENCE STANDARD)
		 swig_add_library(mymod	LANGUAGE python	SOURCES	mymod.i)
		 get_property(support_files TARGET mymod PROPERTY SWIG_SUPPORT_FILES)

	      NOTE:
		 Only  most  principal	support	files are listed. In case some
		 advanced features of SWIG are used (for  example  %template),
		 associated support files may not be listed. Prefer to use the
		 SWIG_SUPPORT_FILES_DIRECTORY  property	 to   handle   support
		 files.

       SWIG_SUPPORT_FILES_DIRECTORY
	      New in version 3.12.

	      This output property specifies the directory where support files
	      will be generated.

	      NOTE:
		 When source property OUTPUT_DIR is defined, multiple directo-
		 ries  can  be	specified as part of SWIG_SUPPORT_FILES_DIREC-
		 TORY.

       Some variables can be set to customize the behavior of swig_add_library
       as well as SWIG:

       UseSWIG_MODULE_VERSION
	      New in version 3.12.

	      Specify different	behaviors for UseSWIG module.

	      o	Set to 1 or undefined: Legacy behavior is applied.

	      o	Set  to	 2: A new strategy is applied regarding	support	files:
		the output directory of	support	files is  erased  before  SWIG
		interface compilation.

       CMAKE_SWIG_FLAGS
	      Add flags	to all swig calls.

       CMAKE_SWIG_OUTDIR
	      Specify where to write the language specific files (swig -outdir
	      option).

       SWIG_OUTFILE_DIR
	      New in version 3.8.

	      Specify an output	directory name where the generated source file
	      will be placed.  If not specified, CMAKE_SWIG_OUTDIR is used.

       SWIG_MODULE_<name>_EXTRA_DEPS
	      Specify extra dependencies for the generated module for <name>.

       SWIG_SOURCE_FILE_EXTENSIONS
	      New in version 3.14.

	      Specify a	list of	source file extensions to override the default
	      behavior of considering only .i files as sources	for  the  SWIG
	      tool. For	example:

		 set(SWIG_SOURCE_FILE_EXTENSIONS ".i" ".swg")

       SWIG_USE_SWIG_DEPENDENCIES
	      New in version 3.20.

	      If  set to TRUE, implicit	dependencies are generated by the swig
	      tool itself. This	property is only meaningful for	 Makefile  and
	      Ninja generators.	Default	value is FALSE.

	      Source file property USE_SWIG_DEPENDENCIES, if not defined, will
	      be initialized with the value of this variable.

   UsewxWidgets
       Convenience include for using wxWidgets library.

       Determines if wxWidgets was FOUND and sets the  appropriate  libs,  in-
       cdirs,	flags,	etc.   INCLUDE_DIRECTORIES  and	 LINK_DIRECTORIES  are
       called.

       USAGE

	  # Note that for MinGW	users the order	of libs	is important!
	  find_package(wxWidgets REQUIRED net gl core base)
	  include(${wxWidgets_USE_FILE})
	  # and	for each of your dependent executable/library targets:
	  target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})

       DEPRECATED

	  LINK_LIBRARIES is not	called in favor	of adding dependencies per target.

       AUTHOR

	  Jan Woetzel <jw -at- mip.informatik.uni-kiel.de>

FIND MODULES
       These modules search  for  third-party  software.   They	 are  normally
       called through the find_package() command.

   FindALSA
       Find Advanced Linux Sound Architecture (ALSA)

       Find the	alsa libraries (asound)

   IMPORTED Targets
       New in version 3.12.

       This module defines IMPORTED target ALSA::ALSA, if ALSA has been	found.

   Result Variables
       This module defines the following variables:

       ALSA_FOUND
	      True if ALSA_INCLUDE_DIR & ALSA_LIBRARY are found

       ALSA_LIBRARIES
	      List of libraries	when using ALSA.

       ALSA_INCLUDE_DIRS
	      Where to find the	ALSA headers.

   Cache variables
       The following cache variables may also be set:

       ALSA_INCLUDE_DIR
	      the ALSA include directory

       ALSA_LIBRARY
	      the absolute path	of the asound library

   FindArmadillo
       Find  the Armadillo C++ library.	 Armadillo is a	library	for linear al-
       gebra & scientific computing.

       New in version 3.18: Support for	 linking  wrapped  libraries  directly
       (ARMA_DONT_USE_WRAPPER).

       Using Armadillo:

	  find_package(Armadillo REQUIRED)
	  include_directories(${ARMADILLO_INCLUDE_DIRS})
	  add_executable(foo foo.cc)
	  target_link_libraries(foo ${ARMADILLO_LIBRARIES})

       This module sets	the following variables:

	  ARMADILLO_FOUND - set	to true	if the library is found
	  ARMADILLO_INCLUDE_DIRS - list	of required include directories
	  ARMADILLO_LIBRARIES -	list of	libraries to be	linked
	  ARMADILLO_VERSION_MAJOR - major version number
	  ARMADILLO_VERSION_MINOR - minor version number
	  ARMADILLO_VERSION_PATCH - patch version number
	  ARMADILLO_VERSION_STRING - version number as a string	(ex: "1.0.4")
	  ARMADILLO_VERSION_NAME - name	of the version (ex: "Antipodean	Antileech")

   FindASPELL
       Try to find ASPELL

       Once done this will define

	  ASPELL_FOUND - system	has ASPELL
	  ASPELL_EXECUTABLE - the ASPELL executable
	  ASPELL_INCLUDE_DIR - the ASPELL include directory
	  ASPELL_LIBRARIES - The libraries needed to use ASPELL
	  ASPELL_DEFINITIONS - Compiler	switches required for using ASPELL

   FindAVIFile
       Locate AVIFILE library and include paths

       AVIFILE	(http://avifile.sourceforge.net/)  is  a  set of libraries for
       i386 machines to	use various AVI	codecs.	  Support  is  limited	beyond
       Linux.	Windows	 provides native AVI support, and so doesn't need this
       library.	 This module defines

	  AVIFILE_INCLUDE_DIR, where to	find avifile.h , etc.
	  AVIFILE_LIBRARIES, the libraries to link against
	  AVIFILE_DEFINITIONS, definitions to use when compiling
	  AVIFILE_FOUND, If false, don't try to	use AVIFILE

   FindBacktrace
       Find provider for backtrace(3).

       Checks if OS supports backtrace(3) via either libc or  custom  library.
       This module defines the following variables:

       Backtrace_HEADER
	      The  header  file	 needed	 for  backtrace(3).  Cached.  Could be
	      forcibly set by user.

       Backtrace_INCLUDE_DIRS
	      The include directories needed to	use backtrace(3) header.

       Backtrace_LIBRARIES
	      The libraries (linker flags) needed to use backtrace(3), if any.

       Backtrace_FOUND
	      Is set if	and only if backtrace(3) support detected.

       The following cache variables are also available	to set or use:

       Backtrace_LIBRARY
	      The external library providing backtrace,	if any.

       Backtrace_INCLUDE_DIR
	      The directory holding the	backtrace(3) header.

       Typical usage is	to generate of header file using configure_file() with
       the contents like the following:

	  #cmakedefine01 Backtrace_FOUND
	  #if Backtrace_FOUND
	  # include <${Backtrace_HEADER}>
	  #endif

       And then	reference that generated header	file in	actual source.

   FindBISON
       Find  bison  executable	and  provide  a	macro to generate custom build
       rules.

       The module defines the following	variables:

       BISON_EXECUTABLE
	      path to the bison	program

       BISON_VERSION
	      version of bison

       BISON_FOUND
	      "True" if	the program was	found

       The minimum required version of bison can be specified using the	 stan-
       dard CMake syntax, e.g.	find_package(BISON 2.1.3).

       If bison	is found, the module defines the macro:

	  BISON_TARGET(<Name> <YaccInput> <CodeOutput>
		       [COMPILE_FLAGS <flags>]
		       [DEFINES_FILE <file>]
		       [VERBOSE	[<file>]]
		       [REPORT_FILE <file>]
		       )

       which  will  create a custom rule to generate a parser.	<YaccInput> is
       the path	to a yacc file.	 <CodeOutput> is the name of the  source  file
       generated  by  bison.  A	header file is also be generated, and contains
       the token list.

       Changed in version 3.14:	When CMP0088 is	set to NEW, bison runs in  the
       CMAKE_CURRENT_BINARY_DIR	directory.

       The options are:

       COMPILE_FLAGS <flags>
	      Specify flags to be added	to the bison command line.

       DEFINES_FILE <file>
	      New in version 3.4.

	      Specify a	non-default header <file> to be	generated by bison.

       VERBOSE [<file>]
	      Tell bison to write a report file	of the grammar and parser.

	      Deprecated  since	 version 3.7: If <file>	is given, it specifies
	      path the report file is copied to.  [<file>] is left  for	 back-
	      ward  compatibility  of  this  module.   Use VERBOSE REPORT_FILE
	      <file>.

       REPORT_FILE <file>
	      New in version 3.7.

	      Specify a	non-default report <file>, if generated.

       The macro defines the following variables:

       BISON_<Name>_DEFINED
	      True is the macro	ran successfully

       BISON_<Name>_INPUT
	      The input	source file, an	alias for <YaccInput>

       BISON_<Name>_OUTPUT_SOURCE
	      The source file generated	by bison

       BISON_<Name>_OUTPUT_HEADER
	      The header file generated	by bison

       BISON_<Name>_OUTPUTS
	      All files	generated by bison including the  source,  the	header
	      and the report

       BISON_<Name>_COMPILE_FLAGS
	      Options used in the bison	command	line

       Example usage:

	  find_package(BISON)
	  BISON_TARGET(MyParser	parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp
		       DEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/parser.h)
	  add_executable(Foo main.cpp ${BISON_MyParser_OUTPUTS})

   FindBLAS
       Find Basic Linear Algebra Subprograms (BLAS) library

       This module finds an installed Fortran library that implements the BLAS
       linear-algebra interface	(see http://www.netlib.org/blas/).

       The  approach  follows  that  taken  for	 the  autoconf	 macro	 file,
       acx_blas.m4			 (distributed			    at
       http://ac-archive.sourceforge.net/ac-archive/acx_blas.html).

   Input Variables
       The following variables may be set to influence this module's behavior:

       BLA_STATIC
	      if ON use	static linkage

       BLA_VENDOR
	      If set, checks only the specified	vendor,	if not set checks  all
	      the possibilities.  List of vendors valid	in this	module:

	      o	Goto

	      o	FlexiBLAS

	      o	OpenBLAS

	      o	FLAME

	      o	ATLAS PhiPACK

	      o	CXML

	      o	DXML

	      o	SunPerf

	      o	SCSL

	      o	SGIMATH

	      o	IBMESSL

	      o	Intel10_32 (intel mkl v10 32 bit, threaded code)

	      o	Intel10_64lp  (intel  mkl  v10+	 64  bit,  threaded code, lp64
		model)

	      o	Intel10_64lp_seq (intel	mkl v10+ 64 bit, sequential code, lp64
		model)

	      o	Intel10_64ilp  (intel  mkl  v10+  64 bit, threaded code, ilp64
		model)

	      o	Intel10_64ilp_seq (intel mkl v10+  64  bit,  sequential	 code,
		ilp64 model)

	      o	Intel10_64_dyn (intel mkl v10+ 64 bit, single dynamic library)

	      o	Intel (obsolete	versions of mkl	32 and 64 bit)

	      o	ACML

	      o	ACML_MP

	      o	ACML_GPU

	      o	Apple

	      o	NAS

	      o	Arm

	      o	Arm_mp

	      o	Arm_ilp64

	      o	Arm_ilp64_mp

	      o	EML

	      o	EML_mt

	      o	Generic

	      New in version 3.6: OpenBLAS support.

	      New in version 3.11: FLAME support.

	      New  in  version	3.13: Added ILP64 MKL variants (Intel10_64ilp,
	      Intel10_64ilp_seq).

	      New in version 3.17: Added single	dynamic	 library  MKL  variant
	      (Intel10_64_dyn).

	      New  in  version	3.18:  Arm Performance Libraries support (Arm,
	      Arm_mp, Arm_ilp64, Arm_ilp64_mp).

	      New in version 3.19: FlexiBLAS support.

	      New in version 3.20: Elbrus Math Library support (EML, EML_mt).

       BLA_F95
	      if ON tries to find the BLAS95 interfaces

       BLA_PREFER_PKGCONFIG
	      New in version 3.11.

	      if set pkg-config	will be	used to	 search	 for  a	 BLAS  library
	      first and	if one is found	that is	preferred

   Imported targets
       New in version 3.18.

       This module defines the following IMPORTED target:

       BLAS::BLAS
	      The libraries to use for BLAS, if	found.

   Result Variables
       This module defines the following variables:

       BLAS_FOUND
	      library implementing the BLAS interface is found

       BLAS_LINKER_FLAGS
	      uncached list of required	linker flags (excluding	-l and -L).

       BLAS_LIBRARIES
	      uncached	list  of  libraries  (using  full  path	 name) to link
	      against to use BLAS (may be empty	if compiler  implicitly	 links
	      BLAS)

       BLAS95_LIBRARIES
	      uncached	list  of  libraries  (using  full  path	 name) to link
	      against to use BLAS95 interface

       BLAS95_FOUND
	      library implementing the BLAS95 interface	is found

       NOTE:
	  C, CXX or Fortran must be enabled to detect a	BLAS  library.	 C  or
	  CXX must be enabled to use Intel Math	Kernel Library (MKL).

	  For example, to use Intel MKL	libraries and/or Intel compiler:

	      set(BLA_VENDOR Intel10_64lp)
	      find_package(BLAS)

   Hints
       MKLROOT
	      New in version 3.15.

	      Set  this	 environment  variable to a directory that contains an
	      MKL installation,	or add the directory to	 the  dynamic  library
	      loader  environment  variable  for  your platform	(LIB, DYLD_LI-
	      BRARY_PATH or LD_LIBRARY_PATH).

   FindBoost
       Find Boost include dirs and libraries

       Use this	module by invoking find_package() with the form:

	  find_package(Boost
	    [version] [EXACT]	   # Minimum or	EXACT version e.g. 1.67.0
	    [REQUIRED]		   # Fail with error if	Boost is not found
	    [COMPONENTS	<libs>...] # Boost libraries by	their canonical	name
				   # e.g. "date_time" for "libboost_date_time"
	    [OPTIONAL_COMPONENTS <libs>...]
				   # Optional Boost libraries by their canonical name)
	    )			   # e.g. "date_time" for "libboost_date_time"

       This module finds headers and requested component libraries OR a	 CMake
       package	configuration file provided by a "Boost	CMake" build.  For the
       latter case skip	to the Boost CMake section below.

       New in version 3.7: bzip2 and zlib components (Windows only).

       New in version 3.11: The	OPTIONAL_COMPONENTS option.

       New in version 3.13: stacktrace_* components.

       New in version 3.19: bzip2 and zlib components on all platforms.

   Result Variables
       This module defines the following variables:

       Boost_FOUND
	      True if headers and requested libraries were found.

       Boost_INCLUDE_DIRS
	      Boost include directories.

       Boost_LIBRARY_DIRS
	      Link directories for Boost libraries.

       Boost_LIBRARIES
	      Boost component libraries	to be linked.

       Boost_<COMPONENT>_FOUND
	      True if component	<COMPONENT> was	found (<COMPONENT> name	is up-
	      per-case).

       Boost_<COMPONENT>_LIBRARY
	      Libraries	 to  link  for component <COMPONENT> (may include tar-
	      get_link_libraries() debug/optimized keywords).

       Boost_VERSION_MACRO
	      BOOST_VERSION value from boost/version.hpp.

       Boost_VERSION_STRING
	      Boost version number in X.Y.Z format.

       Boost_VERSION
	      Boost  version  number  in  X.Y.Z	 format	 (same	as  Boost_VER-
	      SION_STRING).

	      Changed  in version 3.15:	In previous CMake versions, this vari-
	      able used	the raw	version	string from the	Boost header (same  as
	      Boost_VERSION_MACRO).  See policy	CMP0093.

       Boost_LIB_VERSION
	      Version string appended to library filenames.

       Boost_VERSION_MAJOR, Boost_MAJOR_VERSION
	      Boost major version number (X in X.Y.Z).

       Boost_VERSION_MINOR, Boost_MINOR_VERSION
	      Boost minor version number (Y in X.Y.Z).

       Boost_VERSION_PATCH, Boost_SUBMINOR_VERSION
	      Boost subminor version number (Z in X.Y.Z).

       Boost_VERSION_COUNT
	      Amount of	version	components (3).

       Boost_LIB_DIAGNOSTIC_DEFINITIONS	(Windows-specific)
	      Pass  to	add_definitions() to have diagnostic information about
	      Boost's automatic	linking	displayed during compilation

       New in version 3.15: The	Boost_VERSION_<PART> variables.

   Cache variables
       Search results are saved	persistently in	CMake cache entries:

       Boost_INCLUDE_DIR
	      Directory	containing Boost headers.

       Boost_LIBRARY_DIR_RELEASE
	      Directory	containing release Boost libraries.

       Boost_LIBRARY_DIR_DEBUG
	      Directory	containing debug Boost libraries.

       Boost_<COMPONENT>_LIBRARY_DEBUG
	      Component	<COMPONENT> library debug variant.

       Boost_<COMPONENT>_LIBRARY_RELEASE
	      Component	<COMPONENT> library release variant.

       New in version 3.3: Per-configuration  variables	 Boost_LIBRARY_DIR_RE-
       LEASE and Boost_LIBRARY_DIR_DEBUG.

   Hints
       This module reads hints about search locations from variables:

       BOOST_ROOT, BOOSTROOT
	      Preferred	installation prefix.

       BOOST_INCLUDEDIR
	      Preferred	include	directory e.g. <prefix>/include.

       BOOST_LIBRARYDIR
	      Preferred	library	directory e.g. <prefix>/lib.

       BOOST_PYTHON_SUFFIX
	      Preferred	Python version.

       Boost_NO_SYSTEM_PATHS
	      Set  to  ON  to  disable searching in locations not specified by
	      these hint variables. Default is OFF.

       Boost_ADDITIONAL_VERSIONS
	      List of Boost versions not known to this module.	(Boost install
	      locations	may contain the	version).

       Users may set these hints or results as CACHE entries.  Projects	should
       not read	these entries directly but instead use the above result	 vari-
       ables.	Note  that some	hint names start in upper-case BOOST.  One may
       specify these as	environment variables if they  are  not	 specified  as
       CMake variables or cache	entries.

       This  module  first searches for	the Boost header files using the above
       hint variables (excluding BOOST_LIBRARYDIR) and	saves  the  result  in
       Boost_INCLUDE_DIR.   Then it searches for requested component libraries
       using the  above	 hints	(excluding  BOOST_INCLUDEDIR  and  Boost_ADDI-
       TIONAL_VERSIONS), "lib" directories near	Boost_INCLUDE_DIR, and the li-
       brary name configuration	settings below.	 It saves the library directo-
       ries in Boost_LIBRARY_DIR_DEBUG and Boost_LIBRARY_DIR_RELEASE and indi-
       vidual  library	locations   in	 Boost_<COMPONENT>_LIBRARY_DEBUG   and
       Boost_<COMPONENT>_LIBRARY_RELEASE.   When  one changes settings used by
       previous	searches in the	same build tree	(excluding  environment	 vari-
       ables)  this  module  discards  previous	search results affected	by the
       changes and searches again.

   Imported Targets
       New in version 3.5.

       This module defines the following IMPORTED targets:

       Boost::boost
	      Target for header-only dependencies. (Boost include directory).

       Boost::headers
	      New in version 3.15: Alias for Boost::boost.

       Boost::<component>
	      Target for specific component dependency (shared or  static  li-
	      brary); <component> name is lower-case.

       Boost::diagnostic_definitions
	      Interface	 target	to enable diagnostic information about Boost's
	      automatic	linking	during compilation (adds  -DBOOST_LIB_DIAGNOS-
	      TIC).

       Boost::disable_autolinking
	      Interface	 target	 to  disable automatic linking with MSVC (adds
	      -DBOOST_ALL_NO_LIB).

       Boost::dynamic_linking
	      Interface	target to enable dynamic  linking  linking  with  MSVC
	      (adds -DBOOST_ALL_DYN_LINK).

       Implicit	dependencies such as Boost::filesystem requiring Boost::system
       will be automatically detected and satisfied, even  if  system  is  not
       specified  when	using find_package() and if Boost::system is not added
       to   target_link_libraries().	 If    using	Boost::thread,	  then
       Threads::Threads	will also be added automatically.

       It  is  important  to note that the imported targets behave differently
       than variables created by this module:  multiple	 calls	to  find_pack-
       age(Boost)  in the same directory or sub-directories with different op-
       tions (e.g. static or shared) will not override the values of the  tar-
       gets created by the first call.

   Other Variables
       Boost  libraries	 come  in  many	 variants  encoded in their file name.
       Users or	projects may tell this module which variant to find by setting
       variables:

       Boost_USE_DEBUG_LIBS
	      New in version 3.10.

	      Set  to ON or OFF	to specify whether to search and use the debug
	      libraries.  Default is ON.

       Boost_USE_RELEASE_LIBS
	      New in version 3.10.

	      Set to ON	or OFF to specify whether to search and	 use  the  re-
	      lease libraries.	Default	is ON.

       Boost_USE_MULTITHREADED
	      Set  to  OFF  to use the non-multithreaded libraries ("mt" tag).
	      Default is ON.

       Boost_USE_STATIC_LIBS
	      Set to ON	to force the use of the	static libraries.  Default  is
	      OFF.

       Boost_USE_STATIC_RUNTIME
	      Set  to  ON  or  OFF  to specify whether to use libraries	linked
	      statically to the	C++ runtime ("s" tag).	 Default  is  platform
	      dependent.

       Boost_USE_DEBUG_RUNTIME
	      Set  to  ON or OFF to specify whether to use libraries linked to
	      the MS debug C++ runtime ("g" tag).  Default is ON.

       Boost_USE_DEBUG_PYTHON
	      Set to ON	to use libraries compiled with a  debug	 Python	 build
	      ("y" tag).  Default is OFF.

       Boost_USE_STLPORT
	      Set  to ON to use	libraries compiled with	STLPort	("p" tag). De-
	      fault is OFF.

       Boost_USE_STLPORT_DEPRECATED_NATIVE_IOSTREAMS
	      Set to ON	to use libraries compiled with STLPort deprecated "na-
	      tive iostreams" ("n" tag).  Default is OFF.

       Boost_COMPILER
	      Set  to the compiler-specific library suffix (e.g. -gcc43).  De-
	      fault is auto-computed for the C++ compiler in use.

	      Changed in version 3.9: A	list may be used if multiple  compati-
	      ble  suffixes should be tested for, in decreasing	order of pref-
	      erence.

       Boost_LIB_PREFIX
	      New in version 3.18.

	      Set to the platform-specific library name	prefix (e.g. lib) used
	      by  Boost	 static	 libs.	This is	needed only on platforms where
	      CMake does not know the prefix by	default.

       Boost_ARCHITECTURE
	      New in version 3.13.

	      Set to the architecture-specific	library	 suffix	 (e.g.	-x64).
	      Default is auto-computed for the C++ compiler in use.

       Boost_THREADAPI
	      Suffix  for  thread  component  library name, such as pthread or
	      win32.  Names with and without this suffix will both be tried.

       Boost_NAMESPACE
	      Alternate	namespace used to build	boost with e.g.	if set to  my-
	      boost, will search for myboost_thread instead of boost_thread.

       Other variables one may set to control this module are:

       Boost_DEBUG
	      Set  to ON to enable debug output	from FindBoost.	 Please	enable
	      this before filing any bug report.

       Boost_REALPATH
	      Set to ON	to resolve symlinks for	discovered libraries to	assist
	      with packaging.  For example, the	"system" component library may
	      be resolved  to  /usr/lib/libboost_system.so.1.67.0  instead  of
	      /usr/lib/libboost_system.so.   This  does	not affect linking and
	      should not be enabled unless the user needs this information.

       Boost_LIBRARY_DIR
	      Default  value  for  Boost_LIBRARY_DIR_RELEASE   and   Boost_LI-
	      BRARY_DIR_DEBUG.

       Boost_NO_WARN_NEW_VERSIONS
	      New in version 3.20.

	      Set to ON	to suppress the	warning	about unknown dependencies for
	      new Boost	versions.

       On Visual Studio	and Borland compilers Boost headers request  automatic
       linking	to  corresponding libraries.  This requires matching libraries
       to be linked explicitly or available in the link	library	 search	 path.
       In  this	 case setting Boost_USE_STATIC_LIBS to OFF may not achieve dy-
       namic linking.  Boost automatic linking typically requests  static  li-
       braries with a few exceptions (such as Boost.Python).  Use:

	  add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})

       to ask Boost to report information about	automatic linking requests.

   Examples
       Find Boost headers only:

	  find_package(Boost 1.36.0)
	  if(Boost_FOUND)
	    include_directories(${Boost_INCLUDE_DIRS})
	    add_executable(foo foo.cc)
	  endif()

       Find Boost libraries and	use imported targets:

	  find_package(Boost 1.56 REQUIRED COMPONENTS
		       date_time filesystem iostreams)
	  add_executable(foo foo.cc)
	  target_link_libraries(foo Boost::date_time Boost::filesystem
				    Boost::iostreams)

       Find Boost Python 3.6 libraries and use imported	targets:

	  find_package(Boost 1.67 REQUIRED COMPONENTS
		       python36	numpy36)
	  add_executable(foo foo.cc)
	  target_link_libraries(foo Boost::python36 Boost::numpy36)

       Find Boost headers and some static (release only) libraries:

	  set(Boost_USE_STATIC_LIBS	   ON)	# only find static libs
	  set(Boost_USE_DEBUG_LIBS	  OFF)	# ignore debug libs and
	  set(Boost_USE_RELEASE_LIBS	   ON)	# only find release libs
	  set(Boost_USE_MULTITHREADED	   ON)
	  set(Boost_USE_STATIC_RUNTIME	  OFF)
	  find_package(Boost 1.66.0 COMPONENTS date_time filesystem system ...)
	  if(Boost_FOUND)
	    include_directories(${Boost_INCLUDE_DIRS})
	    add_executable(foo foo.cc)
	    target_link_libraries(foo ${Boost_LIBRARIES})
	  endif()

   Boost CMake
       If  Boost  was built using the boost-cmake project or from Boost	1.70.0
       on it provides a	package	configuration file for use with	find_package's
       config  mode.   This  module  looks  for	the package configuration file
       called BoostConfig.cmake	or boost-config.cmake and stores the result in
       CACHE  entry  Boost_DIR.	  If  found, the package configuration file is
       loaded and this module returns with no further action.  See  documenta-
       tion  of	 the  Boost CMake package configuration	for details on what it
       provides.

       Set Boost_NO_BOOST_CMAKE	to ON, to disable the search for boost-cmake.

   FindBullet
       Try to find the Bullet physics engine

	  This module defines the following variables

	  BULLET_FOUND - Was bullet found
	  BULLET_INCLUDE_DIRS -	the Bullet include directories
	  BULLET_LIBRARIES - Link to this, by default it includes
			     all bullet	components (Dynamics,
			     Collision,	LinearMath, & SoftBody)

	  This module accepts the following variables

	  BULLET_ROOT -	Can be set to bullet install path or Windows build path

   FindBZip2
       Try to find BZip2

   IMPORTED Targets
       New in version 3.12.

       This module defines IMPORTED target BZip2::BZip2,  if  BZip2  has  been
       found.

   Result Variables
       This module defines the following variables:

       BZIP2_FOUND
	      system has BZip2

       BZIP2_INCLUDE_DIRS
	      New in version 3.12: the BZip2 include directories

       BZIP2_LIBRARIES
	      Link these to use	BZip2

       BZIP2_NEED_PREFIX
	      this is set if the functions are prefixed	with BZ2_

       BZIP2_VERSION_STRING
	      the version of BZip2 found

   Cache variables
       The following cache variables may also be set:

       BZIP2_INCLUDE_DIR
	      the BZip2	include	directory

   FindCABLE
       Find CABLE

       This  module  finds  if CABLE is	installed and determines where the in-
       clude files and libraries are.  This code sets the following variables:

	  CABLE		    the	path to	the cable executable
	  CABLE_TCL_LIBRARY the	path to	the Tcl	wrapper	library
	  CABLE_INCLUDE_DIR the	path to	the include directory

       To build	Tcl wrappers, you should add shared library  and  link	it  to
       ${CABLE_TCL_LIBRARY}.   You  should also	add ${CABLE_INCLUDE_DIR} as an
       include directory.

   FindCoin3D
       Find Coin3D (Open Inventor)

       Coin3D is an implementation of the Open Inventor	API.  It provides data
       structures and algorithms for 3D	visualization.

       This module defines the following variables

	  COIN3D_FOUND	       - system	has Coin3D - Open Inventor
	  COIN3D_INCLUDE_DIRS  - where the Inventor include directory can be found
	  COIN3D_LIBRARIES     - Link to this to use Coin3D

   FindCUDAToolkit
       New in version 3.17.

       This  script  locates  the  NVIDIA  CUDA	toolkit	and the	associated li-
       braries,	but does not require the CUDA language be enabled for a	 given
       project.	This module does not search for	the NVIDIA CUDA	Samples.

       New in version 3.19: QNX	support.

   Search Behavior
       The CUDA	Toolkit	search behavior	uses the following order:

       1. If the CUDA language has been	enabled	we will	use the	directory con-
	  taining the compiler as the first search location for	nvcc.

       2. If the CUDAToolkit_ROOT cmake	configuration variable (e.g.,  -DCUDA-
	  Toolkit_ROOT=/some/path) or environment variable is defined, it will
	  be searched.	If both	an environment variable	 and  a	 configuration
	  variable are specified, the configuration variable takes precedence.

	  The  directory  specified here must be such that the executable nvcc
	  or the appropriate version.txt file  can  be	found  underneath  the
	  specified directory.

       3. If  the  CUDA_PATH  environment  variable  is	 defined,  it  will be
	  searched for nvcc.

       4. The user's path is searched for nvcc using find_program().  If  this
	  is  found,  no  subsequent search attempts are performed.  Users are
	  responsible for ensuring that	the first nvcc to show up in the  path
	  is the desired path in the event that	multiple CUDA Toolkits are in-
	  stalled.

       5. On Unix systems, if the symbolic link	/usr/local/cuda	 exists,  this
	  is  used.   No subsequent search attempts are	performed.  No default
	  symbolic link	location exists	for the	Windows	platform.

       6. The platform specific	default	install	locations  are	searched.   If
	  exactly  one	candidate  is  found,  this is used.  The default CUDA
	  Toolkit install locations searched are:

		       +-----------+----------------------------+
		       |Platform   | Search Pattern		|
		       +-----------+----------------------------+
		       |macOS	   | /Developer/NVIDIA/CUDA-X.Y	|
		       +-----------+----------------------------+
		       |Other Unix | /usr/local/cuda-X.Y	|
		       +-----------+----------------------------+
		       |Windows	   | C:\Program	   Files\NVIDIA	|
		       |	   | GPU     Computing	  Tool-	|
		       |	   | kit\CUDA\vX.Y		|
		       +-----------+----------------------------+

	  Where	X.Y would be a specific	version	of the CUDA Toolkit,  such  as
	  /usr/local/cuda-9.0  or  C:\Program Files\NVIDIA GPU Computing Tool-
	  kit\CUDA\v9.0

	  NOTE:
	     When multiple CUDA	Toolkits are installed in the default location
	     of	  a   system  (e.g.,  both  /usr/local/cuda-9.0	 and  /usr/lo-
	     cal/cuda-10.0 exist but the /usr/local/cuda  symbolic  link  does
	     not exist), this package is marked	as not found.

	     There  are	too many factors involved in making an automatic deci-
	     sion in the presence of multiple CUDA Toolkits  being  installed.
	     In	 this  situation, users	are encouraged to either (1) set CUDA-
	     Toolkit_ROOT or (2) ensure	that the correct nvcc executable shows
	     up	in $PATH for find_program() to find.

   Options
       VERSION
	      If  specified,  describes	 the  version  of  the CUDA Toolkit to
	      search for.

       REQUIRED
	      If specified, configuration will error if	a suitable CUDA	 Tool-
	      kit is not found.

       QUIET  If  specified,  the  search for a	suitable CUDA Toolkit will not
	      produce any messages.

       EXACT  If specified, the	CUDA Toolkit is	considered found only  if  the
	      exact VERSION specified is recovered.

   Imported targets
       An imported target named	CUDA::toolkit is provided.

       This  module  defines  IMPORTED	targets	 for each of the following li-
       braries that are	part of	the CUDAToolkit:

       o CUDA Runtime Library

       o CUDA Driver Library

       o cuBLAS

       o cuFFT

       o cuRAND

       o cuSOLVER

       o cuSPARSE

       o cuPTI

       o NPP

       o nvBLAS

       o nvGRAPH

       o nvJPEG

       o nvidia-ML

       o nvRTC

       o nvToolsExt

       o OpenCL

       o cuLIBOS

   CUDA	Runtime	Library
       The CUDA	Runtime	library	(cudart) are what most applications will typi-
       cally  need  to	link against to	make any calls such as cudaMalloc, and
       cudaFree.

       Targets Created:

       o CUDA::cudart

       o CUDA::cudart_static

   CUDA	Driver Library
       The CUDA	Driver library (cuda) are used by applications that use	 calls
       such as cuMemAlloc, and cuMemFree. This is generally used by advanced

       Targets Created:

       o CUDA::cuda_driver

       o CUDA::cuda_driver

   cuBLAS
       The cuBLAS library.

       Targets Created:

       o CUDA::cublas

       o CUDA::cublas_static

       o CUDA::cublasLt	starting in CUDA 10.1

       o CUDA::cublasLt_static starting	in CUDA	10.1

   cuFFT
       The cuFFT library.

       Targets Created:

       o CUDA::cufft

       o CUDA::cufftw

       o CUDA::cufft_static

       o CUDA::cufftw_static

   cuRAND
       The cuRAND library.

       Targets Created:

       o CUDA::curand

       o CUDA::curand_static

   cuSOLVER
       The cuSOLVER library.

       Targets Created:

       o CUDA::cusolver

       o CUDA::cusolver_static

   cuSPARSE
       The cuSPARSE library.

       Targets Created:

       o CUDA::cusparse

       o CUDA::cusparse_static

   cupti
       The NVIDIA CUDA Profiling Tools Interface.

       Targets Created:

       o CUDA::cupti

       o CUDA::cupti_static

   NPP
       The NPP libraries.

       Targets Created:

       o nppc:

	 o CUDA::nppc

	 o CUDA::nppc_static

       o nppial:  Arithmetic  and  logical  operation functions	in nppi_arith-
	 metic_and_logical_operations.h

	 o CUDA::nppial

	 o CUDA::nppial_static

       o nppicc: Color conversion and sampling functions in nppi_color_conver-
	 sion.h

	 o CUDA::nppicc

	 o CUDA::nppicc_static

       o nppicom:  JPEG	 compression  and decompression	functions in nppi_com-
	 pression_functions.h Removed starting in CUDA 11.0,  use  nvJPEG  in-
	 stead.

	 o CUDA::nppicom

	 o CUDA::nppicom_static

       o nppidei:  Data	exchange and initialization functions in nppi_data_ex-
	 change_and_initialization.h

	 o CUDA::nppidei

	 o CUDA::nppidei_static

       o nppif:	Filtering and computer vision functions	 in  nppi_filter_func-
	 tions.h

	 o CUDA::nppif

	 o CUDA::nppif_static

       o nppig:	  Geometry   transformation  functions	found  in  nppi_geome-
	 try_transforms.h

	 o CUDA::nppig

	 o CUDA::nppig_static

       o nppim:	Morphological operation	functions  found  in  nppi_morphologi-
	 cal_operations.h

	 o CUDA::nppim

	 o CUDA::nppim_static

       o nppist:  Statistics  and  linear  transform  in nppi_statistics_func-
	 tions.h and nppi_linear_transforms.h

	 o CUDA::nppist

	 o CUDA::nppist_static

       o nppisu: Memory	support	functions in nppi_support_functions.h

	 o CUDA::nppisu

	 o CUDA::nppisu_static

       o nppitc: Threshold and compare	operation  functions  in  nppi_thresh-
	 old_and_compare_operations.h

	 o CUDA::nppitc

	 o CUDA::nppitc_static

       o npps:

	 o CUDA::npps

	 o CUDA::npps_static

   nvBLAS
       The nvBLAS libraries.  This is a	shared library only.

       Targets Created:

       o CUDA::nvblas

   nvGRAPH
       The nvGRAPH library.  Removed starting in CUDA 11.0

       Targets Created:

       o CUDA::nvgraph

       o CUDA::nvgraph_static

   nvJPEG
       The nvJPEG library.  Introduced in CUDA 10.

       Targets Created:

       o CUDA::nvjpeg

       o CUDA::nvjpeg_static

   nvRTC
       The  nvRTC  (Runtime  Compilation)  library.   This is a	shared library
       only.

       Targets Created:

       o CUDA::nvrtc

   nvidia-ML
       The NVIDIA Management Library.  This is a shared	library	only.

       Targets Created:

       o CUDA::nvml

   nvToolsExt
       The NVIDIA Tools	Extension.  This is a shared library only.

       Targets Created:

       o CUDA::nvToolsExt

   OpenCL
       The NVIDIA OpenCL Library.  This	is a shared library only.

       Targets Created:

       o CUDA::OpenCL

   cuLIBOS
       The cuLIBOS library is a	backend	thread abstraction layer library which
       is   static   only.   The  CUDA::cublas_static,	CUDA::cusparse_static,
       CUDA::cufft_static, CUDA::curand_static,	and (when implemented) NPP li-
       braries all automatically have this dependency linked.

       Target Created:

       o CUDA::culibos

       Note: direct usage of this target by consumers should not be necessary.

   Result variables
       CUDAToolkit_FOUND
	      A	boolean	specifying whether or not the CUDA Toolkit was found.

       CUDAToolkit_VERSION
	      The exact	version	of the CUDA Toolkit found (as reported by nvcc
	      --version	or version.txt).

       CUDAToolkit_VERSION_MAJOR
	      The major	version	of the CUDA Toolkit.

       CUDAToolkit_VERSION_MAJOR
	      The minor	version	of the CUDA Toolkit.

       CUDAToolkit_VERSION_PATCH
	      The patch	version	of the CUDA Toolkit.

       CUDAToolkit_BIN_DIR
	      The path to the CUDA Toolkit library directory that contains the
	      CUDA executable nvcc.

       CUDAToolkit_INCLUDE_DIRS
	      The  path	 to  the  CUDA	Toolkit	 include folder	containing the
	      header files required to compile a project linking against CUDA.

       CUDAToolkit_LIBRARY_DIR
	      The path to the CUDA Toolkit library directory that contains the
	      CUDA Runtime library cudart.

       CUDAToolkit_LIBRARY_ROOT
	      New in version 3.18.

	      The  path	 to the	CUDA Toolkit directory containing the nvvm di-
	      rectory and version.txt.

       CUDAToolkit_TARGET_DIR
	      The path to the CUDA Toolkit directory including the target  ar-
	      chitecture  when	cross-compiling. When not cross-compiling this
	      will  be	equivalent  to	 the   parent	directory   of	 CUDA-
	      Toolkit_BIN_DIR.

       CUDAToolkit_NVCC_EXECUTABLE
	      The  path	to the NVIDIA CUDA compiler nvcc.  Note	that this path
	      may not be the same as CMAKE_CUDA_COMPILER.  nvcc	must be	 found
	      to  determine  the  CUDA	Toolkit	version	as well	as determining
	      other features of	the Toolkit.  This variable  is	 set  for  the
	      convenience of modules that depend on this one.

   FindCups
       Find the	Common UNIX Printing System (CUPS).

       Set  CUPS_REQUIRE_IPP_DELETE_ATTRIBUTE  to  TRUE	 if you	need a version
       which features this function (i.e. at least 1.1.19)

   Imported targets
       New in version 3.15.

       This module defines IMPORTED target Cups::Cups, if Cups has been	found.

   Result variables
       This module will	set the	following variables in your project:

       CUPS_FOUND
	      true if CUPS headers and libraries were found

       CUPS_INCLUDE_DIRS
	      the directory containing the Cups	headers

       CUPS_LIBRARIES
	      the libraries to link against to use CUPS.

       CUPS_VERSION_STRING
	      the version of CUPS found	(since CMake 2.8.8)

   Cache variables
       The following cache variables may also be set:

       CUPS_INCLUDE_DIR
	      the directory containing the Cups	headers

   FindCURL
       Find the	native CURL headers and	libraries.

       New in version 3.14: This module	accept optional	 COMPONENTS  to	 check
       supported features and protocols:

	  PROTOCOLS: ICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS POP3
		     POP3S RTMP	RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP
	  FEATURES:  SSL IPv6 UnixSockets libz AsynchDNS IDN GSS-API PSL SPNEGO
		     Kerberos NTLM NTLM_WB TLS-SRP HTTP2 HTTPS-proxy

   IMPORTED Targets
       New in version 3.12.

       This  module  defines  IMPORTED	target CURL::libcurl, if curl has been
       found.

   Result Variables
       This module defines the following variables:

       CURL_FOUND
	      "True" if	curl found.

       CURL_INCLUDE_DIRS
	      where to find curl/curl.h, etc.

       CURL_LIBRARIES
	      List of libraries	when using curl.

       CURL_VERSION_STRING
	      The version of curl found.

       New in version 3.13: Debug and Release variants are found separately.

   CURL	CMake
       New in version 3.17.

       If CURL was built using the CMake buildsystem then it provides its  own
       CURLConfig.cmake	 file for use with the find_package() command's	config
       mode. This module looks for this	file and, if found,  returns  its  re-
       sults with no further action.

       Set CURL_NO_CURL_CMAKE to ON to disable this search.

   FindCurses
       Find the	curses or ncurses include file and library.

   Result Variables
       This module defines the following variables:

       CURSES_FOUND
	      True if Curses is	found.

       CURSES_INCLUDE_DIRS
	      The include directories needed to	use Curses.

       CURSES_LIBRARIES
	      The libraries needed to use Curses.

       CURSES_CFLAGS
	      New in version 3.16.

	      Parameters  which	 ought	be given to C/C++ compilers when using
	      Curses.

       CURSES_HAVE_CURSES_H
	      True if curses.h is available.

       CURSES_HAVE_NCURSES_H
	      True if ncurses.h	is available.

       CURSES_HAVE_NCURSES_NCURSES_H
	      True if ncurses/ncurses.h	is available.

       CURSES_HAVE_NCURSES_CURSES_H
	      True if ncurses/curses.h is available.

       Set CURSES_NEED_NCURSES to TRUE before the find_package(Curses) call if
       NCurses functionality is	required.

       New in version 3.10: Set	CURSES_NEED_WIDE to TRUE before	the find_pack-
       age(Curses) call	if unicode functionality is required.

   Backward Compatibility
       The following variable are provided for backward	compatibility:

       CURSES_INCLUDE_DIR
	      Path to Curses include.  Use CURSES_INCLUDE_DIRS instead.

       CURSES_LIBRARY
	      Path to Curses library.  Use CURSES_LIBRARIES instead.

   FindCVS
       Find the	Concurrent Versions System (CVS).

       The module defines the following	variables:

	  CVS_EXECUTABLE - path	to cvs command line client
	  CVS_FOUND - true if the command line client was found

       Example usage:

	  find_package(CVS)
	  if(CVS_FOUND)
	    message("CVS found:	${CVS_EXECUTABLE}")
	  endif()

   FindCxxTest
       Find CxxTest unit testing framework.

       Find the	CxxTest	suite and declare a helper  macro  for	creating  unit
       tests and integrating them with CTest.  For more	details	on CxxTest see
       http://cxxtest.tigris.org

       INPUT Variables

	  CXXTEST_USE_PYTHON [deprecated since 1.3]
	      Only used	in the case both Python	& Perl
	      are detected on the system to control
	      which CxxTest code generator is used.
	      Valid only for CxxTest version 3.

	  NOTE:	In older versions of this Find Module,
	  this variable	controlled if the Python test
	  generator was	used instead of	the Perl one,
	  regardless of	which scripting	language the
	  user had installed.

	  CXXTEST_TESTGEN_ARGS (since CMake 2.8.3)
	      Specify a	list of	options	to pass	to the CxxTest code
	      generator.  If not defined, --error-printer is
	      passed.

       OUTPUT Variables

	  CXXTEST_FOUND
	      True if the CxxTest framework was	found
	  CXXTEST_INCLUDE_DIRS
	      Where to find the	CxxTest	include	directory
	  CXXTEST_PERL_TESTGEN_EXECUTABLE
	      The perl-based test generator
	  CXXTEST_PYTHON_TESTGEN_EXECUTABLE
	      The python-based test generator
	  CXXTEST_TESTGEN_EXECUTABLE (since CMake 2.8.3)
	      The test generator that is actually used (chosen using user preferences
	      and interpreters found in	the system)
	  CXXTEST_TESTGEN_INTERPRETER (since CMake 2.8.3)
	      The full path to the Perl	or Python executable on	the system, on
	      platforms	where the script cannot	be executed using its shebang line.

       MACROS for optional use by CMake	users:

	  CXXTEST_ADD_TEST(<test_name> <gen_source_file> <input_files_to_testgen...>)
	     Creates a CxxTest runner and adds it to the CTest testing suite
	     Parameters:
		 test_name		 The name of the test
		 gen_source_file	 The generated source filename to be
					 generated by CxxTest
		 input_files_to_testgen	 The list of header files containing the
					 CxxTest::TestSuite's to be included in
					 this runner

	  #==============
	  Example Usage:

	  find_package(CxxTest)
	  if(CXXTEST_FOUND)
	      include_directories(${CXXTEST_INCLUDE_DIR})
	      enable_testing()

	      CXXTEST_ADD_TEST(unittest_foo foo_test.cc
				${CMAKE_CURRENT_SOURCE_DIR}/foo_test.h)
	      target_link_libraries(unittest_foo foo) #	as needed
	  endif()

	  This will (if	CxxTest	is found):
	  1. Invoke the	testgen	executable to autogenerate foo_test.cc in the
	     binary tree from "foo_test.h" in the current source directory.
	  2. Create an executable and test called unittest_foo.

	  #=============
	  Example foo_test.h:

	  #include <cxxtest/TestSuite.h>

	  class	MyTestSuite : public CxxTest::TestSuite
	  {
	  public:
	     void testAddition(	void )
	     {
		TS_ASSERT( 1 + 1 > 1 );
		TS_ASSERT_EQUALS( 1 + 1, 2 );
	     }
	  };

   FindCygwin
       Find Cygwin, a POSIX-compatible environment that	runs natively  on  Mi-
       crosoft Windows

   FindDart
       Find DART

       This  module  looks for the dart	testing	software and sets DART_ROOT to
       point to	where it found it.

   FindDCMTK
       Find DICOM ToolKit (DCMTK) libraries and	applications

       The module defines the following	variables:

	  DCMTK_INCLUDE_DIRS  -	Directories to include to use DCMTK
	  DCMTK_LIBRARIES     -	Files to link against to use DCMTK
	  DCMTK_FOUND	      -	If false, don't	try to use DCMTK
	  DCMTK_DIR	      -	(optional) Source directory for	DCMTK

   Compatibility
       This module is able to find a version of	DCMTK that does	 or  does  not
       export a	DCMTKConfig.cmake file.	It applies a two step process:

       o Step  1:  Attempt to find DCMTK version providing a DCMTKConfig.cmake
	 file.

       o Step 2:  If step 1 failed, rely on  FindDCMTK.cmake  to  set  DCMTK_*
	 variables details below.

       Recent  DCMTK  provides a DCMTKConfig.cmake package configuration file.
       To exclusively use the package  configuration  file  (recommended  when
       possible),  pass	 the  NO_MODULE	option to find_package(). For example,
       find_package(DCMTK NO_MODULE).  This requires official  DCMTK  snapshot
       3.6.1_20140617 or newer.

       Until  all  clients update to the more recent DCMTK, build systems will
       need to support different versions of DCMTK.

       On any given system, the	following combinations of DCMTK	versions could
       be considered:

	     +-------+-----------------+-----------------+-------------+
	     |	     | SYSTEM DCMTK    | LOCAL DCMTK	 | Supported ? |
	     +-------+-----------------+-----------------+-------------+
	     |Case A | NA	       | [ ] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case B | NA	       | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case C | [ ] DCMTKConfig | NA		 | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case D | [X] DCMTKConfig | NA		 | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case E | [ ] DCMTKConfig | [ ] DCMTKConfig | YES (*)     |
	     +-------+-----------------+-----------------+-------------+
	     |Case F | [X] DCMTKConfig | [ ] DCMTKConfig | NO	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case G | [ ] DCMTKConfig | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case H | [X] DCMTKConfig | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	  (*) See Troubleshooting section.

       Legend:
	  NA ...............: Means that no System or Local DCMTK is available

	  [  ] DCMTKConfig ..: Means that the version of DCMTK does NOT	export
	  a DCMTKConfig.cmake file.

	  [X] DCMTKConfig ..: Means that the version of	DCMTK exports a	DCMTK-
	  Config.cmake file.

   Troubleshooting
       What to do if my	project	finds a	different version of DCMTK?

       Remove  DCMTK  entry from the CMake cache per find_package() documenta-
       tion.

   FindDevIL
       This    module	 locates    the	    developer's	    image     library.
       http://openil.sourceforge.net/

       This module sets:

	  IL_LIBRARIES -   the name of the IL library. These include the full path to
			   the core DevIL library. This	one has	to be linked into the
			   application.
	  ILU_LIBRARIES	-  the name of the ILU library.	Again, the full	path. This
			   library is for filters and effects, not actual loading. It
			   doesn't have	to be linked if	the functionality it provides
			   is not used.
	  ILUT_LIBRARIES - the name of the ILUT	library. Full path. This part of the
			   library interfaces with OpenGL. It is not strictly needed
			   in applications.
	  IL_INCLUDE_DIR - where to find the il.h, ilu.h and ilut.h files.
	  DevIL_FOUND	 - this	is set to TRUE if all the above	variables were set.
			   This	will be	set to false if	ILU or ILUT are	not found,
			   even	if they	are not	needed.	In most	systems, if one
			   library is found all	the others are as well.	That's the
			   way the DevIL developers release it.

   FindDoxygen
       Doxygen	   is	  a	documentation	  generation	 tool	  (see
       http://www.doxygen.org).	 This module looks for Doxygen	and  some  op-
       tional tools it supports:

       dot    Graphviz dot utility used	to render various graphs.

       mscgen Message Chart Generator utility used by Doxygen's	\msc and \msc-
	      file commands.

       dia    Dia the diagram editor used by Doxygen's \diafile	command.

       New in version 3.9: These tools are  available  as  components  in  the
       find_package() command.	For example:

	  # Require dot, treat the other components as optional
	  find_package(Doxygen
		       REQUIRED	dot
		       OPTIONAL_COMPONENTS mscgen dia)

       The following variables are defined by this module:

       DOXYGEN_FOUND
	      True if the doxygen executable was found.

       DOXYGEN_VERSION
	      The version reported by doxygen --version.

       New in version 3.9: The module defines IMPORTED targets for Doxygen and
       each component found.  These can	be used	as part	 of  custom  commands,
       etc.  and should	be preferred over old-style (and now deprecated) vari-
       ables like DOXYGEN_EXECUTABLE. The following import targets are defined
       if  their corresponding executable could	be found (the component	import
       targets will only be defined if that component was requested):

	  Doxygen::doxygen
	  Doxygen::dot
	  Doxygen::mscgen
	  Doxygen::dia

   Functions
       doxygen_add_docs
	      New in version 3.9.

	      This function is intended	as a convenience for adding  a	target
	      for  generating  documentation  with Doxygen. It aims to provide
	      sensible defaults	so that	projects can  generally	 just  provide
	      the  input  files	and directories	and that will be sufficient to
	      give sensible results. The function supports the ability to cus-
	      tomize  the  Doxygen  configuration used to build	the documenta-
	      tion.

		 doxygen_add_docs(targetName
		     [filesOrDirs...]
		     [ALL]
		     [USE_STAMP_FILE]
		     [WORKING_DIRECTORY	dir]
		     [COMMENT comment])

	      The function constructs a	Doxyfile and defines a	custom	target
	      that  runs  Doxygen on that generated file. The listed files and
	      directories are used as the INPUT	of the generated Doxyfile  and
	      they  can	 contain wildcards.  Any files that are	listed explic-
	      itly will	also be	added as SOURCES of the	custom target so  they
	      will show	up in an IDE project's source list.

	      So  that	relative  input	paths work as expected,	by default the
	      working directory	of the Doxygen command	will  be  the  current
	      source  directory	 (i.e.	CMAKE_CURRENT_SOURCE_DIR). This	can be
	      overridden with the WORKING_DIRECTORY option to change  the  di-
	      rectory  used  as	 the relative base point. Note also that Doxy-
	      gen's default behavior is	to strip the  working  directory  from
	      relative	 paths	 in   the  generated  documentation  (see  the
	      STRIP_FROM_PATH Doxygen config option for	details).

	      If provided, the optional	comment	will be	passed as the  COMMENT
	      for  the	add_custom_target()  command used to create the	custom
	      target internally.

	      New in version 3.12: If ALL is set, the target will be added  to
	      the default build	target.

	      New  in  version 3.16: If	USE_STAMP_FILE is set, the custom com-
	      mand defined by this function will create	a stamp	file with  the
	      name <targetName>.stamp in the current binary directory whenever
	      doxygen is re-run.  With	this  option  present,	all  items  in
	      <filesOrDirs>  must  be  files (i.e. no directories, symlinks or
	      wildcards) and each of the files must exist at  the  time	 doxy-
	      gen_add_docs() is	called.	 An error will be raised if any	of the
	      items listed is missing or is not	a file when USE_STAMP_FILE  is
	      given.   A  dependency  will  be created on each of the files so
	      that doxygen will	only be	re-run if one of the files is updated.
	      Without the USE_STAMP_FILE option, doxygen will always be	re-run
	      if the <targetName> target is built regardless of	 whether  any-
	      thing listed in <filesOrDirs> has	changed.

	      The contents of the generated Doxyfile can be customized by set-
	      ting CMake  variables  before  calling  doxygen_add_docs().  Any
	      variable	with  a	 name  of the form DOXYGEN_<tag> will have its
	      value substituted	for the	corresponding <tag> configuration  op-
	      tion in the Doxyfile. See	the Doxygen documentation for the full
	      list of supported	configuration options.

	      Some of Doxygen's	defaults are overridden	to provide more	appro-
	      priate  behavior for a CMake project. Each of the	following will
	      be explicitly set	unless the variable already has	a value	before
	      doxygen_add_docs() is called (with some exceptions noted):

	      DOXYGEN_HAVE_DOT
		     Set  to YES if the	dot component was requested and	it was
		     found,  NO	 otherwise.  Any  existing  value   of	 DOXY-
		     GEN_HAVE_DOT is ignored.

	      DOXYGEN_DOT_MULTI_TARGETS
		     Set  to YES by this module	(note that this	requires a dot
		     version newer than	1.8.10). This option is	only  meaning-
		     ful if DOXYGEN_HAVE_DOT is	also set to YES.

	      DOXYGEN_GENERATE_LATEX
		     Set to NO by this module.

	      DOXYGEN_WARN_FORMAT
		     For  Visual  Studio  based	generators, this is set	to the
		     form recognized by	the Visual Studio IDE: $file($line)  :
		     $text.  For all other generators, Doxygen's default value
		     is	not overridden.

	      DOXYGEN_PROJECT_NAME
		     Populated with the	name  of  the  current	project	 (i.e.
		     PROJECT_NAME).

	      DOXYGEN_PROJECT_NUMBER
		     Populated	with  the version of the current project (i.e.
		     PROJECT_VERSION).

	      DOXYGEN_PROJECT_BRIEF
		     Populated with the	description  of	 the  current  project
		     (i.e.  PROJECT_DESCRIPTION).

	      DOXYGEN_INPUT
		     Projects  should  not set this variable. It will be popu-
		     lated with	the set	of files  and  directories  passed  to
		     doxygen_add_docs(), thereby providing consistent behavior
		     with the other built-in commands  like  add_executable(),
		     add_library()  and	 add_custom_target().  If  a  variable
		     named DOXYGEN_INPUT is set	by the project,	it will	be ig-
		     nored and a warning will be issued.

	      DOXYGEN_RECURSIVE
		     Set to YES	by this	module.

	      DOXYGEN_EXCLUDE_PATTERNS
		     If	 the set of inputs includes directories, this variable
		     will specify patterns used	to exclude  files  from	 them.
		     The following patterns are	added by doxygen_add_docs() to
		     ensure CMake-specific files and directories are  not  in-
		     cluded  in	 the  input.  If  the project sets DOXYGEN_EX-
		     CLUDE_PATTERNS, those contents are	merged with these  ad-
		     ditional patterns rather than replacing them:

			*/.git/*
			*/.svn/*
			*/.hg/*
			*/CMakeFiles/*
			*/_CPack_Packages/*
			DartConfiguration.tcl
			CMakeLists.txt
			CMakeCache.txt

	      DOXYGEN_OUTPUT_DIRECTORY
		     Set to CMAKE_CURRENT_BINARY_DIR by	this module. Note that
		     if	the project provides its own value for this and	it  is
		     a relative	path, it will be converted to an absolute path
		     relative to the current binary directory. This is	neces-
		     sary  because  doxygen will normally be run from a	direc-
		     tory within the source tree so that relative source paths
		     work  as  expected.  If this directory does not exist, it
		     will be recursively created prior to executing the	 doxy-
		     gen commands.

       To  change  any	of these defaults or override any other	Doxygen	config
       option, set relevant variables before calling  doxygen_add_docs().  For
       example:

	      set(DOXYGEN_GENERATE_HTML	NO)
	      set(DOXYGEN_GENERATE_MAN YES)

	      doxygen_add_docs(
		  doxygen
		  ${PROJECT_SOURCE_DIR}
		  COMMENT "Generate man	pages"
	      )

       A  number of Doxygen config options accept lists	of values, but Doxygen
       requires	them to	be separated by	whitespace. CMake variables hold lists
       as  a string with items separated by semi-colons, so a conversion needs
       to be performed.	The doxygen_add_docs() command specifically checks the
       following  Doxygen  config  options  and	 will convert their associated
       CMake variable's	contents into the required form	if set.

	  ABBREVIATE_BRIEF
	  ALIASES
	  CITE_BIB_FILES
	  DIAFILE_DIRS
	  DOTFILE_DIRS
	  DOT_FONTPATH
	  ENABLED_SECTIONS
	  EXAMPLE_PATH
	  EXAMPLE_PATTERNS
	  EXCLUDE
	  EXCLUDE_PATTERNS
	  EXCLUDE_SYMBOLS
	  EXPAND_AS_DEFINED
	  EXTENSION_MAPPING
	  EXTRA_PACKAGES
	  EXTRA_SEARCH_MAPPINGS
	  FILE_PATTERNS
	  FILTER_PATTERNS
	  FILTER_SOURCE_PATTERNS
	  HTML_EXTRA_FILES
	  HTML_EXTRA_STYLESHEET
	  IGNORE_PREFIX
	  IMAGE_PATH
	  INCLUDE_FILE_PATTERNS
	  INCLUDE_PATH
	  INPUT
	  LATEX_EXTRA_FILES
	  LATEX_EXTRA_STYLESHEET
	  MATHJAX_EXTENSIONS
	  MSCFILE_DIRS
	  PLANTUML_INCLUDE_PATH
	  PREDEFINED
	  QHP_CUST_FILTER_ATTRS
	  QHP_SECT_FILTER_ATTRS
	  STRIP_FROM_INC_PATH
	  STRIP_FROM_PATH
	  TAGFILES
	  TCL_SUBST

       The following single value Doxygen options will be quoted automatically
       if they contain at least	one space:

	  CHM_FILE
	  DIA_PATH
	  DOCBOOK_OUTPUT
	  DOCSET_FEEDNAME
	  DOCSET_PUBLISHER_NAME
	  DOT_FONTNAME
	  DOT_PATH
	  EXTERNAL_SEARCH_ID
	  FILE_VERSION_FILTER
	  GENERATE_TAGFILE
	  HHC_LOCATION
	  HTML_FOOTER
	  HTML_HEADER
	  HTML_OUTPUT
	  HTML_STYLESHEET
	  INPUT_FILTER
	  LATEX_FOOTER
	  LATEX_HEADER
	  LATEX_OUTPUT
	  LAYOUT_FILE
	  MAN_OUTPUT
	  MAN_SUBDIR
	  MATHJAX_CODEFILE
	  MSCGEN_PATH
	  OUTPUT_DIRECTORY
	  PERL_PATH
	  PLANTUML_JAR_PATH
	  PROJECT_BRIEF
	  PROJECT_LOGO
	  PROJECT_NAME
	  QCH_FILE
	  QHG_LOCATION
	  QHP_CUST_FILTER_NAME
	  QHP_VIRTUAL_FOLDER
	  RTF_EXTENSIONS_FILE
	  RTF_OUTPUT
	  RTF_STYLESHEET_FILE
	  SEARCHDATA_FILE
	  USE_MDFILE_AS_MAINPAGE
	  WARN_FORMAT
	  WARN_LOGFILE
	  XML_OUTPUT

       New  in	version	3.11: There are	situations where it may	be undesirable
       for a particular	config option to  be  automatically  quoted  by	 doxy-
       gen_add_docs(),	such  as ALIASES which may need	to include its own em-
       bedded quoting.	The DOXYGEN_VERBATIM_VARS  variable  can  be  used  to
       specify	a  list	 of  Doxygen variables (including the leading DOXYGEN_
       prefix) which should not	be quoted.  The	project	 is  then  responsible
       for  ensuring  that  those variables' values make sense when placed di-
       rectly in the Doxygen input file.  In the case of list variables,  list
       items  are  still separated by spaces, it is only the automatic quoting
       that is skipped.	 For example, the following allows  doxygen_add_docs()
       to  apply  quoting  to  DOXYGEN_PROJECT_BRIEF, but not each item	in the
       DOXYGEN_ALIASES list (bracket syntax can	also be	used to	 make  working
       with embedded quotes easier):

	  set(DOXYGEN_PROJECT_BRIEF "String with spaces")
	  set(DOXYGEN_ALIASES
	      [[somealias="@some_command param"]]
	      "anotherAlias=@foobar"
	  )
	  set(DOXYGEN_VERBATIM_VARS DOXYGEN_ALIASES)

       The resultant Doxyfile will contain the following lines:

	  PROJECT_BRIEF	= "String with spaces"
	  ALIASES	= somealias="@some_command param" anotherAlias=@foobar

   Deprecated Result Variables
       Deprecated since	version	3.9.

       For  compatibility with previous	versions of CMake, the following vari-
       ables are also defined but they are deprecated and should no longer  be
       used:

       DOXYGEN_EXECUTABLE
	      The  path	 to  the doxygen command. If projects need to refer to
	      the doxygen executable  directly,	 they  should  use  the	 Doxy-
	      gen::doxygen import target instead.

       DOXYGEN_DOT_FOUND
	      True if the dot executable was found.

       DOXYGEN_DOT_EXECUTABLE
	      The  path	 to  the dot command. If projects need to refer	to the
	      dot executable directly, they should use the Doxygen::dot	import
	      target instead.

       DOXYGEN_DOT_PATH
	      The  path	 to the	directory containing the dot executable	as re-
	      ported in	DOXYGEN_DOT_EXECUTABLE.	 The  path  may	 have  forward
	      slashes even on Windows and is not suitable for direct substitu-
	      tion into	a Doxyfile.in template.	 If you	need this  value,  get
	      the  IMPORTED_LOCATION  property	of the Doxygen::dot target and
	      use get_filename_component() to extract the  directory  part  of
	      that  path.  You	may  also  want	 to consider using file(TO_NA-
	      TIVE_PATH) to prepare the	path for a Doxygen configuration file.

   Deprecated Hint Variables
       Deprecated since	version	3.9.

       DOXYGEN_SKIP_DOT
	      This variable has	no effect for the component form of find_pack-
	      age.   In	 backward  compatibility mode (i.e. without components
	      list)  it	 prevents  the	finder	module	from   searching   for
	      Graphviz's dot utility.

   FindEnvModules
       New in version 3.15.

       Locate an environment module implementation and make commands available
       to CMake	scripts	to use them.  This is compatible with  both  Lua-based
       Lmod and	TCL-based EnvironmentModules.

       This module is intended for the use case	of setting up the compiler and
       library environment within a CTest Script (ctest	-S).  It can  also  be
       used in a CMake Script (cmake -P).

       NOTE:
	  The  loaded environment will not survive past	the end	of the calling
	  process.  Do not use this module  in	project	 code  (CMakeLists.txt
	  files) to load a compiler environment; it will not be	available dur-
	  ing the build.  Instead load the environment manually	before running
	  CMake	or using the generated build system.

   Example Usage
	  set(CTEST_BUILD_NAME "CrayLinux-CrayPE-Cray-dynamic")
	  set(CTEST_BUILD_CONFIGURATION	Release)
	  set(CTEST_BUILD_FLAGS	"-k -j8")
	  set(CTEST_CMAKE_GENERATOR "Unix Makefiles")

	  ...

	  find_package(EnvModules REQUIRED)

	  env_module(purge)
	  env_module(load modules)
	  env_module(load craype)
	  env_module(load PrgEnv-cray)
	  env_module(load craype-knl)
	  env_module(load cray-mpich)
	  env_module(load cray-libsci)

	  set(ENV{CRAYPE_LINK_TYPE} dynamic)

	  ...

   Result Variables
       This module will	set the	following variables in your project:

       EnvModules_FOUND
	      True if a	compatible environment modules framework was found.

   Cache Variables
       The following cache variable will be set:

       EnvModules_COMMAND
	      The low level module command to use.  Currently supported	imple-
	      mentations are the Lua based Lmod	and TCL	based  EnvironmentMod-
	      ules.

   Environment Variables
       ENV{MODULESHOME}
	      Usually  set by the module environment implementation, used as a
	      hint to locate the module	command	to execute.

   Provided Functions
       This defines the	following CMake	functions for interacting  with	 envi-
       ronment modules:

       env_module
	      Execute an aribitrary module command:

		 env_module(cmd	arg1 ... argN)
		 env_module(
		   COMMAND cmd arg1 ...	argN
		   [OUTPUT_VARIABLE <out-var>]
		   [RESULT_VARIABLE <ret-var>]
		 )

	      The options are:

	      cmd arg1 ... argN
		     The  module  sub-command  and  arguments to execute as if
		     they were passed directly to the module command  in  your
		     shell environment.

	      OUTPUT_VARIABLE <out-var>
		     The standard output from executing	the module command.

	      RESULT_VARIABLE <ret-var>
		     The return	code from executing the	module command.

       env_module_swap
	      Swap one module for another:

		 env_module_swap(out_mod in_mod
		   [OUTPUT_VARIABLE <out-var>]
		   [RESULT_VARIABLE <ret-var>]
		 )

	      This  is	functionally  equivalent  to  the  module swap out_mod
	      in_mod shell command.  The options are:

	      OUTPUT_VARIABLE <out-var>
		     The standard output from executing	the module command.

	      RESULT_VARIABLE <ret-var>
		     The return	code from executing the	module command.

       env_module_list
	      Retrieve the list	of currently loaded modules:

		 env_module_list(<out-var>)

	      This is functionally equivalent to the module  list  shell  com-
	      mand.  The result	is stored in <out-var> as a properly formatted
	      CMake semicolon-separated	list variable.

       env_module_avail
	      Retrieve the list	of available modules:

		 env_module_avail([<mod-prefix>] <out-var>)

	      This is functionally equivalent to the module avail <mod-prefix>
	      shell  command.  The result is stored in <out-var> as a properly
	      formatted	CMake semicolon-separated list variable.

   FindEXPAT
       Find the	native Expat headers and library.  Expat is a  stream-oriented
       XML parser library written in C.

   Imported Targets
       New in version 3.10.

       This module defines the following IMPORTED targets:

       EXPAT::EXPAT
	      The Expat	expat library, if found.

   Result Variables
       This module will	set the	following variables in your project:

       EXPAT_INCLUDE_DIRS
	      where to find expat.h, etc.

       EXPAT_LIBRARIES
	      the libraries to link against to use Expat.

       EXPAT_FOUND
	      true if the Expat	headers	and libraries were found.

   FindFLEX
       Find  Fast  Lexical  Analyzer (Flex) executable and provides a macro to
       generate	custom build rules

       The module defines the following	variables:

	  FLEX_FOUND - True is flex executable is found
	  FLEX_EXECUTABLE - the	path to	the flex executable
	  FLEX_VERSION - the version of	flex
	  FLEX_LIBRARIES - The flex libraries
	  FLEX_INCLUDE_DIRS - The path to the flex headers

       The minimum required version of flex can	be specified using  the	 stan-
       dard syntax, e.g.  find_package(FLEX 2.5.13)

       If flex is found	on the system, the module provides the macro:

	  FLEX_TARGET(Name FlexInput FlexOutput
		      [COMPILE_FLAGS <string>]
		      [DEFINES_FILE <string>]
		      )

       which creates a custom command to generate the FlexOutput file from the
       FlexInput file.	Name is	an alias used to get details  of  this	custom
       command.	  If  COMPILE_FLAGS option is specified, the next parameter is
       added to	the flex command line.

       New in version 3.5: If flex is configured to output a header file,  the
       DEFINES_FILE option may be used to specify its name.

       Changed	in  version 3.17: When CMP0098 is set to NEW, flex runs	in the
       CMAKE_CURRENT_BINARY_DIR	directory.

       The macro defines the following variables:

	  FLEX_${Name}_DEFINED - true is the macro ran successfully
	  FLEX_${Name}_OUTPUTS - the source file generated by the custom rule, an
	  alias	for FlexOutput
	  FLEX_${Name}_INPUT - the flex	source file, an	alias for ${FlexInput}
	  FLEX_${Name}_OUTPUT_HEADER - the header flex output, if any.

       Flex scanners often use tokens defined by Bison:	the code generated  by
       Flex  depends  of  the header generated by Bison.  This module also de-
       fines a macro:

	  ADD_FLEX_BISON_DEPENDENCY(FlexTarget BisonTarget)

       which adds the required dependency between a scanner and	a parser where
       FlexTarget  and	BisonTarget  are  the first parameters of respectively
       FLEX_TARGET and BISON_TARGET macros.

	  ====================================================================
	  Example:

	  find_package(BISON)
	  find_package(FLEX)

	  BISON_TARGET(MyParser	parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp)
	  FLEX_TARGET(MyScanner	lexer.l	 ${CMAKE_CURRENT_BINARY_DIR}/lexer.cpp)
	  ADD_FLEX_BISON_DEPENDENCY(MyScanner MyParser)

	   include_directories(${CMAKE_CURRENT_BINARY_DIR})
	   add_executable(Foo
	      Foo.cc
	      ${BISON_MyParser_OUTPUTS}
	      ${FLEX_MyScanner_OUTPUTS}
	   )
	   target_link_libraries(Foo ${FLEX_LIBRARIES})
	  ====================================================================

   FindFLTK
       Find the	Fast Light Toolkit (FLTK) library

   Input Variables
       By default this module will search for all of the FLTK  components  and
       add  them to the	FLTK_LIBRARIES variable.  You can limit	the components
       which get placed	in FLTK_LIBRARIES by defining one or more of the  fol-
       lowing three options:

       FLTK_SKIP_OPENGL
	      Set to true to disable searching for the FLTK GL library

       FLTK_SKIP_FORMS
	      Set to true to disable searching for the FLTK Forms library

       FLTK_SKIP_IMAGES
	      Set to true to disable searching for the FLTK Images library

       FLTK  is	 composed also by a binary tool. You can set the following op-
       tion:

       FLTK_SKIP_FLUID
	      Set to true to not look for the FLUID binary

   Result Variables
       The following variables will be defined:

       FLTK_FOUND
	      True if all components not skipped were found

       FLTK_INCLUDE_DIR
	      Path to the include directory for	FLTK header files

       FLTK_LIBRARIES
	      List of the FLTK libraries found

       FLTK_FLUID_EXECUTABLE
	      Path to the FLUID	binary tool

       FLTK_WRAP_UI
	      True if FLUID is found, used to enable the FLTK_WRAP_UI command

   Cache Variables
       The following cache variables are also available	to set or use:

       FLTK_BASE_LIBRARY_RELEASE
	      The FLTK base library (optimized)

       FLTK_BASE_LIBRARY_DEBUG
	      The FLTK base library (debug)

       FLTK_GL_LIBRARY_RELEASE
	      The FLTK GL library (optimized)

       FLTK_GL_LIBRARY_DEBUG
	      The FLTK GL library (debug)

       FLTK_FORMS_LIBRARY_RELEASE
	      The FLTK Forms library (optimized)

       FLTK_FORMS_LIBRARY_DEBUG
	      The FLTK Forms library (debug)

       FLTK_IMAGES_LIBRARY_RELEASE
	      The FLTK Images protobuf library (optimized)

       FLTK_IMAGES_LIBRARY_DEBUG
	      The FLTK Images library (debug)

       New in version 3.11: Debug and Release variants	are  found  separately
       and use per-configuration variables.

   FindFLTK2
       Find the	native FLTK 2.0	includes and library

       The following settings are defined

	  FLTK2_FLUID_EXECUTABLE, where	to find	the Fluid tool
	  FLTK2_WRAP_UI, This enables the FLTK2_WRAP_UI	command
	  FLTK2_INCLUDE_DIR, where to find include files
	  FLTK2_LIBRARIES, list	of fltk2 libraries
	  FLTK2_FOUND, Don't use FLTK2 if false.

       The following settings should not be used in general.

	  FLTK2_BASE_LIBRARY   = the full path to fltk2.lib
	  FLTK2_GL_LIBRARY     = the full path to fltk2_gl.lib
	  FLTK2_IMAGES_LIBRARY = the full path to fltk2_images.lib

   FindFontconfig
       New in version 3.14.

       Find Fontconfig headers and library.

   Imported Targets
       Fontconfig::Fontconfig
	      The Fontconfig library, if found.

   Result Variables
       This will define	the following variables	in your	project:

       Fontconfig_FOUND
	      true if (the requested version of) Fontconfig is available.

       Fontconfig_VERSION
	      the version of Fontconfig.

       Fontconfig_LIBRARIES
	      the libraries to link against to use Fontconfig.

       Fontconfig_INCLUDE_DIRS
	      where to find the	Fontconfig headers.

       Fontconfig_COMPILE_OPTIONS
	      this should be passed to target_compile_options(), if the	target
	      is not used for linking

   FindFreetype
       Find the	FreeType font renderer includes	and library.

   Imported Targets
       New in version 3.10.

       This module defines the following IMPORTED target:

       Freetype::Freetype
	      The Freetype freetype library, if	found

   Result Variables
       This module will	set the	following variables in your project:

       FREETYPE_FOUND
	      true if the Freetype headers and libraries were found

       FREETYPE_INCLUDE_DIRS
	      directories containing the Freetype headers. This	 is  the  con-
	      catenation of the	variables:

	      FREETYPE_INCLUDE_DIR_ft2build
		     directory	holding	 the  main  Freetype API configuration
		     header

	      FREETYPE_INCLUDE_DIR_freetype2
		     directory holding Freetype	public headers

       FREETYPE_LIBRARIES
	      the library to link against

       FREETYPE_VERSION_STRING
	      the version of freetype found

       New in version 3.7: Debug and Release variants are found	separately.

   Hints
       The user	may set	the environment	variable FREETYPE_DIR to the root  di-
       rectory of a Freetype installation.

   FindGCCXML
       Find the	GCC-XML	front-end executable.

       This module will	define the following variables:

	  GCCXML - the GCC-XML front-end executable.

   FindGDAL
       Find Geospatial Data Abstraction	Library	(GDAL).

   IMPORTED Targets
       New in version 3.14.

       This module defines IMPORTED target GDAL::GDAL if GDAL has been found.

   Result Variables
       This module will	set the	following variables in your project:

       GDAL_FOUND
	      True if GDAL is found.

       GDAL_INCLUDE_DIRS
	      Include directories for GDAL headers.

       GDAL_LIBRARIES
	      Libraries	to link	to GDAL.

       GDAL_VERSION
	      New in version 3.14: The version of GDAL found.

   Cache variables
       The following cache variables may also be set:

       GDAL_LIBRARY
	      The libgdal library file.

       GDAL_INCLUDE_DIR
	      The directory containing gdal.h.

   Hints
       Set  GDAL_DIR  or  GDAL_ROOT in the environment to specify the GDAL in-
       stallation prefix.

       The following variables may be set to modify the	search strategy:

       FindGDAL_SKIP_GDAL_CONFIG
	      If set, gdal-config will not be used.  This  can	be  useful  if
	      there are	GDAL libraries built with autotools (which provide the
	      tool) and	CMake (which do	not) in	the same environment.

       GDAL_ADDITIONAL_LIBRARY_VERSIONS
	      Extra versions of	library	names to search	for.

   FindGettext
       Find GNU	gettext	tools

       This module looks for the GNU gettext tools.  This module  defines  the
       following values:

	  GETTEXT_MSGMERGE_EXECUTABLE: the full	path to	the msgmerge tool.
	  GETTEXT_MSGFMT_EXECUTABLE: the full path to the msgfmt tool.
	  GETTEXT_FOUND: True if gettext has been found.
	  GETTEXT_VERSION_STRING: the version of gettext found (since CMake 2.8.8)

       Additionally it provides	the following macros:

       GETTEXT_CREATE_TRANSLATIONS ( outputFile	[ALL] file1 ...	 fileN )

	  This will create a target "translations" which will convert the
	  given	input po files into the	binary output mo file. If the
	  ALL option is	used, the translations will also be created when
	  building the default target.

       GETTEXT_PROCESS_POT_FILE(  <potfile>  [ALL] [INSTALL_DESTINATION	<dest-
       dir>] LANGUAGES <lang1> <lang2> ...  )

	  Process the given pot	file to	mo files.
	  If INSTALL_DESTINATION is given then automatically install rules will
	  be created, the language subdirectory	will be	taken into account
	  (by default use share/locale/).
	  If ALL is specified, the pot file is processed when building the all traget.
	  It creates a custom target "potfile".

       GETTEXT_PROCESS_PO_FILES(  <lang>  [ALL]	 [INSTALL_DESTINATION	<dir>]
       PO_FILES	<po1> <po2> ...	 )

	  Process the given po files to	mo files for the given language.
	  If INSTALL_DESTINATION is given then automatically install rules will
	  be created, the language subdirectory	will be	taken into account
	  (by default use share/locale/).
	  If ALL is specified, the po files are	processed when building	the all	traget.
	  It creates a custom target "pofiles".

       New  in	version	3.2: If	you wish to use	the Gettext library (libintl),
       use FindIntl.

   FindGIF
       This finds the Graphics Interchange Format (GIF)	library	(giflib)

   Imported targets
       This module defines the following IMPORTED target:

       GIF::GIF
	      The giflib library, if found.

   Result variables
       This module will	set the	following variables in your project:

       GIF_FOUND
	      If false,	do not try to use GIF.

       GIF_INCLUDE_DIRS
	      where to find gif_lib.h, etc.

       GIF_LIBRARIES
	      the libraries needed to use GIF.

       GIF_VERSION
	      3, 4 or a	full version string (eg	5.1.4) for versions >= 4.1.6.

   Cache variables
       The following cache variables may also be set:

       GIF_INCLUDE_DIR
	      where to find the	GIF headers.

       GIF_LIBRARY
	      where to find the	GIF library.

   Hints
       GIF_DIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$GIF_DIR.

   FindGit
       The module defines the following	variables:

       GIT_EXECUTABLE
	      Path to Git command-line client.

       Git_FOUND, GIT_FOUND
	      True if the Git command-line client was found.

       GIT_VERSION_STRING
	      The version of Git found.

       New  in version 3.14: The module	defines	the following IMPORTED targets
       (when CMAKE_ROLE	is PROJECT):

       Git::Git
	      Executable of the	Git command-line client.

       Example usage:

	  find_package(Git)
	  if(Git_FOUND)
	    message("Git found:	${GIT_EXECUTABLE}")
	  endif()

   FindGLEW
       Find the	OpenGL Extension Wrangler Library (GLEW)

   Input Variables
       The following variables may be set to influence this module's behavior:

       GLEW_USE_STATIC_LIBS
	      to find and create IMPORTED target for static linkage.

       GLEW_VERBOSE
	      to output	a detailed log of this module.

   Imported Targets
       New in version 3.1.

       This module defines the following Imported Targets:

       GLEW::glew
	      The GLEW shared library.

       GLEW::glew_s
	      The GLEW static library, if GLEW_USE_STATIC_LIBS is set to TRUE.

       GLEW::GLEW
	      Duplicates either	GLEW::glew or GLEW::glew_s based on availabil-
	      ity.

   Result Variables
       This module defines the following variables:

       GLEW_INCLUDE_DIRS
	      include directories for GLEW

       GLEW_LIBRARIES
	      libraries	to link	against	GLEW

       GLEW_SHARED_LIBRARIES
	      libraries	to link	against	shared GLEW

       GLEW_STATIC_LIBRARIES
	      libraries	to link	against	static GLEW

       GLEW_FOUND
	      true if GLEW has been found and can be used

       GLEW_VERSION
	      GLEW version

       GLEW_VERSION_MAJOR
	      GLEW major version

       GLEW_VERSION_MINOR
	      GLEW minor version

       GLEW_VERSION_MICRO
	      GLEW micro version

       New in version 3.7: Debug and Release variants are found	separately.

   FindGLUT
       Find OpenGL Utility Toolkit (GLUT) library and include files.

   IMPORTED Targets
       New in version 3.1.

       This module defines the IMPORTED	targets:

       GLUT::GLUT
	      Defined if the system has	GLUT.

   Result Variables
       This module sets	the following variables:

	  GLUT_INCLUDE_DIR, where to find GL/glut.h, etc.
	  GLUT_LIBRARIES, the libraries	to link	against
	  GLUT_FOUND, If false,	do not try to use GLUT.

       Also defined, but not for general use are:

	  GLUT_glut_LIBRARY = the full path to the glut	library.
	  GLUT_Xmu_LIBRARY  = the full path to the Xmu library.
	  GLUT_Xi_LIBRARY   = the full path to the Xi Library.

       New in version 3.13: Debug and Release variants are found separately.

   FindGnuplot
       this module looks for gnuplot

       Once done this will define

	  GNUPLOT_FOUND	- system has Gnuplot
	  GNUPLOT_EXECUTABLE - the Gnuplot executable
	  GNUPLOT_VERSION_STRING - the version of Gnuplot found	(since CMake 2.8.8)

       GNUPLOT_VERSION_STRING will not work for	old versions like 3.7.1.

   FindGnuTLS
       Find the	GNU Transport Layer Security library (gnutls)

   IMPORTED Targets
       New in version 3.16.

       This  module defines IMPORTED target GnuTLS::GnuTLS, if gnutls has been
       found.

   Result Variables
       GNUTLS_FOUND
	      System has gnutls

       GNUTLS_INCLUDE_DIR
	      The gnutls include directory

       GNUTLS_LIBRARIES
	      The libraries needed to use gnutls

       GNUTLS_DEFINITIONS
	      Compiler switches	required for using gnutls

       GNUTLS_VERSION
	      version of gnutls.

   FindGSL
       New in version 3.2.

       Find the	native GNU Scientific Library (GSL) includes and libraries.

       The GNU Scientific Library (GSL)	is a numerical library for C  and  C++
       programmers. It is free software	under the GNU General Public License.

   Imported Targets
       If GSL is found,	this module defines the	following IMPORTED targets:

	  GSL::gsl	- The main GSL library.
	  GSL::gslcblas	- The CBLAS support library used by GSL.

   Result Variables
       This module will	set the	following variables in your project:

	  GSL_FOUND	     - True if GSL found on the	local system
	  GSL_INCLUDE_DIRS   - Location	of GSL header files.
	  GSL_LIBRARIES	     - The GSL libraries.
	  GSL_VERSION	     - The version of the discovered GSL install.

   Hints
       Set GSL_ROOT_DIR	to a directory that contains a GSL installation.

       This  script expects to find libraries at $GSL_ROOT_DIR/lib and the GSL
       headers at $GSL_ROOT_DIR/include/gsl.  The library  directory  may  op-
       tionally	provide	Release	and Debug folders. If available, the libraries
       named gsld, gslblasd or cblasd are recognized as	debug libraries.   For
       Unix-like  systems,  this  script will use $GSL_ROOT_DIR/bin/gsl-config
       (if found) to aid in the	discovery of GSL.

   Cache Variables
       This module may set the following variables depending on	 platform  and
       type of GSL installation	discovered.  These variables may optionally be
       set to help this	module find the	correct	files:

	  GSL_CBLAS_LIBRARY	  - Location of	the GSL	CBLAS library.
	  GSL_CBLAS_LIBRARY_DEBUG - Location of	the debug GSL CBLAS library (if	any).
	  GSL_CONFIG_EXECUTABLE	  - Location of	the ``gsl-config`` script (if any).
	  GSL_LIBRARY		  - Location of	the GSL	library.
	  GSL_LIBRARY_DEBUG	  - Location of	the debug GSL library (if any).

   FindGTest
       Locate the Google C++ Testing Framework.

       New in version 3.20: Upstream GTestConfig.cmake is used if possible.

   Imported targets
       New in version 3.20: This module	defines	the  following	IMPORTED  tar-
       gets:

       GTest::gtest
	      The Google Test gtest library, if	found; adds Thread::Thread au-
	      tomatically

       GTest::gtest_main
	      The Google Test gtest_main library, if found

       Deprecated since	version	3.20: For backwards compatibility, this	module
       defines	additionally the following deprecated IMPORTED targets (avail-
       able since 3.5):

       GTest::GTest
	      The Google Test gtest library, if	found; adds Thread::Thread au-
	      tomatically

       GTest::Main
	      The Google Test gtest_main library, if found

   Result variables
       This module will	set the	following variables in your project:

       GTest_FOUND
	      Found the	Google Testing framework

       GTEST_INCLUDE_DIRS
	      the directory containing the Google Test headers

       The library variables below are set as normal variables.	 These contain
       debug/optimized keywords	when a debugging library is found.

       GTEST_LIBRARIES
	      The Google Test gtest library; note  it  also  requires  linking
	      with an appropriate thread library

       GTEST_MAIN_LIBRARIES
	      The Google Test gtest_main library

       GTEST_BOTH_LIBRARIES
	      Both gtest and gtest_main

   Cache variables
       The following cache variables may also be set:

       GTEST_ROOT
	      The  root	directory of the Google	Test installation (may also be
	      set as an	environment variable)

       GTEST_MSVC_SEARCH
	      If compiling with	MSVC, this variable can	be set	to  MT	or  MD
	      (the default) to enable searching	a GTest	build tree

   Example usage
	  enable_testing()
	  find_package(GTest REQUIRED)

	  add_executable(foo foo.cc)
	  target_link_libraries(foo GTest::gtest GTest::gtest_main)

	  add_test(AllTestsInFoo foo)

   Deeper integration with CTest
       See  GoogleTest for information on the gtest_add_tests()	and gtest_dis-
       cover_tests() commands.

       Changed	 in   version	3.9:   Previous	  CMake	   versions    defined
       gtest_add_tests() macro in this module.

   FindGTK
       Find GTK, glib and GTKGLArea

	  GTK_INCLUDE_DIR   - Directories to include to	use GTK
	  GTK_LIBRARIES	    - Files to link against to use GTK
	  GTK_FOUND	    - GTK was found
	  GTK_GL_FOUND	    - GTK's GL features	were found

   FindGTK2
       Find the	GTK2 widget libraries and several of its other optional	compo-
       nents like gtkmm, glade,	and glademm.

       Specify one or more of the following components as you call  this  find
       module.	See example below.

       o gtk

       o gtkmm

       o glade

       o glademm

   Imported Targets
       This  module  defines the following IMPORTED targets (subject to	compo-
       nent selection):

       GTK2::atk, GTK2::atkmm, GTK2::cairo,  GTK2::cairomm,  GTK2::gdk_pixbuf,
       GTK2::gdk,    GTK2::gdkmm,    GTK2::gio,	   GTK2::giomm,	  GTK2::glade,
       GTK2::glademm, GTK2::glib, GTK2::glibmm,	GTK2::gmodule,	GTK2::gobject,
       GTK2::gthread,  GTK2::gtk,  GTK2::gtkmm,	 GTK2::harfbuzz,  GTK2::pango,
       GTK2::pangocairo,   GTK2::pangoft2,   GTK2::pangomm,    GTK2::pangoxft,
       GTK2::sigc.

       New in version 3.16.7: Added the	GTK2::harfbuzz target.

   Result Variables
       The following variables will be defined for your	use

       GTK2_FOUND
	      Were all of your specified components found?

       GTK2_INCLUDE_DIRS
	      All include directories

       GTK2_LIBRARIES
	      All libraries

       GTK2_TARGETS
	      New in version 3.5: All imported targets

       GTK2_DEFINITIONS
	      Additional compiler flags

       GTK2_VERSION
	      The version of GTK2 found	(x.y.z)

       GTK2_MAJOR_VERSION
	      The major	version	of GTK2

       GTK2_MINOR_VERSION
	      The minor	version	of GTK2

       GTK2_PATCH_VERSION
	      The patch	version	of GTK2

       New  in	version	 3.5:  When  GTK2_USE_IMPORTED_TARGETS is set to TRUE,
       GTK2_LIBRARIES will list	imported targets instead of library paths.

   Input Variables
       Optional	variables you can define prior to calling this module:

       GTK2_DEBUG
	      Enables verbose debugging	of the module

       GTK2_ADDITIONAL_SUFFIXES
	      Allows defining additional directories  to  search  for  include
	      files

   Example Usage
       Call find_package() once.  Here are some	examples to pick from:

       Require GTK 2.6 or later:

	  find_package(GTK2 2.6	REQUIRED gtk)

       Require GTK 2.10	or later and Glade:

	  find_package(GTK2 2.10 REQUIRED gtk glade)

       Search for GTK/GTKMM 2.8	or later:

	  find_package(GTK2 2.8	COMPONENTS gtk gtkmm)

       Use the results:

	  if(GTK2_FOUND)
	    include_directories(${GTK2_INCLUDE_DIRS})
	    add_executable(mygui mygui.cc)
	    target_link_libraries(mygui	${GTK2_LIBRARIES})
	  endif()

   FindHDF5
       Find Hierarchical Data Format (HDF5), a library for reading and writing
       self describing array data.

       This module invokes the HDF5 wrapper compiler that should be  installed
       alongside  HDF5.	  Depending  upon  the HDF5 Configuration, the wrapper
       compiler	is called either h5cc or h5pcc.	 If this succeeds, the	module
       will  then  call	 the compiler with the show argument to	see what flags
       are used	when compiling an HDF5 client application.

       The module will optionally accept the COMPONENTS	argument.  If no  COM-
       PONENTS	are  specified,	 then  the find	module will default to finding
       only the	HDF5 C library.	 If one	or more	COMPONENTS are specified,  the
       module  will  attempt  to  find the language bindings for the specified
       components.  The	valid components are C,	CXX, Fortran, HL.   HL	refers
       to  the	"high-level"  HDF5 functions for C and Fortran.	 If the	COMPO-
       NENTS argument is not given, the	module will attempt to find only the C
       bindings.   For example,	to use Fortran HDF5 and	HDF5-HL	functions, do:
       find_package(HDF5 COMPONENTS Fortran HL).

       This module will	read the variable HDF5_USE_STATIC_LIBRARIES to	deter-
       mine  whether or	not to prefer a	static link to a dynamic link for HDF5
       and all of it's dependencies.  To use this feature, make	sure that  the
       HDF5_USE_STATIC_LIBRARIES variable is set before	the call to find_pack-
       age.

       New in version 3.10: Support for	HDF5_USE_STATIC_LIBRARIES on Windows.

       Both the	serial and parallel HDF5 wrappers are considered and the first
       directory  to  contain either one will be used.	In the event that both
       appear in the same directory the	serial version is  preferentially  se-
       lected. This behavior can be reversed by	setting	the variable HDF5_PRE-
       FER_PARALLEL to TRUE.

       In addition to finding the includes and libraries required  to  compile
       an  HDF5	 client	 application, this module also makes an	effort to find
       tools that come with the	HDF5 distribution that may be useful  for  re-
       gression	testing.

   Result Variables
       This module will	set the	following variables in your project:

       HDF5_FOUND
	      HDF5 was found on	the system

       HDF5_VERSION
	      New in version 3.3: HDF5 library version

       HDF5_INCLUDE_DIRS
	      Location of the HDF5 header files

       HDF5_DEFINITIONS
	      Required compiler	definitions for	HDF5

       HDF5_LIBRARIES
	      Required libraries for all requested bindings

       HDF5_HL_LIBRARIES
	      Required libraries for the HDF5 high level API for all bindings,
	      if the HL	component is enabled

       Available components are: C CXX Fortran and HL.	For each enabled  lan-
       guage binding, a	corresponding HDF5_${LANG}_LIBRARIES variable, and po-
       tentially HDF5_${LANG}_DEFINITIONS, will	be defined.  If	the HL	compo-
       nent  is	 enabled,  then	 an HDF5_${LANG}_HL_LIBRARIES will also	be de-
       fined.  With all	components enabled, the	following  variables  will  be
       defined:

       HDF5_C_DEFINITIONS
	      Required compiler	definitions for	HDF5 C bindings

       HDF5_CXX_DEFINITIONS
	      Required compiler	definitions for	HDF5 C++ bindings

       HDF5_Fortran_DEFINITIONS
	      Required compiler	definitions for	HDF5 Fortran bindings

       HDF5_C_INCLUDE_DIRS
	      Required include directories for HDF5 C bindings

       HDF5_CXX_INCLUDE_DIRS
	      Required include directories for HDF5 C++	bindings

       HDF5_Fortran_INCLUDE_DIRS
	      Required include directories for HDF5 Fortran bindings

       HDF5_C_LIBRARIES
	      Required libraries for the HDF5 C	bindings

       HDF5_CXX_LIBRARIES
	      Required libraries for the HDF5 C++ bindings

       HDF5_Fortran_LIBRARIES
	      Required libraries for the HDF5 Fortran bindings

       HDF5_C_HL_LIBRARIES
	      Required libraries for the high level C bindings

       HDF5_CXX_HL_LIBRARIES
	      Required libraries for the high level C++	bindings

       HDF5_Fortran_HL_LIBRARIES
	      Required libraries for the high level Fortran bindings.

       HDF5_IS_PARALLEL
	      HDF5 library has parallel	IO support

       HDF5_C_COMPILER_EXECUTABLE
	      path to the HDF5 C wrapper compiler

       HDF5_CXX_COMPILER_EXECUTABLE
	      path to the HDF5 C++ wrapper compiler

       HDF5_Fortran_COMPILER_EXECUTABLE
	      path to the HDF5 Fortran wrapper compiler

       HDF5_C_COMPILER_EXECUTABLE_NO_INTERROGATE
	      path to the primary C compiler which is also the HDF5 wrapper

       HDF5_CXX_COMPILER_EXECUTABLE_NO_INTERROGATE
	      path to the primary C++ compiler which is	also the HDF5 wrapper

       HDF5_Fortran_COMPILER_EXECUTABLE_NO_INTERROGATE
	      path  to	the  primary  Fortran  compiler	which is also the HDF5
	      wrapper

       HDF5_DIFF_EXECUTABLE
	      path to the HDF5 dataset comparison tool

       With all	components enabled, the	following targets will be defined:

       HDF5::HDF5
	      All detected HDF5_LIBRARIES.

       hdf5::hdf5
	      C	library.

       hdf5::hdf5_cpp
	      C++ library.

       hdf5::hdf5_fortran
	      Fortran library.

       hdf5::hdf5_hl
	      High-level C library.

       hdf5::hdf5_hl_cpp
	      High-level C++ library.

       hdf5::hdf5_hl_fortran
	      High-level Fortran library.

       hdf5::h5diff
	      h5diff executable.

   Hints
       The following variables can be set to guide the	search	for  HDF5  li-
       braries and includes:

       HDF5_PREFER_PARALLEL
	      New in version 3.4.

	      set  true	 to  prefer  parallel HDF5 (by default,	serial is pre-
	      ferred)

       HDF5_FIND_DEBUG
	      New in version 3.9.

	      Set true to get extra debugging output.

       HDF5_NO_FIND_PACKAGE_CONFIG_FILE
	      New in version 3.8.

	      Set true to skip trying to find hdf5-config.cmake.

   FindHg
       Extract information from	a mercurial working copy.

       The module defines the following	variables:

	  HG_EXECUTABLE	- path to mercurial command line client	(hg)
	  HG_FOUND - true if the command line client was found
	  HG_VERSION_STRING - the version of mercurial found

       New in version 3.1: If the command line client executable is found  the
       following macro is defined:

	  HG_WC_INFO(<dir> <var-prefix>)

       Hg_WC_INFO  extracts information	of a mercurial working copy at a given
       location.  This macro defines the following variables:

	  <var-prefix>_WC_CHANGESET - current changeset
	  <var-prefix>_WC_REVISION - current revision

       Example usage:

	  find_package(Hg)
	  if(HG_FOUND)
	    message("hg	found: ${HG_EXECUTABLE}")
	    HG_WC_INFO(${PROJECT_SOURCE_DIR} Project)
	    message("Current revision is ${Project_WC_REVISION}")
	    message("Current changeset is ${Project_WC_CHANGESET}")
	  endif()

   FindHSPELL
       Try to find Hebrew spell-checker	(Hspell) and morphology	engine.

       Once done this will define

	  HSPELL_FOUND - system	has Hspell
	  HSPELL_INCLUDE_DIR - the Hspell include directory
	  HSPELL_LIBRARIES - The libraries needed to use Hspell
	  HSPELL_DEFINITIONS - Compiler	switches required for using Hspell

	  HSPELL_VERSION_STRING	- The version of Hspell	found (x.y)
	  HSPELL_MAJOR_VERSION	- the major version of Hspell
	  HSPELL_MINOR_VERSION	- The minor version of Hspell

   FindHTMLHelp
       This module looks for Microsoft HTML Help Compiler

       It defines:

	  HTML_HELP_COMPILER	 : full	path to	the Compiler (hhc.exe)
	  HTML_HELP_INCLUDE_PATH : include path	to the API (htmlhelp.h)
	  HTML_HELP_LIBRARY	 : full	path to	the library (htmlhelp.lib)

   FindIce
       New in version 3.1.

       Find the	ZeroC Internet Communication Engine (ICE) programs,  libraries
       and datafiles.

       This  module  supports multiple components.  Components can include any
       of: Freeze, Glacier2, Ice, IceBox, IceDB, IceDiscovery, IceGrid,	IceLo-
       catorDiscovery, IcePatch, IceSSL, IceStorm, IceUtil, IceXML, or Slice.

       Ice 3.7 and later also include C++11-specific components: Glacier2++11,
       Ice++11,	IceBox++11, IceDiscovery++11 IceGrid, IceLocatorDiscovery++11,
       IceSSL++11, IceStorm++11

       Note that the set of supported components is Ice	version-specific.

       New in version 3.4: Imported targets for	components and most EXECUTABLE
       variables.

       New in version 3.7: Debug and Release variants are found	separately.

       New in version 3.10: Ice	3.7 support, including	new  components,  pro-
       grams and the Nuget package.

       This  module  reports information about the Ice installation in several
       variables.  General variables:

	  Ice_VERSION -	Ice release version
	  Ice_FOUND - true if the main programs	and libraries were found
	  Ice_LIBRARIES	- component libraries to be linked
	  Ice_INCLUDE_DIRS - the directories containing	the Ice	headers
	  Ice_SLICE_DIRS - the directories containing the Ice slice interface
			   definitions

       Imported	targets:

	  Ice::<C>

       Where <C> is the	name of	an Ice component, for example Ice::Glacier2 or
       Ice++11.

       Ice slice programs are reported in:

	  Ice_SLICE2CONFLUENCE_EXECUTABLE - path to slice2confluence executable
	  Ice_SLICE2CPP_EXECUTABLE - path to slice2cpp executable
	  Ice_SLICE2CS_EXECUTABLE - path to slice2cs executable
	  Ice_SLICE2FREEZEJ_EXECUTABLE - path to slice2freezej executable
	  Ice_SLICE2FREEZE_EXECUTABLE -	path to	slice2freeze executable
	  Ice_SLICE2HTML_EXECUTABLE - path to slice2html executable
	  Ice_SLICE2JAVA_EXECUTABLE - path to slice2java executable
	  Ice_SLICE2JS_EXECUTABLE - path to slice2js executable
	  Ice_SLICE2MATLAB_EXECUTABLE -	path to	slice2matlab executable
	  Ice_SLICE2OBJC_EXECUTABLE - path to slice2objc executable
	  Ice_SLICE2PHP_EXECUTABLE - path to slice2php executable
	  Ice_SLICE2PY_EXECUTABLE - path to slice2py executable
	  Ice_SLICE2RB_EXECUTABLE - path to slice2rb executable

       New in version 3.14: Variables for slice2confluence and slice2matlab.

       Ice programs are	reported in:

	  Ice_GLACIER2ROUTER_EXECUTABLE	- path to glacier2router executable
	  Ice_ICEBOX_EXECUTABLE	- path to icebox executable
	  Ice_ICEBOXXX11_EXECUTABLE - path to icebox++11 executable
	  Ice_ICEBOXADMIN_EXECUTABLE - path to iceboxadmin executable
	  Ice_ICEBOXD_EXECUTABLE - path	to iceboxd executable
	  Ice_ICEBOXNET_EXECUTABLE - path to iceboxnet executable
	  Ice_ICEBRIDGE_EXECUTABLE - path to icebridge executable
	  Ice_ICEGRIDADMIN_EXECUTABLE -	path to	icegridadmin executable
	  Ice_ICEGRIDDB_EXECUTABLE - path to icegriddb executable
	  Ice_ICEGRIDNODE_EXECUTABLE - path to icegridnode executable
	  Ice_ICEGRIDNODED_EXECUTABLE -	path to	icegridnoded executable
	  Ice_ICEGRIDREGISTRY_EXECUTABLE - path	to icegridregistry executable
	  Ice_ICEGRIDREGISTRYD_EXECUTABLE - path to icegridregistryd executable
	  Ice_ICEPATCH2CALC_EXECUTABLE - path to icepatch2calc executable
	  Ice_ICEPATCH2CLIENT_EXECUTABLE - path	to icepatch2client executable
	  Ice_ICEPATCH2SERVER_EXECUTABLE - path	to icepatch2server executable
	  Ice_ICESERVICEINSTALL_EXECUTABLE - path to iceserviceinstall executable
	  Ice_ICESTORMADMIN_EXECUTABLE - path to icestormadmin executable
	  Ice_ICESTORMDB_EXECUTABLE - path to icestormdb executable
	  Ice_ICESTORMMIGRATE_EXECUTABLE - path	to icestormmigrate executable

       Ice  db	programs  (Windows only; standard system versions on all other
       platforms) are reported in:

	  Ice_DB_ARCHIVE_EXECUTABLE - path to db_archive executable
	  Ice_DB_CHECKPOINT_EXECUTABLE - path to db_checkpoint executable
	  Ice_DB_DEADLOCK_EXECUTABLE - path to db_deadlock executable
	  Ice_DB_DUMP_EXECUTABLE - path	to db_dump executable
	  Ice_DB_HOTBACKUP_EXECUTABLE -	path to	db_hotbackup executable
	  Ice_DB_LOAD_EXECUTABLE - path	to db_load executable
	  Ice_DB_LOG_VERIFY_EXECUTABLE - path to db_log_verify executable
	  Ice_DB_PRINTLOG_EXECUTABLE - path to db_printlog executable
	  Ice_DB_RECOVER_EXECUTABLE - path to db_recover executable
	  Ice_DB_STAT_EXECUTABLE - path	to db_stat executable
	  Ice_DB_TUNER_EXECUTABLE - path to db_tuner executable
	  Ice_DB_UPGRADE_EXECUTABLE - path to db_upgrade executable
	  Ice_DB_VERIFY_EXECUTABLE - path to db_verify executable
	  Ice_DUMPDB_EXECUTABLE	- path to dumpdb executable
	  Ice_TRANSFORMDB_EXECUTABLE - path to transformdb executable

       Ice component libraries are reported in:

	  Ice_<C>_FOUND	- ON if	component was found
	  Ice_<C>_LIBRARIES - libraries	for component

       Note that <C> is	the uppercased name of the component.

       This module reads hints about search results from:

	  Ice_HOME - the root of the Ice installation

       The environment variable	ICE_HOME may also be used; the Ice_HOME	 vari-
       able takes precedence.

       NOTE:
	  On  Windows,	Ice  3.7.0  and	 later provide libraries via the NuGet
	  package manager.  Appropriate	NuGet packages will  be	 searched  for
	  using	CMAKE_PREFIX_PATH, or alternatively Ice_HOME may be set	to the
	  location of a	specific NuGet package to restrict the search.

       The following cache variables may also be set:

	  Ice_<P>_EXECUTABLE - the path	to executable <P>
	  Ice_INCLUDE_DIR - the	directory containing the Ice headers
	  Ice_SLICE_DIR	- the directory	containing the Ice slice interface
			  definitions
	  Ice_<C>_LIBRARY - the	library	for component <C>

       NOTE:
	  In most cases	none of	the above variables will require setting,  un-
	  less	multiple  Ice versions are available and a specific version is
	  required.  On	Windows, the most recent version of Ice	will be	 found
	  through  the registry.  On Unix, the programs, headers and libraries
	  will usually be in standard locations, but Ice_SLICE_DIRS might  not
	  be  automatically  detected (commonly	known locations	are searched).
	  All the other	variables are defaulted	using Ice_HOME,	if set.	  It's
	  possible  to	set Ice_HOME and selectively specify alternative loca-
	  tions	for the	other components; this	might  be  required  for  e.g.
	  newer	versions of Visual Studio if the heuristics are	not sufficient
	  to identify the correct programs and libraries for the specific Vis-
	  ual Studio version.

       Other variables one may set to control this module are:

	  Ice_DEBUG - Set to ON	to enable debug	output from FindIce.

   FindIconv
       New in version 3.11.

       This  module  finds the iconv() POSIX.1 functions on the	system.	 These
       functions might be provided in the regular C library or	externally  in
       the form	of an additional library.

       The following variables are provided to indicate	iconv support:

       Iconv_FOUND
	      Variable indicating if the iconv support was found.

       Iconv_INCLUDE_DIRS
	      The directories containing the iconv headers.

       Iconv_LIBRARIES
	      The iconv	libraries to be	linked.

       Iconv_IS_BUILT_IN
	      A	variable indicating whether iconv support is stemming from the
	      C	library	or not.	Even if	the C library  provides	 iconv(),  the
	      presence	of  an	external libiconv implementation might lead to
	      this being false.

       Additionally, the following IMPORTED target is being provided:

       Iconv::Iconv
	      Imported target for using	iconv.

       The following cache variables may also be set:

       Iconv_INCLUDE_DIR
	      The directory containing the iconv headers.

       Iconv_LIBRARY
	      The iconv	library	(if not	implicitly given in the	C library).

       NOTE:
	  On POSIX platforms, iconv might be part of the  C  library  and  the
	  cache	variables Iconv_INCLUDE_DIR and	Iconv_LIBRARY might be empty.

   FindIcotool
       Find icotool

       This module looks for icotool. Convert and create Win32 icon and	cursor
       files.  This module defines the following values:

	  ICOTOOL_EXECUTABLE: the full path to the icotool tool.
	  ICOTOOL_FOUND: True if icotool has been found.
	  ICOTOOL_VERSION_STRING: the version of icotool found.

   FindICU
       New in version 3.7.

       Find the	International Components for Unicode (ICU) libraries and  pro-
       grams.

       This  module  supports multiple components.  Components can include any
       of: data, i18n, io, le, lx, test, tu and	uc.

       Note that on Windows data is named dt and i18n is named in; any of  the
       names  may  be used, and	the appropriate	platform-specific library name
       will be automatically selected.

       New in version 3.11: Added support for static libraries on Windows.

       This module reports information about the ICU installation  in  several
       variables.  General variables:

	  ICU_VERSION -	ICU release version
	  ICU_FOUND - true if the main programs	and libraries were found
	  ICU_LIBRARIES	- component libraries to be linked
	  ICU_INCLUDE_DIRS - the directories containing	the ICU	headers

       Imported	targets:

	  ICU::<C>

       Where  <C>  is the name of an ICU component, for	example	ICU::i18n; <C>
       is lower-case.

       ICU programs are	reported in:

	  ICU_GENCNVAL_EXECUTABLE - path to gencnval executable
	  ICU_ICUINFO_EXECUTABLE - path	to icuinfo executable
	  ICU_GENBRK_EXECUTABLE	- path to genbrk executable
	  ICU_ICU-CONFIG_EXECUTABLE - path to icu-config executable
	  ICU_GENRB_EXECUTABLE - path to genrb executable
	  ICU_GENDICT_EXECUTABLE - path	to gendict executable
	  ICU_DERB_EXECUTABLE -	path to	derb executable
	  ICU_PKGDATA_EXECUTABLE - path	to pkgdata executable
	  ICU_UCONV_EXECUTABLE - path to uconv executable
	  ICU_GENCFU_EXECUTABLE	- path to gencfu executable
	  ICU_MAKECONV_EXECUTABLE - path to makeconv executable
	  ICU_GENNORM2_EXECUTABLE - path to gennorm2 executable
	  ICU_GENCCODE_EXECUTABLE - path to genccode executable
	  ICU_GENSPREP_EXECUTABLE - path to gensprep executable
	  ICU_ICUPKG_EXECUTABLE	- path to icupkg executable
	  ICU_GENCMN_EXECUTABLE	- path to gencmn executable

       ICU component libraries are reported in:

	  ICU_<C>_FOUND	- ON if	component was found; ``<C>`` is	upper-case.
	  ICU_<C>_LIBRARIES - libraries	for component; ``<C>`` is upper-case.

       ICU datafiles are reported in:

	  ICU_MAKEFILE_INC - Makefile.inc
	  ICU_PKGDATA_INC - pkgdata.inc

       This module reads hints about search results from:

	  ICU_ROOT - the root of the ICU installation

       The environment variable	ICU_ROOT may also be used; the ICU_ROOT	 vari-
       able takes precedence.

       The following cache variables may also be set:

	  ICU_<P>_EXECUTABLE - the path	to executable <P>; ``<P>`` is upper-case.
	  ICU_INCLUDE_DIR - the	directory containing the ICU headers
	  ICU_<C>_LIBRARY - the	library	for component <C>; ``<C>`` is upper-case.

       NOTE:
	  In  most cases none of the above variables will require setting, un-
	  less multiple	ICU versions are available and a specific  version  is
	  required.

       Other variables one may set to control this module are:

	  ICU_DEBUG - Set to ON	to enable debug	output from FindICU.

   FindImageMagick
       Find ImageMagick	binary suite.

       New in version 3.9: Added support for ImageMagick 7.

       This  module  will  search  for a set of	ImageMagick tools specified as
       components in the find_package()	call.  Typical components include, but
       are  not	 limited  to  (future versions of ImageMagick might have addi-
       tional components not listed here):

	  animate
	  compare
	  composite
	  conjure
	  convert
	  display
	  identify
	  import
	  mogrify
	  montage
	  stream

       If no component is specified in the find_package() call,	then  it  only
       searches	 for  the ImageMagick executable directory.  This code defines
       the following variables:

	  ImageMagick_FOUND		     - TRUE if all components are found.
	  ImageMagick_EXECUTABLE_DIR	     - Full path to executables	directory.
	  ImageMagick_<component>_FOUND	     - TRUE if <component> is found.
	  ImageMagick_<component>_EXECUTABLE - Full path to <component>	executable.
	  ImageMagick_VERSION_STRING	     - the version of ImageMagick found
					       (since CMake 2.8.8)

       ImageMagick_VERSION_STRING will not work	for old	versions like 5.2.3.

       There are also components for the following ImageMagick APIs:

	  Magick++
	  MagickWand
	  MagickCore

       For these components the	following variables are	set:

	  ImageMagick_FOUND		       - TRUE if all components	are found.
	  ImageMagick_INCLUDE_DIRS	       - Full paths to all include dirs.
	  ImageMagick_LIBRARIES		       - Full paths to all libraries.
	  ImageMagick_<component>_FOUND	       - TRUE if <component> is	found.
	  ImageMagick_<component>_INCLUDE_DIRS - Full path to <component> include dirs.
	  ImageMagick_<component>_LIBRARIES    - Full path to <component> libraries.

       Example Usages:

	  find_package(ImageMagick)
	  find_package(ImageMagick COMPONENTS convert)
	  find_package(ImageMagick COMPONENTS convert mogrify display)
	  find_package(ImageMagick COMPONENTS Magick++)
	  find_package(ImageMagick COMPONENTS Magick++ convert)

       Note that the standard find_package()  features	are  supported	(i.e.,
       QUIET, REQUIRED,	etc.).

   FindIntl
       New in version 3.2.

       Find the	Gettext	libintl	headers	and libraries.

       This  module reports information	about the Gettext libintl installation
       in several variables.

       Intl_FOUND
	      True if libintl is found.

       Intl_INCLUDE_DIRS
	      The directory containing the libintl headers.

       Intl_LIBRARIES
	      The intl libraries to be linked.

       New in version 3.20: This module	defines	IMPORTED target	Intl::Intl.

       The following cache variables may also be set:

       Intl_INCLUDE_DIR
	      The directory containing the libintl headers

       Intl_LIBRARY
	      The libintl library (if any)

       Intl_IS_BUILT_IN
	      New in version 3.20.

	      whether intl is a	part of	the C library.

       NOTE:
	  On some platforms, such as Linux with	GNU libc,  the	gettext	 func-
	  tions	 are  present in the C standard	library	and libintl is not re-
	  quired.  Intl_LIBRARIES will be empty	in this	case.

       NOTE:
	  If you wish to use the Gettext tools (msgmerge, msgfmt,  etc.),  use
	  FindGettext.

   FindITK
       This module no longer exists.

       This  module existed in versions	of CMake prior to 3.1, but became only
       a thin wrapper around find_package(ITK NO_MODULE) to  provide  compati-
       bility  for  projects  using long-outdated conventions.	Now find_pack-
       age(ITK)	will search for	ITKConfig.cmake	directly.

   FindJasper
       Try to find the Jasper JPEG2000 library

       Once done this will define

	  JASPER_FOUND - system	has Jasper
	  JASPER_INCLUDE_DIR - the Jasper include directory
	  JASPER_LIBRARIES - the libraries needed to use Jasper
	  JASPER_VERSION_STRING	- the version of Jasper	found (since CMake 2.8.8)

   FindJava
       Find Java

       This module finds if Java is installed and determines where the include
       files  and  libraries  are.   The  caller may set variable JAVA_HOME to
       specify a Java installation prefix explicitly.

       See also	the FindJNI module to find Java	Native Interface (JNI).

       New in version 3.10: Added support for Java 9+ version parsing.

       Specify one or more of the following components as you call  this  find
       module. See example below.

	  Runtime     =	Java Runtime Environment used to execute Java byte-compiled applications
	  Development =	Development tools (java, javac,	javah, jar and javadoc), includes Runtime component
	  IdlJ	      =	Interface Description Language (IDL) to	Java compiler
	  JarSigner   =	Signer and verifier tool for Java Archive (JAR)	files

       This module sets	the following result variables:

	  Java_JAVA_EXECUTABLE	    = the full path to the Java	runtime
	  Java_JAVAC_EXECUTABLE	    = the full path to the Java	compiler
	  Java_JAVAH_EXECUTABLE	    = the full path to the Java	header generator
	  Java_JAVADOC_EXECUTABLE   = the full path to the Java	documentation generator
	  Java_IDLJ_EXECUTABLE	    = the full path to the Java	idl compiler
	  Java_JAR_EXECUTABLE	    = the full path to the Java	archiver
	  Java_JARSIGNER_EXECUTABLE = the full path to the Java	jar signer
	  Java_VERSION_STRING	    = Version of java found, eg. 1.6.0_12
	  Java_VERSION_MAJOR	    = The major	version	of the package found.
	  Java_VERSION_MINOR	    = The minor	version	of the package found.
	  Java_VERSION_PATCH	    = The patch	version	of the package found.
	  Java_VERSION_TWEAK	    = The tweak	version	of the package found (after '_')
	  Java_VERSION		    = This is set to: $major[.$minor[.$patch[.$tweak]]]

       New  in	version	 3.4:  Added  the  Java_IDLJ_EXECUTABLE	 and Java_JAR-
       SIGNER_EXECUTABLE variables.

       The minimum required  version  of  Java	can  be	 specified  using  the
       find_package() syntax, e.g.

	  find_package(Java 1.8)

       NOTE:  ${Java_VERSION} and ${Java_VERSION_STRING} are not guaranteed to
       be identical.  For example some	java  version  may  return:  Java_VER-
       SION_STRING = 1.8.0_17 and Java_VERSION = 1.8.0.17

       another	example	is the Java OEM, with: Java_VERSION_STRING = 1.8.0-oem
       and Java_VERSION	= 1.8.0

       For these components the	following variables are	set:

	  Java_FOUND			- TRUE if all components are found.
	  Java_<component>_FOUND	- TRUE if <component> is found.

       Example Usages:

	  find_package(Java)
	  find_package(Java 1.8	REQUIRED)
	  find_package(Java COMPONENTS Runtime)
	  find_package(Java COMPONENTS Development)

   FindJNI
       Find Java Native	Interface (JNI)	libraries.

       JNI enables Java	code running in	a Java Virtual Machine (JVM)  to  call
       and  be	called	by  native applications	and libraries written in other
       languages such as C, C++.

       This module finds if Java is installed and determines where the include
       files  and  libraries are.  It also determines what the name of the li-
       brary is.  The caller may set variable JAVA_HOME	to specify a Java  in-
       stallation prefix explicitly.

   Result Variables
       This module sets	the following result variables:

       JNI_INCLUDE_DIRS
	      the include dirs to use

       JNI_LIBRARIES
	      the libraries to use (JAWT and JVM)

       JNI_FOUND
	      TRUE if JNI headers and libraries	were found.

   Cache Variables
       The following cache variables are also available	to set or use:

       JAVA_AWT_LIBRARY
	      the path to the Java AWT Native Interface	(JAWT) library

       JAVA_JVM_LIBRARY
	      the path to the Java Virtual Machine (JVM) library

       JAVA_INCLUDE_PATH
	      the include path to jni.h

       JAVA_INCLUDE_PATH2
	      the include path to jni_md.h and jniport.h

       JAVA_AWT_INCLUDE_PATH
	      the include path to jawt.h

   FindJPEG
       Find the	Joint Photographic Experts Group (JPEG)	library	(libjpeg)

   Imported targets
       New in version 3.12.

       This module defines the following IMPORTED targets:

       JPEG::JPEG
	      The JPEG library,	if found.

   Result variables
       This module will	set the	following variables in your project:

       JPEG_FOUND
	      If false,	do not try to use JPEG.

       JPEG_INCLUDE_DIRS
	      where to find jpeglib.h, etc.

       JPEG_LIBRARIES
	      the libraries needed to use JPEG.

       JPEG_VERSION
	      New in version 3.12: the version of the JPEG library found

   Cache variables
       The following cache variables may also be set:

       JPEG_INCLUDE_DIRS
	      where to find jpeglib.h, etc.

       JPEG_LIBRARY_RELEASE
	      where to find the	JPEG library (optimized).

       JPEG_LIBRARY_DEBUG
	      where to find the	JPEG library (debug).

       New in version 3.12: Debug and Release variand are found	separately.

   Obsolete variables
       JPEG_INCLUDE_DIR
	      where to find jpeglib.h, etc. (same as JPEG_INCLUDE_DIRS)

       JPEG_LIBRARY
	      where to find the	JPEG library.

   FindKDE3
       Find  the KDE3 include and library dirs,	KDE preprocessors and define a
       some macros

       This module defines the following variables:

       KDE3_DEFINITIONS
	      compiler definitions required for	compiling KDE software

       KDE3_INCLUDE_DIR
	      the KDE include directory

       KDE3_INCLUDE_DIRS
	      the KDE and the Qt include directory, for	use  with  include_di-
	      rectories()

       KDE3_LIB_DIR
	      the  directory  where  the  KDE libraries	are installed, for use
	      with link_directories()

       QT_AND_KDECORE_LIBS
	      this contains both the Qt	and the	kdecore	library

       KDE3_DCOPIDL_EXECUTABLE
	      the dcopidl executable

       KDE3_DCOPIDL2CPP_EXECUTABLE
	      the dcopidl2cpp executable

       KDE3_KCFGC_EXECUTABLE
	      the kconfig_compiler executable

       KDE3_FOUND
	      set to TRUE if all of the	above has been found

       The following user adjustable options are provided:

       KDE3_BUILD_TESTS
	      enable this to build KDE testcases

       It also adds the	following macros (from KDE3Macros.cmake)  SRCS_VAR  is
       always  the  variable  which contains the list of source	files for your
       application or library.

       KDE3_AUTOMOC(file1 ...  fileN)

	  Call this if you want	to have	automatic moc file handling.
	  This means if	you include "foo.moc" in the source file foo.cpp
	  a moc	file for the header foo.h will be created automatically.
	  You can set the property SKIP_AUTOMAKE using set_source_files_properties()
	  to exclude some files	in the list from being processed.

       KDE3_ADD_MOC_FILES(SRCS_VAR file1 ...  fileN )

	  If you don't use the KDE3_AUTOMOC() macro, for the files
	  listed here moc files	will be	created	(named "foo.moc.cpp")

       KDE3_ADD_DCOP_SKELS(SRCS_VAR header1.h ...  headerN.h )

	  Use this to generate DCOP skeletions from the	listed headers.

       KDE3_ADD_DCOP_STUBS(SRCS_VAR header1.h ...  headerN.h )

	  Use this to generate DCOP stubs from the listed headers.

       KDE3_ADD_UI_FILES(SRCS_VAR file1.ui ...	fileN.ui )

	  Use this to add the Qt designer ui files to your application/library.

       KDE3_ADD_KCFG_FILES(SRCS_VAR file1.kcfgc	...  fileN.kcfgc )

	  Use this to add KDE kconfig compiler files to	your application/library.

       KDE3_INSTALL_LIBTOOL_FILE(target)

	  This will create and install a simple	libtool	file for the given target.

       KDE3_ADD_EXECUTABLE(name	file1 ...  fileN )

	  Currently identical to add_executable(), may provide some advanced
	  features in the future.

       KDE3_ADD_KPART(name [WITH_PREFIX] file1 ...  fileN )

	  Create a KDE plugin (KPart, kioslave,	etc.) from the given source files.
	  If WITH_PREFIX is given, the resulting plugin	will have the prefix "lib",
	  otherwise it won't.
	  It creates and installs an appropriate libtool la-file.

       KDE3_ADD_KDEINIT_EXECUTABLE(name	file1 ...  fileN )

	  Create a KDE application in the form of a module loadable via	kdeinit.
	  A library named kdeinit_<name> will be created and a small executable
	  which	links to it.

       The option KDE3_ENABLE_FINAL to enable  all-in-one  compilation	is  no
       longer supported.

       Author: Alexander Neundorf <neundorf@kde.org>

   FindKDE4
       Find  KDE4  and	provide	 all necessary variables and macros to compile
       software	for it.	 It looks for KDE 4 in the  following  directories  in
       the given order:

	  CMAKE_INSTALL_PREFIX
	  KDEDIRS
	  /usr/local

       Please look in FindKDE4Internal.cmake and KDE4Macros.cmake for more in-
       formation.   They  are  installed  with	the   KDE   4	libraries   in
       $KDEDIRS/share/apps/cmake/modules/.

       Author: Alexander Neundorf <neundorf@kde.org>

   FindLAPACK
       Find Linear Algebra PACKage (LAPACK) library

       This  module finds an installed Fortran library that implements the LA-
       PACK linear-algebra interface (see http://www.netlib.org/lapack/).

       The approach follows that taken for the autoconf	 macro	file,  acx_la-
       pack.m4			       (distributed			    at
       http://ac-archive.sourceforge.net/ac-archive/acx_lapack.html).

   Input Variables
       The following variables may be set to influence this module's behavior:

       BLA_STATIC
	      if ON use	static linkage

       BLA_VENDOR
	      If set, checks only the specified	vendor,	if not set checks  all
	      the possibilities.  List of vendors valid	in this	module:

	      o	FlexiBLAS

	      o	OpenBLAS

	      o	FLAME

	      o	Intel10_32 (intel mkl v10 32 bit, threaded code)

	      o	Intel10_64lp  (intel  mkl  v10+	 64  bit,  threaded code, lp64
		model)

	      o	Intel10_64lp_seq (intel	mkl v10+ 64 bit, sequential code, lp64
		model)

	      o	Intel10_64ilp  (intel  mkl  v10+  64 bit, threaded code, ilp64
		model)

	      o	Intel10_64ilp_seq (intel mkl v10+  64  bit,  sequential	 code,
		ilp64 model)

	      o	Intel10_64_dyn (intel mkl v10+ 64 bit, single dynamic library)

	      o	Intel (obsolete	versions of mkl	32 and 64 bit)

	      o	ACML

	      o	Apple

	      o	NAS

	      o	Arm

	      o	Arm_mp

	      o	Arm_ilp64

	      o	Arm_ilp64_mp

	      o	EML

	      o	EML_mt

	      o	Generic

	      New in version 3.6: OpenBLAS support.

	      New in version 3.11: FLAME support.

	      New  in  version	3.13: Added ILP64 MKL variants (Intel10_64ilp,
	      Intel10_64ilp_seq).

	      New in version 3.17: Added single	dynamic	 library  MKL  variant
	      (Intel10_64_dyn).

	      New  in  version	3.18:  Arm Performance Libraries support (Arm,
	      Arm_mp, Arm_ilp64, Arm_ilp64_mp).

	      New in version 3.19: FlexiBLAS support.

	      New in version 3.20: Elbrus Math Library support (EML, EML_mt).

       BLA_F95
	      if ON tries to find the BLAS95/LAPACK95 interfaces

       BLA_PREFER_PKGCONFIG
	      New in version 3.20.

	      if set pkg-config	will be	used to	search for  a  LAPACK  library
	      first and	if one is found	that is	preferred

   Imported targets
       New in version 3.18.

       This module defines the following IMPORTED target:

       LAPACK::LAPACK
	      The libraries to use for LAPACK, if found.

   Result Variables
       This module defines the following variables:

       LAPACK_FOUND
	      library implementing the LAPACK interface	is found

       LAPACK_LINKER_FLAGS
	      uncached list of required	linker flags (excluding	-l and -L).

       LAPACK_LIBRARIES
	      uncached	list  of  libraries  (using  full  path	 name) to link
	      against to use LAPACK

       LAPACK95_LIBRARIES
	      uncached list of	libraries  (using  full	 path  name)  to  link
	      against to use LAPACK95

       LAPACK95_FOUND
	      library implementing the LAPACK95	interface is found

       NOTE:
	  C,  CXX  or Fortran must be enabled to detect	a BLAS/LAPACK library.
	  C or CXX must	be enabled to use Intel	Math Kernel Library (MKL).

	  For example, to use Intel MKL	libraries and/or Intel compiler:

	      set(BLA_VENDOR Intel10_64lp)
	      find_package(LAPACK)

   FindLATEX
       Find LaTeX

       This module finds an installed LaTeX and	determines the location	of the
       compiler.   Additionally	 the  module  looks for	Latex-related software
       like BibTeX.

       New in version 3.2: Component processing; support for htlatex, pdftops,
       Biber, xindy, XeLaTeX, LuaLaTeX.

       This module sets	the following result variables:

	  LATEX_FOUND:		whether	found Latex and	requested components
	  LATEX_<component>_FOUND:  whether found <component>
	  LATEX_COMPILER:	path to	the LaTeX compiler
	  PDFLATEX_COMPILER:	path to	the PdfLaTeX compiler
	  XELATEX_COMPILER:	path to	the XeLaTeX compiler
	  LUALATEX_COMPILER:	path to	the LuaLaTeX compiler
	  BIBTEX_COMPILER:	path to	the BibTeX compiler
	  BIBER_COMPILER:	path to	the Biber compiler
	  MAKEINDEX_COMPILER:	path to	the MakeIndex compiler
	  XINDY_COMPILER:	path to	the xindy compiler
	  DVIPS_CONVERTER:	path to	the DVIPS converter
	  DVIPDF_CONVERTER:	path to	the DVIPDF converter
	  PS2PDF_CONVERTER:	path to	the PS2PDF converter
	  PDFTOPS_CONVERTER:	path to	the pdftops converter
	  LATEX2HTML_CONVERTER:	path to	the LaTeX2Html converter
	  HTLATEX_COMPILER:	path to	the htlatex compiler

       Possible	components are:

	  PDFLATEX
	  XELATEX
	  LUALATEX
	  BIBTEX
	  BIBER
	  MAKEINDEX
	  XINDY
	  DVIPS
	  DVIPDF
	  PS2PDF
	  PDFTOPS
	  LATEX2HTML
	  HTLATEX

       Example Usages:

	  find_package(LATEX)
	  find_package(LATEX COMPONENTS	PDFLATEX)
	  find_package(LATEX COMPONENTS	BIBTEX PS2PDF)

   FindLibArchive
       Find  libarchive	 library  and headers.	Libarchive is multi-format ar-
       chive and compression library.

       The module defines the following	variables:

	  LibArchive_FOUND	  - true if libarchive was found
	  LibArchive_INCLUDE_DIRS - include search path
	  LibArchive_LIBRARIES	  - libraries to link
	  LibArchive_VERSION	  - libarchive 3-component version number

       The module defines the following	IMPORTED targets:

	  LibArchive::LibArchive  - target for linking against libarchive

       New in version 3.6: Support for new libarchive 3.2 version string  for-
       mat.

   FindLibinput
       New in version 3.14.

       Find libinput headers and library.

   Imported Targets
       Libinput::Libinput
	      The libinput library, if found.

   Result Variables
       This will define	the following variables	in your	project:

       Libinput_FOUND
	      true if (the requested version of) libinput is available.

       Libinput_VERSION
	      the version of libinput.

       Libinput_LIBRARIES
	      the libraries to link against to use libinput.

       Libinput_INCLUDE_DIRS
	      where to find the	libinput headers.

       Libinput_COMPILE_OPTIONS
	      this should be passed to target_compile_options(), if the	target
	      is not used for linking

   FindLibLZMA
       Find LZMA compression algorithm headers and library.

   Imported Targets
       New in version 3.14.

       This module defines IMPORTED target LibLZMA::LibLZMA,  if  liblzma  has
       been found.

   Result variables
       This module will	set the	following variables in your project:

       LIBLZMA_FOUND
	      True if liblzma headers and library were found.

       LIBLZMA_INCLUDE_DIRS
	      Directory	where liblzma headers are located.

       LIBLZMA_LIBRARIES
	      Lzma libraries to	link against.

       LIBLZMA_HAS_AUTO_DECODER
	      True if lzma_auto_decoder() is found (required).

       LIBLZMA_HAS_EASY_ENCODER
	      True if lzma_easy_encoder() is found (required).

       LIBLZMA_HAS_LZMA_PRESET
	      True if lzma_lzma_preset() is found (required).

       LIBLZMA_VERSION_MAJOR
	      The major	version	of lzma

       LIBLZMA_VERSION_MINOR
	      The minor	version	of lzma

       LIBLZMA_VERSION_PATCH
	      The patch	version	of lzma

       LIBLZMA_VERSION_STRING
	      version number as	a string (ex: "5.0.3")

   FindLibXml2
       Find the	XML processing library (libxml2).

   IMPORTED Targets
       New in version 3.12.

       The following IMPORTED targets may be defined:

       LibXml2::LibXml2
	      libxml2 library.

       LibXml2::xmllint
	      New in version 3.17.

	      xmllint command-line executable.

   Result variables
       This module will	set the	following variables in your project:

       LibXml2_FOUND
	      true if libxml2 headers and libraries were found

       LIBXML2_INCLUDE_DIR
	      the directory containing LibXml2 headers

       LIBXML2_INCLUDE_DIRS
	      list of the include directories needed to	use LibXml2

       LIBXML2_LIBRARIES
	      LibXml2 libraries	to be linked

       LIBXML2_DEFINITIONS
	      the compiler switches required for using LibXml2

       LIBXML2_XMLLINT_EXECUTABLE
	      path to the XML checking tool xmllint coming with	LibXml2

       LIBXML2_VERSION_STRING
	      the version of LibXml2 found (since CMake	2.8.8)

   Cache variables
       The following cache variables may also be set:

       LIBXML2_INCLUDE_DIR
	      the directory containing LibXml2 headers

       LIBXML2_LIBRARY
	      path to the LibXml2 library

   FindLibXslt
       Find  the XSL Transformations, Extensible Stylesheet Language Transfor-
       mations (XSLT) library (LibXslt)

   IMPORTED Targets
       New in version 3.18.

       The following IMPORTED targets may be defined:

       LibXslt::LibXslt
	      If the libxslt library has been found

       LibXslt::LibExslt
	      If the libexslt library has been found

       LibXslt::xsltproc
	      If the xsltproc command-line executable has been found

   Result variables
       This module will	set the	following variables in your project:
	  LIBXSLT_FOUND	- system has LibXslt LIBXSLT_INCLUDE_DIR - the LibXslt
	  include   directory	LIBXSLT_LIBRARIES  -  Link  these  to  LibXslt
	  LIBXSLT_DEFINITIONS -	Compiler switches required for	using  LibXslt
	  LIBXSLT_VERSION_STRING  -  version  of  LibXslt  found  (since CMake
	  2.8.8)

       Additionally, the following two variables are set (but not required for
       using xslt):

       LIBXSLT_EXSLT_INCLUDE_DIR
	      New in version 3.18: The include directory for exslt.

       LIBXSLT_EXSLT_LIBRARIES
	      Link to these if you need	to link	against	the exslt library.

       LIBXSLT_XSLTPROC_EXECUTABLE
	      Contains the full	path to	the xsltproc executable	if found.

   FindLTTngUST
       New in version 3.6.

       Find Linux Trace	Toolkit	Next Generation	(LTTng-UST) library.

   Imported target
       This module defines the following IMPORTED target:

       LTTng::UST
	      The LTTng-UST library, if	found

   Result variables
       This module sets	the following

       LTTNGUST_FOUND
	      TRUE if system has LTTng-UST

       LTTNGUST_INCLUDE_DIRS
	      The LTTng-UST include directories

       LTTNGUST_LIBRARIES
	      The libraries needed to use LTTng-UST

       LTTNGUST_VERSION_STRING
	      The LTTng-UST version

       LTTNGUST_HAS_TRACEF
	      TRUE if the tracef() API is available in the system's LTTng-UST

       LTTNGUST_HAS_TRACELOG
	      TRUE  if	the  tracelog()	 API  is available in the system's LT-
	      Tng-UST

   FindLua
       Locate Lua library.

       New in version 3.18: Support for	Lua 5.4.

       This module defines:

	  ::
	  LUA_FOUND	     - if false, do not	try to	link  to  Lua  LUA_LI-
	  BRARIES	-  both	 lua  and lualib LUA_INCLUDE_DIR    - where to
	  find lua.h LUA_VERSION_STRING	- the version of  Lua  found  LUA_VER-
	  SION_MAJOR   - the major version of Lua LUA_VERSION_MINOR  - the mi-
	  nor version of Lua LUA_VERSION_PATCH	- the patch version of Lua

       Note that the expected include convention is

	  #include "lua.h"

       and not

	  #include <lua/lua.h>

       This is because,	the lua	location is not	standardized and may exist  in
       locations other than lua/

   FindLua50
       Locate Lua library.  This module	defines:

	  ::
	  LUA50_FOUND, if false, do not	try to link to Lua LUA_LIBRARIES, both
	  lua and lualib LUA_INCLUDE_DIR, where	to  find  lua.h	 and  lualib.h
	  (and probably	lauxlib.h)

       Note that the expected include convention is

	  #include "lua.h"

       and not

	  #include <lua/lua.h>

       This  is	because, the lua location is not standardized and may exist in
       locations other than lua/

   FindLua51
       Locate Lua library.  This module	defines:

	  ::
	  LUA51_FOUND, if false, do not	 try  to  link	to  Lua	 LUA_LIBRARIES
	  LUA_INCLUDE_DIR, where to find lua.h LUA_VERSION_STRING, the version
	  of Lua found (since CMake 2.8.8)

       Note that the expected include convention is

	  #include "lua.h"

       and not

	  #include <lua/lua.h>

       This is because,	the lua	location is not	standardized and may exist  in
       locations other than lua/

   FindMatlab
       Finds  Matlab  or  Matlab  Compiler  Runtime  (MCR) and provides	Matlab
       tools, libraries	and compilers to CMake.

       This package primary purpose is to find the libraries  associated  with
       Matlab  or  the MCR in order to be able to build	Matlab extensions (mex
       files). It can also be used:

       o to run	specific commands in Matlab in case Matlab is available

       o for declaring Matlab unit test

       o to retrieve various information from Matlab (mex extensions, versions
	 and release queries, ...)

       New in version 3.12: Added Matlab Compiler Runtime (MCR)	support.

       The module supports the following components:

       o ENG_LIBRARY  and  MAT_LIBRARY:	respectively the ENG and MAT libraries
	 of Matlab

       o MAIN_PROGRAM the Matlab binary	program. Note that this	 component  is
	 not  available	on the MCR version, and	will yield an error if the MCR
	 is found instead of the regular Matlab	installation.

       o MEX_COMPILER the MEX compiler.

       o MCC_COMPILER the MCC compiler,	 included  with	 the  Matlab  Compiler
	 add-on.

       o SIMULINK the Simulink environment.

       New in version 3.7: Added the MAT_LIBRARY component.

       New  in	version	 3.13: Added the ENGINE_LIBRARY, DATAARRAY_LIBRARY and
       MCC_COMPILER components.

       Changed in version 3.14:	Removed	 the  MX_LIBRARY,  ENGINE_LIBRARY  and
       DATAARRAY_LIBRARY  components.	These libraries	are found uncondition-
       ally.

       NOTE:
	  The version given to the find_package() directive is the Matlab ver-
	  sion,	which should not be confused with the Matlab release name (eg.
	  R2014).      The     matlab_get_version_from_release_name()	   and
	  matlab_get_release_name_from_version() provide a mapping between the
	  release name and the version.

       The variable Matlab_ROOT_DIR may	be specified in	order to give the path
       of  the	desired	 Matlab	 version. Otherwise, the behaviour is platform
       specific:

       o Windows: The installed	versions of Matlab/MCR are retrieved from  the
	 Windows registry

       o OS  X:	 The  installed	versions of Matlab/MCR are given by the	MATLAB
	 default installation paths in /Application. If	no such	application is
	 found,	 it  falls  back  to the one that might	be accessible from the
	 PATH.

       o Unix: The desired Matlab should be accessible	from  the  PATH.  This
	 does  not  work  for  MCR  installation and Matlab_ROOT_DIR should be
	 specified on this platform.

       Additional information is provided when MATLAB_FIND_DEBUG is set.  When
       a Matlab/MCR installation is found automatically	and the	MATLAB_VERSION
       is not given, the version is queried from Matlab	directly  (on  Windows
       this may	pop up a Matlab	window)	or from	the MCR	installation.

       The mapping of the release names	and the	version	of Matlab is performed
       by    defining	  pairs	    (name,     version).      The     variable
       MATLAB_ADDITIONAL_VERSIONS  may	be  provided  before  the  call	to the
       find_package() in order to handle additional versions.

       A  Matlab  scripts  can	be  added  to  the  set	 of  tests  using  the
       matlab_add_unit_test(). By default, the Matlab unit test	framework will
       be used (>= 2013a) to run this script, but regular .m  files  returning
       an exit code can	be used	as well	(0 indicating a	success).

   Module Input	Variables
       Users or	projects may set the following variables to configure the mod-
       ule behaviour:

       Matlab_ROOT_DIR
	      the root of the Matlab installation.

       MATLAB_FIND_DEBUG
	      outputs debug information

       MATLAB_ADDITIONAL_VERSIONS
	      additional versions of Matlab for	the automatic retrieval	of the
	      installed	versions.

   Variables defined by	the module
   Result variables
       Matlab_FOUND
	      TRUE  if	the Matlab installation	is found, FALSE	otherwise. All
	      variable below are defined if Matlab is found.

       Matlab_ROOT_DIR
	      the final	root of	the  Matlab  installation  determined  by  the
	      FindMatlab module.

       Matlab_MAIN_PROGRAM
	      the  Matlab  binary  program.  Available	only  if the component
	      MAIN_PROGRAM is given in the find_package() directive.

       Matlab_INCLUDE_DIRS
	      the path of the Matlab libraries headers

       Matlab_MEX_LIBRARY
	      library for mex, always available.

       Matlab_MX_LIBRARY
	      mx library of Matlab (arrays), always available.

       Matlab_ENG_LIBRARY
	      Matlab engine library. Available only if the  component  ENG_LI-
	      BRARY is requested.

       Matlab_MAT_LIBRARY
	      Matlab  matrix  library. Available only if the component MAT_LI-
	      BRARY is requested.

       Matlab_ENGINE_LIBRARY
	      New in version 3.13.

	      Matlab C++ engine	 library,  always  available  for  R2018a  and
	      newer.

       Matlab_DATAARRAY_LIBRARY
	      New in version 3.13.

	      Matlab  C++  data	array library, always available	for R2018a and
	      newer.

       Matlab_LIBRARIES
	      the whole	set of libraries of Matlab

       Matlab_MEX_COMPILER
	      the mex compiler of Matlab. Currently not	used.  Available  only
	      if the component MEX_COMPILER is requested.

       Matlab_MCC_COMPILER
	      New in version 3.13.

	      the  mcc	compiler  of Matlab. Included with the Matlab Compiler
	      add-on.  Available only if the  component	 MCC_COMPILER  is  re-
	      quested.

   Cached variables
       Matlab_MEX_EXTENSION
	      the  extension  of the mex files for the current platform	(given
	      by Matlab).

       Matlab_ROOT_DIR
	      the location of the root of the Matlab  installation  found.  If
	      this  value is changed by	the user, the result variables are re-
	      computed.

   Provided macros
       matlab_get_version_from_release_name()
	      returns the version from the release name

       matlab_get_release_name_from_version()
	      returns the release name from the	Matlab version

   Provided functions
       matlab_add_mex()
	      adds a target compiling a	MEX file.

       matlab_add_unit_test()
	      adds a Matlab unit test file as a	test to	the project.

       matlab_extract_all_installed_versions_from_registry()
	      parses the registry for all Matlab versions. Available  on  Win-
	      dows  only.  The part of the registry parsed is dependent	on the
	      host processor

       matlab_get_all_valid_matlab_roots_from_registry()
	      returns all the possible Matlab or MCR  paths,  according	 to  a
	      previously  given	 list.	Only the existing/accessible paths are
	      kept. This is mainly useful for the searching all	possible  Mat-
	      lab installation.

       matlab_get_mex_suffix()
	      returns the suffix to be used for	the mex	files (platform/archi-
	      tecture dependent)

       matlab_get_version_from_matlab_run()
	      returns the version of Matlab/MCR, given the full	 directory  of
	      the Matlab/MCR installation path.

   Known issues
       Symbol clash in a MEX target
	      By  default,  every  symbols  inside a MEX file defined with the
	      command matlab_add_mex() have hidden visibility, except for  the
	      entry  point. This is the	default	behaviour of the MEX compiler,
	      which lowers the risk of symbol collision	between	the  libraries
	      shipped  with Matlab, and	the libraries to which the MEX file is
	      linking to. This is also the default on Windows platforms.

	      However, this is not sufficient in certain case, where  for  in-
	      stance  your  MEX	file is	linking	against	libraries that are al-
	      ready loaded by Matlab, even if those libraries  have  different
	      SONAMES.	 A possible solution is	to hide	the symbols of the li-
	      braries to which the MEX target  is  linking  to.	 This  can  be
	      achieved	in  GNU	GCC compilers with the linker option -Wl,--ex-
	      clude-libs,ALL.

       Tests using GPU resources
	      in case your MEX file is using the GPU and in order to  be  able
	      to  run unit tests on this MEX file, the GPU resources should be
	      properly released	by Matlab. A possible solution is to make Mat-
	      lab  aware of the	use of the GPU resources in the	session, which
	      can be performed by a command such as D =	gpuDevice() at the be-
	      ginning of the test script (or via a fixture).

   Reference
       Matlab_ROOT_DIR
	      The  root	 folder	 of the	Matlab installation. If	set before the
	      call to find_package(), the module will look for the  components
	      in  that	path.  If  not set, then an automatic search of	Matlab
	      will be performed. If set, it should point to a valid version of
	      Matlab.

       MATLAB_FIND_DEBUG
	      If  set, the lookup of Matlab and	the intermediate configuration
	      steps are	outputted to the console.

       MATLAB_ADDITIONAL_VERSIONS
	      If set, specifies	additional versions  of	 Matlab	 that  may  be
	      looked for.  The variable	should be a list of strings, organised
	      by pairs of release name and versions, such as follows:

		 set(MATLAB_ADDITIONAL_VERSIONS
		     "release_name1=corresponding_version1"
		     "release_name2=corresponding_version2"
		     ...
		     )

	      Example:

		 set(MATLAB_ADDITIONAL_VERSIONS
		     "R2013b=8.2"
		     "R2013a=8.1"
		     "R2012b=8.0")

	      The order	of entries in this list	matters	when several  versions
	      of  Matlab  are  installed. The priority is set according	to the
	      ordering in this list.

       matlab_get_version_from_release_name
	      Returns the version  of  Matlab  (17.58)	from  a	 release  name
	      (R2017k)

       matlab_get_release_name_from_version
	      Returns  the  release  name  (R2017k) from the version of	Matlab
	      (17.58)

       matlab_extract_all_installed_versions_from_registry
	      This function parses the registry	and founds the Matlab versions
	      that  are	 installed.  The  found	 versions are returned in mat-
	      lab_versions.  Set win64 to TRUE if the 64 bit version of	Matlab
	      should be	looked for The returned	list contains all versions un-
	      der HKLM\\SOFTWARE\\Mathworks\\MATLAB and	 HKLM\\SOFTWARE\\Math-
	      works\\MATLAB Runtime or an empty	list in	case an	error occurred
	      (or nothing found).

	      NOTE:
		 Only the versions are provided. No check is made over the ex-
		 istence of the	installation referenced	in the registry,

       matlab_get_all_valid_matlab_roots_from_registry
	      Populates	 the Matlab root with valid versions of	Matlab or Mat-
	      lab Runtime (MCR).  The returned matlab_roots  is	 organized  in
	      triplets	(type,version_number,matlab_root_path),	where type in-
	      dicates either MATLAB or MCR.

		 matlab_get_all_valid_matlab_roots_from_registry(
		     matlab_versions
		     matlab_roots)

	      matlab_versions
		     the versions of each of the Matlab	or MCR installations

	      matlab_roots
		     the location of each of the Matlab	or MCR installations

       matlab_get_mex_suffix
	      Returns the extension of the mex	files  (the  suffixes).	  This
	      function should not be called before the appropriate Matlab root
	      has been found.

		 matlab_get_mex_suffix(
		     matlab_root
		     mex_suffix)

	      matlab_root
		     the root of the Matlab/MCR	installation

	      mex_suffix
		     the variable name in which	the suffix will	be returned.

       matlab_get_version_from_matlab_run
	      This function runs Matlab	program	specified on arguments and ex-
	      tracts  its version. If the path provided	for the	Matlab instal-
	      lation points to an MCR installation, the	version	 is  extracted
	      from the installed files.

		 matlab_get_version_from_matlab_run(
		     matlab_binary_path
		     matlab_list_versions)

	      matlab_binary_path
		     the location of the matlab	binary executable

	      matlab_list_versions
		     the version extracted from	Matlab

       matlab_add_unit_test
	      Adds  a  Matlab  unit test to the	test set of cmake/ctest.  This
	      command requires the component MAIN_PROGRAM  and	hence  is  not
	      available	for an MCR installation.

	      The  unit	 test  uses  the  Matlab  unittest framework (default,
	      available	 starting  Matlab  2013b+)  except   if	  the	option
	      NO_UNITTEST_FRAMEWORK is given.

	      The  function  expects  one Matlab test script file to be	given.
	      In the case NO_UNITTEST_FRAMEWORK	is given, the unittest	script
	      file  should  contain the	script to be run, plus an exit command
	      with the exit value. This	exit value will	be passed to the ctest
	      framework	 (0  success, non 0 failure). Additional arguments ac-
	      cepted by	add_test() can be passed through TEST_ARGS  (eg.  CON-
	      FIGURATION <config> ...).

		 matlab_add_unit_test(
		     NAME <name>
		     UNITTEST_FILE matlab_file_containing_unittest.m
		     [CUSTOM_TEST_COMMAND matlab_command_to_run_as_test]
		     [UNITTEST_PRECOMMAND matlab_command_to_run]
		     [TIMEOUT timeout]
		     [ADDITIONAL_PATH path1 [path2 ...]]
		     [MATLAB_ADDITIONAL_STARTUP_OPTIONS	option1	[option2 ...]]
		     [TEST_ARGS	arg1 [arg2 ...]]
		     [NO_UNITTEST_FRAMEWORK]
		     )

	      The function arguments are:

	      NAME   name of the unittest in ctest.

	      UNITTEST_FILE
		     the  matlab unittest file.	Its path will be automatically
		     added to the Matlab path.

	      CUSTOM_TEST_COMMAND
		     Matlab script command to run as the test.	If this	is not
		     set,   then   the	 following   is	  run:	runtests('mat-
		     lab_file_name'), exit(max([ans(1,:).Failed])) where  mat-
		     lab_file_name is the UNITTEST_FILE	without	the extension.

	      UNITTEST_PRECOMMAND
		     Matlab  script command to be ran before the file contain-
		     ing the test (eg.	GPU  device  initialisation  based  on
		     CMake variables).

	      TIMEOUT
		     the  test	timeout	in seconds. Defaults to	180 seconds as
		     the Matlab	unit test may hang.

	      ADDITIONAL_PATH
		     a list of paths to	add to the Matlab path prior  to  run-
		     ning the unit test.

	      MATLAB_ADDITIONAL_STARTUP_OPTIONS
		     a	list  of additional option in order to run Matlab from
		     the command line.	-nosplash  -nodesktop  -nodisplay  are
		     always added.

	      TEST_ARGS
		     Additional	 options  provided  to	the  add_test command.
		     These options are added to	the default options (eg. "CON-
		     FIGURATIONS Release")

	      NO_UNITTEST_FRAMEWORK
		     when  set,	 indicates  that  the  test should not use the
		     unittest framework	of Matlab (available for  versions  >=
		     R2013a).

	      WORKING_DIRECTORY
		     This will be the working directory	for the	test. If spec-
		     ified it will also	be the output directory	used  for  the
		     log file of the test run.	If not specified the temporary
		     directory ${CMAKE_BINARY_DIR}/Matlab will be used as  the
		     working directory and the log location.

       matlab_add_mex
	      Adds  a  Matlab  MEX  target.   This commands compiles the given
	      sources with the current tool-chain in order to  produce	a  MEX
	      file. The	final name of the produced output may be specified, as
	      well as additional link libraries, and a documentation entry for
	      the  MEX file. Remaining arguments of the	call are passed	to the
	      add_library() or add_executable()	command.

		 matlab_add_mex(
		     NAME <name>
		     [EXECUTABLE | MODULE | SHARED]
		     SRC src1 [src2 ...]
		     [OUTPUT_NAME output_name]
		     [DOCUMENTATION file.txt]
		     [LINK_TO target1 target2 ...]
		     [R2017b | R2018a]
		     [EXCLUDE_FROM_ALL]
		     [...]
		 )

	      NAME   name of the target.

	      SRC    list of source files.

	      LINK_TO
		     a list of additional link dependencies.  The target links
		     to	libmex and libmx by default.

	      OUTPUT_NAME
		     if	given, overrides the default name. The default name is
		     the name of the target without any	prefix and  with  Mat-
		     lab_MEX_EXTENSION suffix.

	      DOCUMENTATION
		     if	 given,	 the file file.txt will	be considered as being
		     the documentation file for	the MEX	 file.	This  file  is
		     copied  into the same folder without any processing, with
		     the same name as the final	mex file, and  with  extension
		     .m. In that case, typing help <name> in Matlab prints the
		     documentation contained in	this file.

	      R2017b or	R2018a
		     New in version 3.14.

		     May be given to specify the version of the	C API to  use:
		     R2017b  specifies	the  traditional  (separate complex) C
		     API, and corresponds to the -R2017b flag for the mex com-
		     mand. R2018a specifies the	new interleaved	complex	C API,
		     and corresponds to	the -R2018a flag for the mex  command.
		     Ignored  if  MATLAB  version prior	to R2018a. Defaults to
		     R2017b.

	      MODULE or	SHARED
		     New in version 3.7.

		     May be given to specify the type of library  to  be  cre-
		     ated.

	      EXECUTABLE
		     New in version 3.7.

		     May  be  given  to	 create	an executable instead of a li-
		     brary. If no  type	 is  given  explicitly,	 the  type  is
		     SHARED.

	      EXCLUDE_FROM_ALL
		     This  option has the same meaning as for EXCLUDE_FROM_ALL
		     and is forwarded  to  add_library()  or  add_executable()
		     commands.

	      The  documentation  file	is  not	processed and should be	in the
	      following	format:

		 % This	is the documentation
		 function ret =	mex_target_output_name(input1)

   FindMFC
       Find Microsoft Foundation Class Library (MFC) on	Windows

       Find the	native MFC - i.e.  decide if an	application can	 link  to  the
       MFC libraries.

	  MFC_FOUND - Was MFC support found

       You don't need to include anything or link anything to use it.

   FindMotif
       Try to find Motif (or lesstif)

       Once done this will define:

	  MOTIF_FOUND	     - system has MOTIF
	  MOTIF_INCLUDE_DIR  - include paths to	use Motif
	  MOTIF_LIBRARIES    - Link these to use Motif

   FindMPEG
       Find the	native MPEG includes and library

       This module defines

	  MPEG_INCLUDE_DIR, where to find MPEG.h, etc.
	  MPEG_LIBRARIES, the libraries	required to use	MPEG.
	  MPEG_FOUND, If false,	do not try to use MPEG.

       also defined, but not for general use are

	  MPEG_mpeg2_LIBRARY, where to find the	MPEG library.
	  MPEG_vo_LIBRARY, where to find the vo	library.

   FindMPEG2
       Find the	native MPEG2 includes and library

       This module defines

	  MPEG2_INCLUDE_DIR, path to mpeg2dec/mpeg2.h, etc.
	  MPEG2_LIBRARIES, the libraries required to use MPEG2.
	  MPEG2_FOUND, If false, do not	try to use MPEG2.

       also defined, but not for general use are

	  MPEG2_mpeg2_LIBRARY, where to	find the MPEG2 library.
	  MPEG2_vo_LIBRARY, where to find the vo library.

   FindMPI
       Find a Message Passing Interface	(MPI) implementation.

       The  Message  Passing  Interface	 (MPI)	is  a  library	used  to write
       high-performance	distributed-memory parallel applications, and is typi-
       cally  deployed	on a cluster.  MPI is a	standard interface (defined by
       the MPI forum) for which	many implementations are available.

       New in version 3.10: Major overhaul of the module: many new  variables,
       per-language components,	support	for a wider variety of runtimes.

   Variables for using MPI
       The  module exposes the components C, CXX, MPICXX and Fortran.  Each of
       these controls the various MPI languages	to search for.	The difference
       between CXX and MPICXX is that CXX refers to the	MPI C API being	usable
       from C++, whereas MPICXX	refers to the MPI-2 C++	API that  was  removed
       again in	MPI-3.

       Depending  on  the  enabled  components the following variables will be
       set:

       MPI_FOUND
	      Variable indicating that MPI settings  for  all  requested  lan-
	      guages have been found.  If no components	are specified, this is
	      true if MPI settings for all enabled  languages  were  detected.
	      Note that	the MPICXX component does not affect this variable.

       MPI_VERSION
	      Minimal  version	of MPI detected	among the requested languages,
	      or all enabled languages if no components	were specified.

       This module will	set the	 following  variables  per  language  in  your
       project,	where <lang> is	one of C, CXX, or Fortran:

       MPI_<lang>_FOUND
	      Variable	indicating  the	MPI settings for <lang>	were found and
	      that simple MPI test programs compile  with  the	provided  set-
	      tings.

       MPI_<lang>_COMPILER
	      MPI compiler for <lang> if such a	program	exists.

       MPI_<lang>_COMPILE_OPTIONS
	      Compilation  options  for	 MPI  programs	in  <lang>, given as a
	      ;-list.

       MPI_<lang>_COMPILE_DEFINITIONS
	      Compilation definitions for MPI programs in <lang>, given	 as  a
	      ;-list.

       MPI_<lang>_INCLUDE_DIRS
	      Include path(s) for MPI header.

       MPI_<lang>_LINK_FLAGS
	      Linker flags for MPI programs.

       MPI_<lang>_LIBRARIES
	      All libraries to link MPI	programs against.

       New  in	version	 3.9: Additionally, the	following IMPORTED targets are
       defined:

       MPI::MPI_<lang>
	      Target for using MPI from	<lang>.

       The following variables indicating which	bindings are present  will  be
       defined:

       MPI_MPICXX_FOUND
	      Variable	indicating  whether the	MPI-2 C++ bindings are present
	      (introduced in MPI-2, removed with MPI-3).

       MPI_Fortran_HAVE_F77_HEADER
	      True if the Fortran 77 header mpif.h is available.

       MPI_Fortran_HAVE_F90_MODULE
	      True if the Fortran 90 module mpi	can be used for	accessing  MPI
	      (MPI-2 and higher	only).

       MPI_Fortran_HAVE_F08_MODULE
	      True  if	the  Fortran 2008 mpi_f08 is available to MPI programs
	      (MPI-3 and higher	only).

       If possible, the	MPI version will be determined by this module. The fa-
       cilities	 to  detect  the MPI version were introduced with MPI-1.2, and
       therefore cannot	be found for older MPI versions.

       MPI_<lang>_VERSION_MAJOR
	      Major version of MPI implemented for <lang> by the MPI distribu-
	      tion.

       MPI_<lang>_VERSION_MINOR
	      Minor version of MPI implemented for <lang> by the MPI distribu-
	      tion.

       MPI_<lang>_VERSION
	      MPI version implemented for <lang> by the	MPI distribution.

       Note that there's no variable  for  the	C  bindings  being  accessible
       through	mpi.h, since the MPI standards always have required this bind-
       ing to work in both C and C++ code.

       For running MPI programs, the module sets the following variables

       MPIEXEC_EXECUTABLE
	      Executable for running MPI programs, if such exists.

       MPIEXEC_NUMPROC_FLAG
	      Flag to pass to mpiexec before giving it the number  of  proces-
	      sors to run on.

       MPIEXEC_MAX_NUMPROCS
	      Number  of  MPI processors to utilize. Defaults to the number of
	      processors detected on the host system.

       MPIEXEC_PREFLAGS
	      Flags to pass to mpiexec directly	before the executable to run.

       MPIEXEC_POSTFLAGS
	      Flags to pass to mpiexec after other flags.

   Variables for locating MPI
       This module performs a four step	search for an MPI implementation:

       1. Search for MPIEXEC_EXECUTABLE	and, if	found, use its base directory.

       2. Check	if the compiler	has MPI	support	built-in. This is the case  if
	  the  user  passed  a compiler	wrapper	as CMAKE_<LANG>_COMPILER or if
	  they're on a Cray system.

       3. Attempt to find an MPI compiler wrapper and determine	 the  compiler
	  information from it.

       4. Try  to find an MPI implementation that does not ship	such a wrapper
	  by guessing settings.	 Currently, only Microsoft MPI and  MPICH2  on
	  Windows are supported.

       For  controlling	 the  MPIEXEC_EXECUTABLE step, the following variables
       may be set:

       MPIEXEC_EXECUTABLE
	      Manually specify the location of mpiexec.

       MPI_HOME
	      Specify the base directory of the	MPI installation.

       ENV{MPI_HOME}
	      Environment variable to specify the base directory  of  the  MPI
	      installation.

       ENV{I_MPI_ROOT}
	      Environment  variable  to	 specify the base directory of the MPI
	      installation.

       For controlling the compiler wrapper step, the following	variables  may
       be set:

       MPI_<lang>_COMPILER
	      Search for the specified compiler	wrapper	and use	it.

       MPI_<lang>_COMPILER_FLAGS
	      Flags  to	pass to	the MPI	compiler wrapper during	interrogation.
	      Some compiler wrappers support  linking  debug  or  tracing  li-
	      braries  if  a  specific flag is passed and this variable	may be
	      used to obtain them.

       MPI_COMPILER_FLAGS
	      Used to initialize MPI_<lang>_COMPILER_FLAGS if no language spe-
	      cific flag has been given.  Empty	by default.

       MPI_EXECUTABLE_SUFFIX
	      A	 suffix	 which	is appended to all names that are being	looked
	      for. For instance	you may	set this to .mpich or .openmpi to pre-
	      fer the one or the other on Debian and its derivatives.

       In  order  to  control the guessing step, the following variable	may be
       set:

       MPI_GUESS_LIBRARY_NAME
	      Valid values are MSMPI and MPICH2. If set, only  the  given  li-
	      brary will be searched for.  By default, MSMPI will be preferred
	      over MPICH2 if both are available.  This also sets MPI_SKIP_COM-
	      PILER_WRAPPER to true, which may be overridden.

       Each  of	 the  search  steps  may be skipped with the following control
       variables:

       MPI_ASSUME_NO_BUILTIN_MPI
	      If true, the module assumes that the compiler  itself  does  not
	      provide an MPI implementation and	skips to step 2.

       MPI_SKIP_COMPILER_WRAPPER
	      If true, no compiler wrapper will	be searched for.

       MPI_SKIP_GUESSING
	      If true, the guessing step will be skipped.

       Additionally,  the  following  control  variable	is available to	change
       search behavior:

       MPI_CXX_SKIP_MPICXX
	      Add some definitions that	will disable the MPI-2	C++  bindings.
	      Currently	supported are MPICH, Open MPI, Platform	MPI and	deriv-
	      atives thereof, for example MVAPICH or Intel MPI.

       If the find procedure fails for a variable MPI_<lang>_WORKS,  then  the
       settings	 detected  by  or passed to the	module did not work and	even a
       simple MPI test program failed to compile.

       If all of these parameters were not sufficient to find  the  right  MPI
       implementation,	a user may disable the entire autodetection process by
       specifying both a list of libraries in MPI_<lang>_LIBRARIES and a  list
       of  include  directories	 in  MPI_<lang>_ADDITIONAL_INCLUDE_DIRS.   Any
       other variable may be set in addition to	these  two.  The  module  will
       then validate the MPI settings and store	the settings in	the cache.

   Cache variables for MPI
       The variable MPI_<lang>_INCLUDE_DIRS will be assembled from the follow-
       ing variables.  For C and CXX:

       MPI_<lang>_HEADER_DIR
	      Location of the mpi.h header on disk.

       For Fortran:

       MPI_Fortran_F77_HEADER_DIR
	      Location of the Fortran 77 header	mpif.h,	if it exists.

       MPI_Fortran_MODULE_DIR
	      Location of the mpi or mpi_f08 modules, if available.

       For all languages the following variables are additionally considered:

       MPI_<lang>_ADDITIONAL_INCLUDE_DIRS
	      A	;-list of paths	needed in addition to the normal  include  di-
	      rectories.

       MPI_<include_name>_INCLUDE_DIR
	      Path   variables	 for  include  folders	referred  to  by  <in-
	      clude_name>.

       MPI_<lang>_ADDITIONAL_INCLUDE_VARS
	      A	;-list of <include_name> that will be added to the include lo-
	      cations of <lang>.

       The  variable MPI_<lang>_LIBRARIES will be assembled from the following
       variables:

       MPI_<lib_name>_LIBRARY
	      The location of a	library	called <lib_name> for use with MPI.

       MPI_<lang>_LIB_NAMES
	      A	;-list of <lib_name> that will be added	to the	include	 loca-
	      tions of <lang>.

   Usage of mpiexec
       When  using  MPIEXEC_EXECUTABLE to execute MPI applications, you	should
       typically use all of the	MPIEXEC_EXECUTABLE flags as follows:

	  ${MPIEXEC_EXECUTABLE}	${MPIEXEC_NUMPROC_FLAG}	${MPIEXEC_MAX_NUMPROCS}
	    ${MPIEXEC_PREFLAGS}	EXECUTABLE ${MPIEXEC_POSTFLAGS}	ARGS

       where EXECUTABLE	is the MPI program, and	ARGS are the arguments to pass
       to the MPI program.

   Advanced variables for using	MPI
       The  module  can	perform	some advanced feature detections upon explicit
       request.

       Important notice: The following checks cannot be	performed without exe-
       cuting  an  MPI	test program.  Consider	the special considerations for
       the behavior of try_run() during	cross compilation.  Moreover,  running
       an  MPI	program	can cause additional issues, like a firewall notifica-
       tion on some systems.  You should only enable these detections  if  you
       absolutely need the information.

       If  the following variables are set to true, the	respective search will
       be performed:

       MPI_DETERMINE_Fortran_CAPABILITIES
	      Determine	for all	available Fortran bindings what	the values  of
	      MPI_SUBARRAYS_SUPPORTED  and  MPI_ASYNC_PROTECTS_NONBLOCKING are
	      and make their values available as  MPI_Fortran_<binding>_SUBAR-
	      RAYS and MPI_Fortran_<binding>_ASYNCPROT,	where <binding>	is one
	      of F77_HEADER, F90_MODULE	and F08_MODULE.

       MPI_DETERMINE_LIBRARY_VERSION
	      For each language, find the  output  of  MPI_Get_library_version
	      and  make	 it  available	as  MPI_<lang>_LIBRARY_VERSION_STRING.
	      This information is usually tied to the runtime component	of  an
	      MPI  implementation  and might differ depending on <lang>.  Note
	      that the return value is entirely	implementation	defined.  This
	      information might	be used	to identify the	MPI vendor and for ex-
	      ample pick the correct one of multiple third party binaries that
	      matches the MPI vendor.

   Backward Compatibility
       Deprecated since	version	3.10.

       For  backward compatibility with	older versions of FindMPI, these vari-
       ables are set:

	  MPI_COMPILER	      MPI_LIBRARY	 MPI_EXTRA_LIBRARY
	  MPI_COMPILE_FLAGS   MPI_INCLUDE_PATH	 MPI_LINK_FLAGS
	  MPI_LIBRARIES

       In new projects,	please use the MPI_<lang>_XXX equivalents.   Addition-
       ally, the following variables are deprecated:

       MPI_<lang>_COMPILE_FLAGS
	      Use  MPI_<lang>_COMPILE_OPTIONS  and  MPI_<lang>_COMPILE_DEFINI-
	      TIONS instead.

       MPI_<lang>_INCLUDE_PATH
	      For consumption use MPI_<lang>_INCLUDE_DIRS and  for  specifying
	      folders use MPI_<lang>_ADDITIONAL_INCLUDE_DIRS instead.

       MPIEXEC
	      Use MPIEXEC_EXECUTABLE instead.

   FindODBC
       New in version 3.12.

       Find  an	 Open  Database	 Connectivity (ODBC) include directory and li-
       brary.

       On Windows, when	building with Visual Studio, this module  assumes  the
       ODBC library is provided	by the available Windows SDK.

       On  Unix,  this	module	allows	to search for ODBC library provided by
       unixODBC	or iODBC implementations of ODBC API.  This module reads  hint
       about location of the config program:

       ODBC_CONFIG
	      Location of odbc_config or iodbc-config program

       Otherwise,  this	 module	 tries	to find	the config program, first from
       unixODBC, then from iODBC.  If no config	 program  found,  this	module
       searches	for ODBC header	and library in list of known locations.

   Imported targets
       This module defines the following IMPORTED targets:

       ODBC::ODBC
	      Imported target for using	the ODBC library, if found.

   Result variables
       ODBC_FOUND
	      Set to true if ODBC library found, otherwise false or undefined.

       ODBC_INCLUDE_DIRS
	      Paths  to	 include directories listed in one variable for	use by
	      ODBC client.  May	be empty on Windows, where the include	direc-
	      tory corresponding to the	expected Windows SDK is	already	avail-
	      able in the compilation environment.

       ODBC_LIBRARIES
	      Paths to libraries to linked against to use ODBC.	  May  just  a
	      library name on Windows, where the library directory correspond-
	      ing to the expected Windows SDK is already available in the com-
	      pilation environment.

       ODBC_CONFIG
	      Path to unixODBC or iODBC	config program,	if found or specified.

   Cache variables
       For users who wish to edit and control the module behavior, this	module
       reads hints about search	locations from the following variables:

       ODBC_INCLUDE_DIR
	      Path to ODBC include directory with sql.h	header.

       ODBC_LIBRARY
	      Path to ODBC library to be linked.

       These variables should not be used directly by project code.

   Limitations
       On Windows, this	module does not	search for iODBC.  On Unix,  there  is
       no way to prefer	unixODBC over iODBC, or	vice versa, other than provid-
       ing the config program location using  the  ODBC_CONFIG.	  This	module
       does not	allow to search	for a specific ODBC driver.

   FindOpenACC
       New in version 3.10.

       Detect OpenACC support by the compiler.

       This  module  can  be used to detect OpenACC support in a compiler.  If
       the compiler supports OpenACC, the flags	required to compile with  Ope-
       nACC  support  are  returned  in	variables for the different languages.
       Currently, only NVHPC, PGI, GNU and Cray	compilers are supported.

   Imported Targets
       New in version 3.16.

       The module provides IMPORTED targets:

       OpenACC::OpenACC_<lang>
	      Target for using OpenACC from <lang>.

   Variables
       This module will	set the	 following  variables  per  language  in  your
       project,	where <lang> is	one of C, CXX, or Fortran:

       OpenACC_<lang>_FOUND
	      Variable indicating if OpenACC support for <lang>	was detected.

       OpenACC_<lang>_FLAGS
	      OpenACC compiler flags for <lang>, separated by spaces.

       OpenACC_<lang>_OPTIONS
	      New in version 3.16.

	      OpenACC compiler flags for <lang>, as a list. Suitable for usage
	      with target_compile_options or target_link_options.

       The module will also try	to provide the OpenACC version variables:

       OpenACC_<lang>_SPEC_DATE
	      Date of the OpenACC specification	implemented by the <lang> com-
	      piler.

       OpenACC_<lang>_VERSION_MAJOR
	      Major version of OpenACC implemented by the <lang> compiler.

       OpenACC_<lang>_VERSION_MINOR
	      Minor version of OpenACC implemented by the <lang> compiler.

       OpenACC_<lang>_VERSION
	      OpenACC version implemented by the <lang>	compiler.

       The  specification  date	is formatted as	given in the OpenACC standard:
       yyyymm where yyyy and mm	represents the year and	month of  the  OpenACC
       specification implemented by the	<lang> compiler.

   Input Variables
       OpenACC_ACCEL_TARGET=<target> If	set, will the correct target accelera-
       tor  flag  set  to  the	 <target>   will   be	returned   with	  Ope-
       nACC_<lang>_FLAGS.

   FindOpenAL
       Finds Open Audio	Library	(OpenAL).

       Projects	 using	this  module should use	#include "al.h"	to include the
       OpenAL header file, not #include	<AL/al.h>.  The	 reason	 for  this  is
       that  the  latter is not	entirely portable.  Windows/Creative Labs does
       not by default put their	headers	in AL/ and macOS uses  the  convention
       <OpenAL/al.h>.

   Hints
       Environment variable $OPENALDIR can be used to set the prefix of	OpenAL
       installation to be found.

       By default on macOS, system framework is	search first.  In other	words,
       OpenAL is searched in the following order:

       1. System  framework: /System/Library/Frameworks, whose priority	can be
	  changed via setting the CMAKE_FIND_FRAMEWORK variable.

       2. Environment variable $OPENALDIR.

       3. System paths.

       4. User-compiled	framework: ~/Library/Frameworks.

       5. Manually compiled framework: /Library/Frameworks.

       6. Add-on package: /opt.

   Result Variables
       This module defines the following variables:

       OPENAL_FOUND
	      If false,	do not try to link to OpenAL

       OPENAL_INCLUDE_DIR
	      OpenAL include directory

       OPENAL_LIBRARY
	      Path to the OpenAL library

       OPENAL_VERSION_STRING
	      Human-readable string containing the version of OpenAL

   FindOpenCL
       New in version 3.1.

       Finds Open Computing Language (OpenCL)

       New in version 3.10: Detection of OpenCL	2.1 and	2.2.

   IMPORTED Targets
       New in version 3.7.

       This module defines IMPORTED target OpenCL::OpenCL, if OpenCL has  been
       found.

   Result Variables
       This module defines the following variables:

	  OpenCL_FOUND		- True if OpenCL was found
	  OpenCL_INCLUDE_DIRS	- include directories for OpenCL
	  OpenCL_LIBRARIES	- link against this library to use OpenCL
	  OpenCL_VERSION_STRING	- Highest supported OpenCL version (eg.	1.2)
	  OpenCL_VERSION_MAJOR	- The major version of the OpenCL implementation
	  OpenCL_VERSION_MINOR	- The minor version of the OpenCL implementation

       The module will also define two cache variables:

	  OpenCL_INCLUDE_DIR	- the OpenCL include directory
	  OpenCL_LIBRARY	- the path to the OpenCL library

   FindOpenGL
       FindModule for OpenGL and OpenGL	Utility	Library	(GLU).

       Changed	in  version  3.2:  X11	is  no longer added as a dependency on
       Unix/Linux systems.

       New in version 3.10: GLVND support on Linux.   See  the	Linux-specific
       section below.

   Optional COMPONENTS
       New in version 3.10.

       This module respects several optional COMPONENTS: EGL, GLX, and OpenGL.
       There are corresponding import targets for each of these	flags.

   IMPORTED Targets
       New in version 3.8.

       This module defines the IMPORTED	targets:

       OpenGL::GL
	      Defined to the platform-specific OpenGL libraries	if the	system
	      has OpenGL.

       OpenGL::GLU
	      Defined if the system has	OpenGL Utility Library (GLU).

       New in version 3.10: Additionally, the following	GLVND-specific library
       targets are defined:

       OpenGL::OpenGL
	      Defined to libOpenGL if the system is GLVND-based.

       OpenGL::GLX
	      Defined if the system has	OpenGL Extension to the	X Window  Sys-
	      tem (GLX).

       OpenGL::EGL
	      Defined if the system has	EGL.

   Result Variables
       This module sets	the following variables:

       OPENGL_FOUND
	      True, if the system has OpenGL and all components	are found.

       OPENGL_XMESA_FOUND
	      True, if the system has XMESA.

       OPENGL_GLU_FOUND
	      True, if the system has GLU.

       OpenGL_OpenGL_FOUND
	      True, if the system has an OpenGL	library.

       OpenGL_GLX_FOUND
	      True, if the system has GLX.

       OpenGL_EGL_FOUND
	      True, if the system has EGL.

       OPENGL_INCLUDE_DIR
	      Path to the OpenGL include directory.

       OPENGL_EGL_INCLUDE_DIRS
	      Path to the EGL include directory.

       OPENGL_LIBRARIES
	      Paths to the OpenGL library, windowing system libraries, and GLU
	      libraries.  On Linux, this assumes GLX and is never correct  for
	      EGL-based	 targets.  Clients are encouraged to use the OpenGL::*
	      import targets instead.

       New in version 3.10: Variables for GLVND-specific libraries OpenGL, EGL
       and GLX.

   Cache variables
       The following cache variables may also be set:

       OPENGL_egl_LIBRARY
	      Path to the EGL library.

       OPENGL_glu_LIBRARY
	      Path to the GLU library.

       OPENGL_glx_LIBRARY
	      Path to the GLVND	'GLX' library.

       OPENGL_opengl_LIBRARY
	      Path to the GLVND	'OpenGL' library

       OPENGL_gl_LIBRARY
	      Path  to	the  OpenGL  library.	New  code  should  prefer  the
	      OpenGL::*	import targets.

       New in version 3.10: Variables for GLVND-specific libraries OpenGL, EGL
       and GLX.

   Linux-specific
       Some  Linux systems utilize GLVND as a new ABI for OpenGL.  GLVND sepa-
       rates context libraries	from  OpenGL  itself;  OpenGL  lives  in  "li-
       bOpenGL",  and  contexts	are defined in "libGLX"	or "libEGL".  GLVND is
       currently the only way to get OpenGL 3+ functionality via EGL in	a man-
       ner  portable  across  vendors.	Projects may use GLVND explicitly with
       target OpenGL::OpenGL and either	OpenGL::GLX or OpenGL::EGL.

       Projects	may use	the OpenGL::GL target (or  OPENGL_LIBRARIES  variable)
       to  use legacy GL interfaces.  These will use the legacy	GL library lo-
       cated by	OPENGL_gl_LIBRARY,  if	available.   If	 OPENGL_gl_LIBRARY  is
       empty  or  not found and	GLVND is available, the	OpenGL::GL target will
       use GLVND OpenGL::OpenGL	 and  OpenGL::GLX  (and	 the  OPENGL_LIBRARIES
       variable	  will	 use   the   corresponding   libraries).    Thus,  for
       non-EGL-based Linux targets, the	OpenGL::GL target is most portable.

       A OpenGL_GL_PREFERENCE variable may be set to specify the preferred way
       to provide legacy GL interfaces in case multiple	choices	are available.
       The value may be	one of:

       GLVND  If the GLVND OpenGL and  GLX  libraries  are  available,	prefer
	      them.  This forces OPENGL_gl_LIBRARY to be empty.

	      Changed  in  version  3.11:  This	 is the	default, unless	policy
	      CMP0072 is set to	OLD and	no components are requeted (since com-
	      ponents correspond to GLVND libraries).

       LEGACY Prefer to	use the	legacy libGL library, if available.

       For  EGL	 targets  the  client must rely	on GLVND support on the	user's
       system.	Linking	should use  the	 OpenGL::OpenGL	 OpenGL::EGL  targets.
       Using   GLES*   libraries   is	theoretically  possible	 in  place  of
       OpenGL::OpenGL, but this	module does not	currently support  that;  con-
       tributions welcome.

       OPENGL_egl_LIBRARY  and OPENGL_EGL_INCLUDE_DIRS are defined in the case
       of GLVND.  For non-GLVND	Linux and other	systems	these are  left	 unde-
       fined.

   macOS-Specific
       On  OSX	FindOpenGL  defaults to	using the framework version of OpenGL.
       People will have	to change the cache values of  OPENGL_glu_LIBRARY  and
       OPENGL_gl_LIBRARY to use	OpenGL with X11	on OSX.

   FindOpenMP
       Finds Open Multi-Processing (OpenMP) support.

       This module can be used to detect OpenMP	support	in a compiler.	If the
       compiler	supports OpenMP, the flags required  to	 compile  with	OpenMP
       support	are  returned  in  variables for the different languages.  The
       variables may be	empty if the compiler does not need a special flag  to
       support OpenMP.

       New in version 3.5: Clang support.

   Variables
       New in version 3.10: The	module exposes the components C, CXX, and For-
       tran.  Each of these controls the various languages  to	search	OpenMP
       support for.

       Depending  on  the  enabled  components the following variables will be
       set:

       OpenMP_FOUND
	      Variable indicating that OpenMP flags  for  all  requested  lan-
	      guages have been found.  If no components	are specified, this is
	      true if OpenMP settings for all enabled languages	were detected.

       OpenMP_VERSION
	      Minimal version of the OpenMP standard detected  among  the  re-
	      quested  languages,  or  all  enabled languages if no components
	      were specified.

       This module will	set the	 following  variables  per  language  in  your
       project,	where <lang> is	one of C, CXX, or Fortran:

       OpenMP_<lang>_FOUND
	      Variable indicating if OpenMP support for	<lang> was detected.

       OpenMP_<lang>_FLAGS
	      OpenMP compiler flags for	<lang>,	separated by spaces.

       OpenMP_<lang>_INCLUDE_DIRS
	      Directories  that	 must  be  added to the	header search path for
	      <lang> when using	OpenMP.

       For linking with	OpenMP code written in <lang>, the following variables
       are provided:

       OpenMP_<lang>_LIB_NAMES
	      ;-list of	libraries for OpenMP programs for <lang>.

       OpenMP_<libname>_LIBRARY
	      Location	of  the	individual libraries needed for	OpenMP support
	      in <lang>.

       OpenMP_<lang>_LIBRARIES
	      A	list of	libraries needed to link with OpenMP code  written  in
	      <lang>.

       Additionally, the module	provides IMPORTED targets:

       OpenMP::OpenMP_<lang>
	      Target for using OpenMP from <lang>.

       Specifically for	Fortran, the module sets the following variables:

       OpenMP_Fortran_HAVE_OMPLIB_HEADER
	      Boolean indicating if OpenMP is accessible through omp_lib.h.

       OpenMP_Fortran_HAVE_OMPLIB_MODULE
	      Boolean  indicating  if OpenMP is	accessible through the omp_lib
	      Fortran module.

       The module will also try	to provide the OpenMP version variables:

       OpenMP_<lang>_SPEC_DATE
	      New in version 3.7.

	      Date of the OpenMP specification implemented by the <lang>  com-
	      piler.

       OpenMP_<lang>_VERSION_MAJOR
	      Major version of OpenMP implemented by the <lang>	compiler.

       OpenMP_<lang>_VERSION_MINOR
	      Minor version of OpenMP implemented by the <lang>	compiler.

       OpenMP_<lang>_VERSION
	      OpenMP version implemented by the	<lang> compiler.

       The  specification  date	 is formatted as given in the OpenMP standard:
       yyyymm where yyyy and mm	represents the year and	month  of  the	OpenMP
       specification implemented by the	<lang> compiler.

       For  some compilers, it may be necessary	to add a header	search path to
       find the	relevant OpenMP	headers.  This location	may  be	 language-spe-
       cific.	Where this is needed, the module may attempt to	find the loca-
       tion, but it can	be provided directly by	setting	the  OpenMP_<lang>_IN-
       CLUDE_DIR  cache	 variable.  Note that this variable is an _input_ con-
       trol to the module.  Project  code  should  use	the  OpenMP_<lang>_IN-
       CLUDE_DIRS  _output_ variable if	it needs to know what include directo-
       ries are	needed.

   FindOpenSceneGraph
       Find OpenSceneGraph (3D graphics	application programming	interface)

       This module searches for	the OpenSceneGraph core	"osg" library as  well
       as  FindOpenThreads, and	whatever additional COMPONENTS (nodekits) that
       you specify.

	  See http://www.openscenegraph.org

       NOTE: To	use this module	effectively you	must either require  CMake  >=
       2.6.3 with  cmake_minimum_required(VERSION 2.6.3) or download and place
       FindOpenThreads,	Findosg	functions, Findosg and	Find<etc>.cmake	 files
       into your CMAKE_MODULE_PATH.

					----

       This module accepts the following variables (note mixed case)

	  OpenSceneGraph_DEBUG - Enable	debugging output

	  OpenSceneGraph_MARK_AS_ADVANCED - Mark cache variables as advanced
					    automatically

       The  following environment variables are	also respected for finding the
       OSG and it's various components.	 CMAKE_PREFIX_PATH can	also  be  used
       for this	(see find_library() CMake documentation).

       <MODULE>_DIR
	      (where  MODULE is	of the form "OSGVOLUME"	and there is a Findos-
	      gVolume.cmake` file)

       OSG_DIR

       OSGDIR

       OSG_ROOT

       [CMake 2.8.10]: The CMake variable OSG_DIR can now be used as  well  to
       influence detection, instead of needing to specify an environment vari-
       able.

       This module defines the following output	variables:

	  OPENSCENEGRAPH_FOUND - Was the OSG and all of	the specified components found?

	  OPENSCENEGRAPH_VERSION - The version of the OSG which	was found

	  OPENSCENEGRAPH_INCLUDE_DIRS -	Where to find the headers

	  OPENSCENEGRAPH_LIBRARIES - The OSG libraries

       ================================== Example Usage:

	  find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgUtil)
	      #	libOpenThreads & libosg	automatically searched
	  include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})

	  add_executable(foo foo.cc)
	  target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})

   FindOpenSSL
       Find the	OpenSSL	encryption library.

       This module finds an installed OpenSSL library and determines its  ver-
       sion.

       New  in	version	3.19: When a version is	requested, it can be specified
       as a simple value or as a range.	For a detailed description of  version
       range usage and capabilities, refer to the find_package() command.

       New in version 3.18: Support for	OpenSSL	3.0.

   Optional COMPONENTS
       New in version 3.12.

       This  module  supports  two  optional COMPONENTS: Crypto	and SSL.  Both
       components have associated imported targets, as described below.

   Imported Targets
       New in version 3.4.

       This module defines the following IMPORTED targets:

       OpenSSL::SSL
	      The OpenSSL ssl library, if found.

       OpenSSL::Crypto
	      The OpenSSL crypto library, if found.

       OpenSSL::applink
	      New in version 3.18.

	      The OpenSSL applink components that might	be need	to be compiled
	      into projects under MSVC.	This target is available only if found
	      OpenSSL version is not less than 0.9.8. By linking  this	target
	      the  above OpenSSL targets can be	linked even if the project has
	      different	MSVC runtime configurations  with  the	above  OpenSSL
	      targets. This target has no effect on platforms other than MSVC.

       NOTE:  Due  to how INTERFACE_SOURCES are	consumed by the	consuming tar-
       get, unless you certainly know what you are doing, it  is  always  pre-
       ferred to link OpenSSL::applink target as PRIVATE and to	make sure that
       this target is linked at	most once for the whole	 dependency  graph  of
       any library or executable:

	  target_link_libraries(myTarget PRIVATE OpenSSL::applink)

       Otherwise  you would probably encounter unexpected random problems when
       building	and linking, as	both the ISO C and the ISO C++ standard	claims
       almost nothing about what a link	process	should be.

   Result Variables
       This module will	set the	following variables in your project:

       OPENSSL_FOUND
	      System  has  the OpenSSL library.	If no components are requested
	      it only requires the crypto library.

       OPENSSL_INCLUDE_DIR
	      The OpenSSL include directory.

       OPENSSL_CRYPTO_LIBRARY
	      The OpenSSL crypto library.

       OPENSSL_CRYPTO_LIBRARIES
	      The OpenSSL crypto library and its dependencies.

       OPENSSL_SSL_LIBRARY
	      The OpenSSL SSL library.

       OPENSSL_SSL_LIBRARIES
	      The OpenSSL SSL library and its dependencies.

       OPENSSL_LIBRARIES
	      All OpenSSL libraries and	their dependencies.

       OPENSSL_VERSION
	      This is set to $major.$minor.$revision$patch (e.g. 0.9.8s).

       OPENSSL_APPLINK_SOURCE
	      The sources in the target	 OpenSSL::applink  that	 is  mentioned
	      above.  This variable shall always be undefined if found openssl
	      version is less than 0.9.8 or if platform	is not MSVC.

   Hints
       Set OPENSSL_ROOT_DIR to the root	directory of an	OpenSSL	installation.

       New in version 3.4: Set OPENSSL_USE_STATIC_LIBS to  TRUE	 to  look  for
       static libraries.

       New  in	version	3.5: Set OPENSSL_MSVC_STATIC_RT	set TRUE to choose the
       MT version of the lib.

   FindOpenThreads
       OpenThreads is a	C++ based threading  library.	Its  largest  userbase
       seems to	OpenSceneGraph so you might notice I accept OSGDIR as an envi-
       ronment path.  I	consider this part of the Findosg* suite used to  find
       OpenSceneGraph components.  Each	component is separate and you must opt
       in to each module.

       Locate	OpenThreads   This    module	defines	   OPENTHREADS_LIBRARY
       OPENTHREADS_FOUND,  if  false,  do  not	try  to	 link  to  OpenThreads
       OPENTHREADS_INCLUDE_DIR,	where to find the headers

       $OPENTHREADS_DIR	is an environment variable that	 would	correspond  to
       the ./configure --prefix=$OPENTHREADS_DIR used in building osg.

       [CMake  2.8.10]:	The CMake variables OPENTHREADS_DIR or OSG_DIR can now
       be used as well to influence detection, instead of needing  to  specify
       an environment variable.

       Created by Eric Wing.

   Findosg
       NOTE:  It  is  highly  recommended  that	you use	the new	FindOpenScene-
       Graph.cmake introduced in CMake 2.6.3 and not use this Find module  di-
       rectly.

       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osg This module defines

       OSG_FOUND - Was the Osg found? OSG_INCLUDE_DIR  -  Where	 to  find  the
       headers	OSG_LIBRARIES -	The libraries to link against for the OSG (use
       this)

       OSG_LIBRARY - The OSG library OSG_LIBRARY_DEBUG - The OSG debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   Findosg_functions
       This  CMake  file  contains two macros to assist	with searching for OSG
       libraries and nodekits.	Please see FindOpenSceneGraph.cmake  for  full
       documentation.

   FindosgAnimation
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgAnimation This	module defines

       OSGANIMATION_FOUND - Was	osgAnimation found? OSGANIMATION_INCLUDE_DIR -
       Where  to  find	the  headers OSGANIMATION_LIBRARIES - The libraries to
       link against for	the OSG	(use this)

       OSGANIMATION_LIBRARY - The OSG library OSGANIMATION_LIBRARY_DEBUG - The
       OSG debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgDB
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL module doesn't work  with  your
       system  as  an  example).   If you want to use a	more convenient	module
       that includes everything, use the  FindOpenSceneGraph  instead  of  the
       Findosg*.cmake modules.

       Locate osgDB This module	defines:

       OSGDB_FOUND
	      Was osgDB	found?

       OSGDB_INCLUDE_DIR
	      Where to find the	headers

       OSGDB_LIBRARIES
	      The libraries to link against for	the osgDB

       OSGDB_LIBRARY
	      The osgDB	library

       OSGDB_LIBRARY_DEBUG
	      The osgDB	debug library

       $OSGDIR is an environment variable that would correspond	to:

	  ./configure --prefix=$OSGDIR used in building	osg.

   FindosgFX
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgFX This module	defines

       OSGFX_FOUND - Was osgFX found? OSGFX_INCLUDE_DIR	- Where	 to  find  the
       headers	OSGFX_LIBRARIES	 - The libraries to link against for the osgFX
       (use this)

       OSGFX_LIBRARY - The osgFX library OSGFX_LIBRARY_DEBUG - The osgFX debug
       library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgGA
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgGA This module	defines

       OSGGA_FOUND  -  Was  osgGA found? OSGGA_INCLUDE_DIR - Where to find the
       headers OSGGA_LIBRARIES - The libraries to link against for  the	 osgGA
       (use this)

       OSGGA_LIBRARY - The osgGA library OSGGA_LIBRARY_DEBUG - The osgGA debug
       library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgIntrospection
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgINTROSPECTION This module defines

       OSGINTROSPECTION_FOUND -	 Was  osgIntrospection	found?	 OSGINTROSPEC-
       TION_INCLUDE_DIR	- Where	to find	the headers OSGINTROSPECTION_LIBRARIES
       - The libraries to link for osgIntrospection (use this)

       OSGINTROSPECTION_LIBRARY	- The osgIntrospection	library	 OSGINTROSPEC-
       TION_LIBRARY_DEBUG - The	osgIntrospection debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgManipulator
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgManipulator This module defines

       OSGMANIPULATOR_FOUND  -	Was  osgManipulator found?  OSGMANIPULATOR_IN-
       CLUDE_DIR - Where to find the headers  OSGMANIPULATOR_LIBRARIES	-  The
       libraries to link for osgManipulator (use this)

       OSGMANIPULATOR_LIBRARY  - The osgManipulator library OSGMANIPULATOR_LI-
       BRARY_DEBUG - The osgManipulator	debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgParticle
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgParticle This module defines

       OSGPARTICLE_FOUND - Was osgParticle  found?  OSGPARTICLE_INCLUDE_DIR  -
       Where to	find the headers OSGPARTICLE_LIBRARIES - The libraries to link
       for osgParticle (use this)

       OSGPARTICLE_LIBRARY - The osgParticle library OSGPARTICLE_LIBRARY_DEBUG
       - The osgParticle debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgPresentation
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgPresentation This module defines

       OSGPRESENTATION_FOUND - Was osgPresentation found?  OSGPRESENTATION_IN-
       CLUDE_DIR - Where to find the headers OSGPRESENTATION_LIBRARIES	-  The
       libraries to link for osgPresentation (use this)

       OSGPRESENTATION_LIBRARY	-  The	osgPresentation	 library  OSGPRESENTA-
       TION_LIBRARY_DEBUG - The	osgPresentation	debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created	by Eric	Wing.  Modified	to work	with osgPresentation by	Robert
       Osfield,	January	2012.

   FindosgProducer
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgProducer This module defines

       OSGPRODUCER_FOUND  -  Was  osgProducer found? OSGPRODUCER_INCLUDE_DIR -
       Where to	find the headers OSGPRODUCER_LIBRARIES - The libraries to link
       for osgProducer (use this)

       OSGPRODUCER_LIBRARY - The osgProducer library OSGPRODUCER_LIBRARY_DEBUG
       - The osgProducer debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgQt
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgQt This module	defines

       OSGQT_FOUND - Was osgQt found? OSGQT_INCLUDE_DIR	- Where	 to  find  the
       headers OSGQT_LIBRARIES - The libraries to link for osgQt (use this)

       OSGQT_LIBRARY - The osgQt library OSGQT_LIBRARY_DEBUG - The osgQt debug
       library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created	by  Eric Wing.	Modified to work with osgQt by Robert Osfield,
       January 2012.

   FindosgShadow
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgShadow	This module defines

       OSGSHADOW_FOUND - Was osgShadow found? OSGSHADOW_INCLUDE_DIR - Where to
       find the	headers	OSGSHADOW_LIBRARIES - The libraries to	link  for  os-
       gShadow (use this)

       OSGSHADOW_LIBRARY - The osgShadow library OSGSHADOW_LIBRARY_DEBUG - The
       osgShadow debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgSim
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgSim This module defines

       OSGSIM_FOUND - Was osgSim found?	OSGSIM_INCLUDE_DIR - Where to find the
       headers OSGSIM_LIBRARIES	- The libraries	to link	for osgSim (use	this)

       OSGSIM_LIBRARY  -  The osgSim library OSGSIM_LIBRARY_DEBUG - The	osgSim
       debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgTerrain
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgTerrain This module defines

       OSGTERRAIN_FOUND	- Was osgTerrain found?	OSGTERRAIN_INCLUDE_DIR - Where
       to  find	 the  headers OSGTERRAIN_LIBRARIES - The libraries to link for
       osgTerrain (use this)

       OSGTERRAIN_LIBRARY - The	osgTerrain library OSGTERRAIN_LIBRARY_DEBUG  -
       The osgTerrain debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgText
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgText This module defines

       OSGTEXT_FOUND  -	Was osgText found? OSGTEXT_INCLUDE_DIR - Where to find
       the headers OSGTEXT_LIBRARIES - The libraries to	link for osgText  (use
       this)

       OSGTEXT_LIBRARY	- The osgText library OSGTEXT_LIBRARY_DEBUG - The osg-
       Text debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgUtil
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgUtil This module defines

       OSGUTIL_FOUND - Was osgUtil found? OSGUTIL_INCLUDE_DIR -	Where to  find
       the  headers OSGUTIL_LIBRARIES -	The libraries to link for osgUtil (use
       this)

       OSGUTIL_LIBRARY -  The  osgUtil	library	 OSGUTIL_LIBRARY_DEBUG	-  The
       osgUtil debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgViewer
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgViewer	This module defines

       OSGVIEWER_FOUND - Was osgViewer found? OSGVIEWER_INCLUDE_DIR - Where to
       find the	headers	OSGVIEWER_LIBRARIES - The libraries to	link  for  os-
       gViewer (use this)

       OSGVIEWER_LIBRARY - The osgViewer library OSGVIEWER_LIBRARY_DEBUG - The
       osgViewer debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgVolume
       This  is	 part of the Findosg* suite used to find OpenSceneGraph	compo-
       nents.  Each component is separate and you must opt in to each  module.
       You  must also opt into OpenGL and OpenThreads (and Producer if needed)
       as these	modules	won't do it for	you.  This is  to  allow  you  control
       over your own system piece by piece in case you need to opt out of cer-
       tain components or change the Find behavior  for	 a  particular	module
       (perhaps	 because the default FindOpenGL.cmake module doesn't work with
       your system as an example).  If you want	to use a more convenient  mod-
       ule  that includes everything, use the FindOpenSceneGraph.cmake instead
       of the Findosg*.cmake modules.

       Locate osgVolume	This module defines

       OSGVOLUME_FOUND - Was osgVolume found? OSGVOLUME_INCLUDE_DIR - Where to
       find  the  headers  OSGVOLUME_LIBRARIES - The libraries to link for os-
       gVolume (use this)

       OSGVOLUME_LIBRARY - The osgVolume library OSGVOLUME_LIBRARY_DEBUG - The
       osgVolume debug library

       $OSGDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       Created by Eric Wing.

   FindosgWidget
       This is part of the Findosg* suite used to find	OpenSceneGraph	compo-
       nents.	Each component is separate and you must	opt in to each module.
       You must	also opt into OpenGL and OpenThreads (and Producer if  needed)
       as  these  modules  won't  do it	for you.  This is to allow you control
       over your own system piece by piece in case you need to opt out of cer-
       tain  components	 or  change  the Find behavior for a particular	module
       (perhaps	because	the default FindOpenGL.cmake module doesn't work  with
       your  system as an example).  If	you want to use	a more convenient mod-
       ule that	includes everything, use the FindOpenSceneGraph.cmake  instead
       of the Findosg*.cmake modules.

       Locate osgWidget	This module defines

       OSGWIDGET_FOUND - Was osgWidget found? OSGWIDGET_INCLUDE_DIR - Where to
       find the	headers	OSGWIDGET_LIBRARIES - The libraries to link  for  osg-
       Widget (use this)

       OSGWIDGET_LIBRARY - The osgWidget library OSGWIDGET_LIBRARY_DEBUG - The
       osgWidget debug library

       $OSGDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$OSGDIR used in building	osg.

       FindosgWidget.cmake  tweaked  from  Findosg*  suite  as created by Eric
       Wing.

   FindPatch
       New in version 3.10.

       The module defines the following	variables:

       Patch_EXECUTABLE
	      Path to patch command-line executable.

       Patch_FOUND
	      True if the patch	command-line executable	was found.

       The following IMPORTED targets are also defined:

       Patch::patch
	      The command-line executable.

       Example usage:

	  find_package(Patch)
	  if(Patch_FOUND)
	    message("Patch found: ${Patch_EXECUTABLE}")
	  endif()

   FindPerl
       Find perl

       this module looks for Perl

	  PERL_EXECUTABLE     -	the full path to perl
	  PERL_FOUND	      -	If false, don't	attempt	to use perl.
	  PERL_VERSION_STRING -	version	of perl	found (since CMake 2.8.8)

   FindPerlLibs
       Find Perl libraries

       This module finds if PERL is installed and determines where the include
       files  and  libraries are.  It also determines what the name of the li-
       brary is.  This code sets the following variables:

	  PERLLIBS_FOUND    = True if perl.h & libperl were found
	  PERL_INCLUDE_PATH = path to where perl.h is found
	  PERL_LIBRARY	    = path to libperl
	  PERL_EXECUTABLE   = full path	to the perl binary

       The minimum required version of Perl can	be specified using  the	 stan-
       dard syntax, e.g.  find_package(PerlLibs	6.0)

	  The following	variables are also available if	needed
	  (introduced after CMake 2.6.4)

	  PERL_SITESEARCH     =	path to	the sitesearch install dir (-V:installsitesearch)
	  PERL_SITEARCH	      =	path to	the sitelib install directory (-V:installsitearch)
	  PERL_SITELIB	      =	path to	the sitelib install directory (-V:installsitelib)
	  PERL_VENDORARCH     =	path to	the vendor arch	install	directory (-V:installvendorarch)
	  PERL_VENDORLIB      =	path to	the vendor lib install directory (-V:installvendorlib)
	  PERL_ARCHLIB	      =	path to	the core arch lib install directory (-V:archlib)
	  PERL_PRIVLIB	      =	path to	the core priv lib install directory (-V:privlib)
	  PERL_UPDATE_ARCHLIB =	path to	the update arch	lib install directory (-V:installarchlib)
	  PERL_UPDATE_PRIVLIB =	path to	the update priv	lib install directory (-V:installprivlib)
	  PERL_EXTRA_C_FLAGS = Compilation flags used to build perl

   FindPHP4
       Find PHP4

       This module finds if PHP4 is installed and determines where the include
       files and libraries are.	 It also determines what the name of  the  li-
       brary is.  This code sets the following variables:

	  PHP4_INCLUDE_PATH	  = path to where php.h	can be found
	  PHP4_EXECUTABLE	  = full path to the php4 binary

   FindPhysFS
       Locate  PhysFS  library This module defines PHYSFS_LIBRARY, the name of
       the library to link against PHYSFS_FOUND, if false, do not try to  link
       to PHYSFS PHYSFS_INCLUDE_DIR, where to find physfs.h

       $PHYSFSDIR  is  an  environment	variable  that would correspond	to the
       ./configure --prefix=$PHYSFSDIR used in building	PHYSFS.

       Created by Eric Wing.

   FindPike
       Find Pike

       This module finds if PIKE is installed and determines where the include
       files  and  libraries are.  It also determines what the name of the li-
       brary is.  This code sets the following variables:

	  PIKE_INCLUDE_PATH	  = path to where program.h is found
	  PIKE_EXECUTABLE	  = full path to the pike binary

   FindPkgConfig
       A pkg-config module for CMake.

       Finds  the  pkg-config  executable  and	adds  the  pkg_get_variable(),
       pkg_check_modules()  and	 pkg_search_module()  commands.	 The following
       variables will also be set:

       PKG_CONFIG_FOUND
	      if pkg-config executable was found

       PKG_CONFIG_EXECUTABLE
	      pathname of the pkg-config program

       PKG_CONFIG_VERSION_STRING
	      version of pkg-config (since CMake 2.8.8)

       pkg_check_modules
	      Checks for all the given modules,	setting	a  variety  of	result
	      variables	in the calling scope.

		 pkg_check_modules(<prefix>
				   [REQUIRED] [QUIET]
				   [NO_CMAKE_PATH]
				   [NO_CMAKE_ENVIRONMENT_PATH]
				   [IMPORTED_TARGET [GLOBAL]]
				   <moduleSpec>	[<moduleSpec>...])

	      When  the	REQUIRED argument is given, the	command	will fail with
	      an error if module(s) could not be found.

	      When the QUIET argument is given,	no  status  messages  will  be
	      printed.

	      New in version 3.1: The CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH,
	      and CMAKE_APPBUNDLE_PATH cache and environment variables will be
	      added  to	 the  pkg-config  search  path.	 The NO_CMAKE_PATH and
	      NO_CMAKE_ENVIRONMENT_PATH	arguments disable  this	 behavior  for
	      the cache	variables and environment variables respectively.  The
	      PKG_CONFIG_USE_CMAKE_PREFIX_PATH variable	set to FALSE  disables
	      this behavior globally.

	      New  in version 3.6: The IMPORTED_TARGET argument	will create an
	      imported target named PkgConfig::<prefix>	that can be passed di-
	      rectly as	an argument to target_link_libraries().

	      New  in version 3.13: The	GLOBAL argument	will make the imported
	      target available in global scope.

	      New in version 3.15:  Non-library	 linker	 options  reported  by
	      pkg-config are stored in the INTERFACE_LINK_OPTIONS target prop-
	      erty.

	      Changed in version  3.18:	 Include  directories  specified  with
	      -isystem	are stored in the INTERFACE_INCLUDE_DIRECTORIES	target
	      property.	 Previous versions of CMake left them  in  the	INTER-
	      FACE_COMPILE_OPTIONS property.

	      Each  <moduleSpec> can be	either a bare module name or it	can be
	      a	module name with a version constraint (operators =, <,	>,  <=
	      and  >= are supported).  The following are examples for a	module
	      named foo	with various constraints:

	      o	foo matches any	version.

	      o	foo<2 only matches versions before 2.

	      o	foo>=3.1 matches any version from 3.1 or later.

	      o	foo=1.2.3 requires that	foo must be exactly version 1.2.3.

	      The following variables may be set upon  return.	 Two  sets  of
	      values exist: One	for the	common case (<XXX> = <prefix>) and an-
	      other for	the information	pkg-config provides when  called  with
	      the --static option (<XXX> = <prefix>_STATIC).

	      <XXX>_FOUND
		     set to 1 if module(s) exist

	      <XXX>_LIBRARIES
		     only the libraries	(without the '-l')

	      <XXX>_LINK_LIBRARIES
		     the libraries and their absolute paths

	      <XXX>_LIBRARY_DIRS
		     the paths of the libraries	(without the '-L')

	      <XXX>_LDFLAGS
		     all required linker flags

	      <XXX>_LDFLAGS_OTHER
		     all other linker flags

	      <XXX>_INCLUDE_DIRS
		     the '-I' preprocessor flags (without the '-I')

	      <XXX>_CFLAGS
		     all required cflags

	      <XXX>_CFLAGS_OTHER
		     the other compiler	flags

	      All  but	<XXX>_FOUND may	be a ;-list if the associated variable
	      returned from pkg-config has multiple values.

	      Changed in version  3.18:	 Include  directories  specified  with
	      -isystem	are stored in the <XXX>_INCLUDE_DIRS variable.	Previ-
	      ous versions of CMake left them in <XXX>_CFLAGS_OTHER.

	      There are	some special variables whose  prefix  depends  on  the
	      number  of  <moduleSpec> given.  When there is only one <module-
	      Spec>, <YYY> will	simply be <prefix>, but	if two or  more	 <mod-
	      uleSpec> items are given,	<YYY> will be <prefix>_<moduleName>.

	      <YYY>_VERSION
		     version of	the module

	      <YYY>_PREFIX
		     prefix directory of the module

	      <YYY>_INCLUDEDIR
		     include directory of the module

	      <YYY>_LIBDIR
		     lib directory of the module

	      Changed  in  version 3.8:	For any	given <prefix>,	pkg_check_mod-
	      ules() can be called multiple times with	different  parameters.
	      Previous	versions  of  CMake cached and returned	the first suc-
	      cessful result.

	      Changed in version 3.16: If a full path  to  the	found  library
	      can't  be	determined, but	it's still visible to the linker, pass
	      it through as -l<name>.  Previous	versions of  CMake  failed  in
	      this case.

	      Examples:

		 pkg_check_modules (GLIB2 glib-2.0)

	      Looks  for  any version of glib2.	 If found, the output variable
	      GLIB2_VERSION will hold the actual version found.

		 pkg_check_modules (GLIB2 glib-2.0>=2.10)

	      Looks for	at least version 2.10 of glib2.	 If found, the	output
	      variable GLIB2_VERSION will hold the actual version found.

		 pkg_check_modules (FOO	glib-2.0>=2.10 gtk+-2.0)

	      Looks for	both glib2-2.0 (at least version 2.10) and any version
	      of gtk2+-2.0.  Only if both are found  will  FOO	be  considered
	      found.   The FOO_glib-2.0_VERSION	and FOO_gtk+-2.0_VERSION vari-
	      ables will be set	to their respective found module versions.

		 pkg_check_modules (XRENDER REQUIRED xrender)

	      Requires any version of xrender.	Example	output	variables  set
	      by a successful call:

		 XRENDER_LIBRARIES=Xrender;X11
		 XRENDER_STATIC_LIBRARIES=Xrender;X11;pthread;Xau;Xdmcp

       pkg_search_module
	      The behavior of this command is the same as pkg_check_modules(),
	      except that rather than checking for all the specified  modules,
	      it searches for just the first successful	match.

		 pkg_search_module(<prefix>
				   [REQUIRED] [QUIET]
				   [NO_CMAKE_PATH]
				   [NO_CMAKE_ENVIRONMENT_PATH]
				   [IMPORTED_TARGET [GLOBAL]]
				   <moduleSpec>	[<moduleSpec>...])

	      New  in  version	3.16:  If a module is found, the <prefix>_MOD-
	      ULE_NAME variable	will contain the name of the matching  module.
	      This variable can	be used	if you need to run pkg_get_variable().

	      Example:

		 pkg_search_module (BAR	libxml-2.0 libxml2 libxml>=2)

       pkg_get_variable
	      New in version 3.4.

	      Retrieves	 the value of a	pkg-config variable varName and	stores
	      it in the	result variable	resultVar in the calling scope.

		 pkg_get_variable(<resultVar> <moduleName> <varName>)

	      If pkg-config returns multiple values for	 the  specified	 vari-
	      able, resultVar will contain a ;-list.

	      For example:

		 pkg_get_variable(GI_GIRDIR gobject-introspection-1.0 girdir)

   Variables Affecting Behavior
       PKG_CONFIG_EXECUTABLE
	      This  can	 be  set to the	path of	the pkg-config executable.  If
	      not provided, it will be set by the module as a result of	 call-
	      ing find_program() internally.

	      New  in  version 3.1: The	PKG_CONFIG environment variable	can be
	      used as a	hint.

       PKG_CONFIG_USE_CMAKE_PREFIX_PATH
	      New in version 3.1.

	      Specifies	whether	 pkg_check_modules()  and  pkg_search_module()
	      should  add  the	paths  in  the CMAKE_PREFIX_PATH, CMAKE_FRAME-
	      WORK_PATH	and CMAKE_APPBUNDLE_PATH cache and  environment	 vari-
	      ables to the pkg-config search path.

	      If this variable is not set, this	behavior is enabled by default
	      if CMAKE_MINIMUM_REQUIRED_VERSION	is 3.1 or later, disabled oth-
	      erwise.

   FindPNG
       Find libpng, the	official reference library for the PNG image format.

   Imported targets
       New in version 3.5.

       This module defines the following IMPORTED target:

       PNG::PNG
	      The libpng library, if found.

   Result variables
       This module will	set the	following variables in your project:

       PNG_INCLUDE_DIRS
	      where to find png.h, etc.

       PNG_LIBRARIES
	      the libraries to link against to use PNG.

       PNG_DEFINITIONS
	      You  should add_definitions(${PNG_DEFINITIONS}) before compiling
	      code that	includes png library files.

       PNG_FOUND
	      If false,	do not try to use PNG.

       PNG_VERSION_STRING
	      the version of the PNG library found (since CMake	2.8.8)

   Obsolete variables
       The following variables may also	be set,	for backwards compatibility:

       PNG_LIBRARY
	      where to find the	PNG library.

       PNG_INCLUDE_DIR
	      where to find the	PNG headers (same as PNG_INCLUDE_DIRS)

       Since PNG depends on the	ZLib compression library, none	of  the	 above
       will be defined unless ZLib can be found.

   FindPostgreSQL
       Find the	PostgreSQL installation.

   IMPORTED Targets
       New in version 3.14.

       This  module  defines  IMPORTED	target PostgreSQL::PostgreSQL if Post-
       greSQL has been found.

   Result Variables
       This module will	set the	following variables in your project:

       PostgreSQL_FOUND
	      True if PostgreSQL is found.

       PostgreSQL_LIBRARIES
	      the PostgreSQL libraries needed for linking

       PostgreSQL_INCLUDE_DIRS
	      the directories of the PostgreSQL	headers

       PostgreSQL_LIBRARY_DIRS
	      the link directories for PostgreSQL libraries

       PostgreSQL_VERSION_STRING
	      the version of PostgreSQL	found

       PostgreSQL_TYPE_INCLUDE_DIR
	      the directories of the PostgreSQL	server headers

   Components
       This module contains additional Server component, that forcibly	checks
       for  the	 presence  of  server  headers.	 Note that PostgreSQL_TYPE_IN-
       CLUDE_DIR is set	regardless of the presence of the Server component  in
       find_package call.

   FindProducer
       Though Producer isn't directly part of OpenSceneGraph, its primary user
       is OSG so I consider this part of the Findosg* suite used to find Open-
       SceneGraph  components.	You'll notice that I accept OSGDIR as an envi-
       ronment path.

       Each component is separate and you must opt in  to  each	 module.   You
       must  also opt into OpenGL (and OpenThreads?) as	these modules won't do
       it for you.  This is to allow you control over your own system piece by
       piece  in  case you need	to opt out of certain components or change the
       Find behavior for a particular  module  (perhaps	 because  the  default
       FindOpenGL.cmake	 module	 doesn't work with your	system as an example).
       If you want to use a more convenient module that	 includes  everything,
       use the FindOpenSceneGraph.cmake	instead	of the Findosg*.cmake modules.

       Locate Producer This module defines PRODUCER_LIBRARY PRODUCER_FOUND, if
       false, do not try to link to Producer  PRODUCER_INCLUDE_DIR,  where  to
       find the	headers

       $PRODUCER_DIR  is  an environment variable that would correspond	to the
       ./configure --prefix=$PRODUCER_DIR used in building osg.

       Created by Eric Wing.

   FindProtobuf
       Locate and configure the	Google Protocol	Buffers	library.

       New in version 3.6: Support for find_package() version checks.

       Changed in version 3.6: All input and output variables use  the	Proto-
       buf_  prefix.   Variables with PROTOBUF_	prefix are still supported for
       compatibility.

       The following variables can be set and are optional:

       Protobuf_SRC_ROOT_FOLDER
	      When compiling with MSVC,	if this	cache variable is set the pro-
	      tobuf-default  VS	 project build locations (vsprojects/Debug and
	      vsprojects/Release   or	 vsprojects/x64/Debug	 and	vspro-
	      jects/x64/Release) will be searched for libraries	and binaries.

       Protobuf_IMPORT_DIRS
	      List  of	additional  directories	 to  be	 searched for imported
	      .proto files.

       Protobuf_DEBUG
	      New in version 3.6.

	      Show debug messages.

       Protobuf_USE_STATIC_LIBS
	      New in version 3.9.

	      Set to ON	to force the use of the	static libraries.  Default  is
	      OFF.

       Defines the following variables:

       Protobuf_FOUND
	      Found  the Google	Protocol Buffers library (libprotobuf &	header
	      files)

       Protobuf_VERSION
	      New in version 3.6.

	      Version of package found.

       Protobuf_INCLUDE_DIRS
	      Include directories for Google Protocol Buffers

       Protobuf_LIBRARIES
	      The protobuf libraries

       Protobuf_PROTOC_LIBRARIES
	      The protoc libraries

       Protobuf_LITE_LIBRARIES
	      The protobuf-lite	libraries

       New in version 3.9: The following IMPORTED targets are also defined:

       protobuf::libprotobuf
	      The protobuf library.

       protobuf::libprotobuf-lite
	      The protobuf lite	library.

       protobuf::libprotoc
	      The protoc library.

       protobuf::protoc
	      New in version 3.10: The protoc compiler.

       The following cache variables are also available	to set or use:

       Protobuf_LIBRARY
	      The protobuf library

       Protobuf_PROTOC_LIBRARY
	      The protoc library

       Protobuf_INCLUDE_DIR
	      The include directory for	protocol buffers

       Protobuf_PROTOC_EXECUTABLE
	      The protoc compiler

       Protobuf_LIBRARY_DEBUG
	      The protobuf library (debug)

       Protobuf_PROTOC_LIBRARY_DEBUG
	      The protoc library (debug)

       Protobuf_LITE_LIBRARY
	      The protobuf lite	library

       Protobuf_LITE_LIBRARY_DEBUG
	      The protobuf lite	library	(debug)

       Example:

	  find_package(Protobuf	REQUIRED)
	  include_directories(${Protobuf_INCLUDE_DIRS})
	  include_directories(${CMAKE_CURRENT_BINARY_DIR})
	  protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS foo.proto)
	  protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS EXPORT_MACRO DLL_EXPORT foo.proto)
	  protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS DESCRIPTORS PROTO_DESCS foo.proto)
	  protobuf_generate_python(PROTO_PY foo.proto)
	  add_executable(bar bar.cc ${PROTO_SRCS} ${PROTO_HDRS})
	  target_link_libraries(bar ${Protobuf_LIBRARIES})

       NOTE:
	  The protobuf_generate_cpp and	protobuf_generate_python functions and
	  add_executable()  or	add_library()  calls only work properly	within
	  the same directory.

       protobuf_generate_cpp
	      Add custom commands to process .proto files to C++:

		 protobuf_generate_cpp (<SRCS> <HDRS>
		     [DESCRIPTORS <DESC>] [EXPORT_MACRO	<MACRO>] [<ARGN>...])

	      SRCS   Variable to define	with autogenerated source files

	      HDRS   Variable to define	with autogenerated header files

	      DESCRIPTORS
		     New in version 3.10: Variable to define  with  autogener-
		     ated descriptor files, if requested.

	      EXPORT_MACRO
		     is	 a  macro which	should expand to __declspec(dllexport)
		     or	__declspec(dllimport) depending	on what	is being  com-
		     piled.

	      ARGN   .proto files

       protobuf_generate_python
	      New in version 3.4.

	      Add custom commands to process .proto files to Python:

		 protobuf_generate_python (<PY>	[<ARGN>...])

	      PY     Variable to define	with autogenerated Python files

	      ARGN   .proto files

   FindPython
       New in version 3.12.

       Find  Python interpreter, compiler and development environment (include
       directories and libraries).

       New in version 3.19: When a version is requested, it can	 be  specified
       as  a simple value or as	a range. For a detailed	description of version
       range usage and capabilities, refer to the find_package() command.

       The following components	are supported:

       o Interpreter: search for Python	interpreter.

       o Compiler: search for Python compiler. Only offered by IronPython.

       o Development: search for development  artifacts	 (include  directories
	 and libraries).

	 New in	version	3.18: This component includes two sub-components which
	 can be	specified independently:

	 o Development.Module: search for artifacts for	Python module develop-
	   ments.

	 o Development.Embed: search for artifacts for Python embedding	devel-
	   opments.

       o NumPy:	search for NumPy include directories.

       New in version 3.14: Added the NumPy component.

       If no COMPONENTS	are specified, Interpreter is assumed.

       If component Development	is specified, it implies sub-components	Devel-
       opment.Module and Development.Embed.

       To ensure consistent versions between components	Interpreter, Compiler,
       Development (or one of its sub-components) and NumPy, specify all  com-
       ponents at the same time:

	  find_package (Python COMPONENTS Interpreter Development)

       This  module  looks  preferably	for version 3 of Python. If not	found,
       version 2 is searched.  To  manage  concurrent  versions	 3  and	 2  of
       Python, use FindPython3 and FindPython2 modules rather than this	one.

       NOTE:
	  If  components Interpreter and Development (or one of	its sub-compo-
	  nents) are both specified, this module search	only  for  interpreter
	  with same platform architecture as the one defined by	CMake configu-
	  ration. This constraint does not apply if only Interpreter component
	  is specified.

   Imported Targets
       This module defines the following Imported Targets:

       Changed	in  version  3.14:  Imported  Targets  are  only  created when
       CMAKE_ROLE is PROJECT.

       Python::Interpreter
	      Python interpreter. Target defined if component  Interpreter  is
	      found.

       Python::Compiler
	      Python compiler. Target defined if component Compiler is found.

       Python::Module
	      New in version 3.15.

	      Python  library  for  Python module. Target defined if component
	      Development.Module is found.

       Python::Python
	      Python library for Python	embedding. Target defined if component
	      Development.Embed	is found.

       Python::NumPy
	      New in version 3.14.

	      NumPy  Python  library.  Target  defined	if  component NumPy is
	      found.

   Result Variables
       This module will	set the	following variables in your project (see Stan-
       dard Variable Names):

       Python_FOUND
	      System has the Python requested components.

       Python_Interpreter_FOUND
	      System has the Python interpreter.

       Python_EXECUTABLE
	      Path to the Python interpreter.

       Python_INTERPRETER_ID

	      A	 short	string	unique to the interpreter. Possible values in-
	      clude:

		     o Python

		     o ActivePython

		     o Anaconda

		     o Canopy

		     o IronPython

		     o PyPy

       Python_STDLIB
	      Standard platform	independent installation directory.

	      Information	 returned	  by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=True)	    or
	      else sysconfig.get_path('stdlib').

       Python_STDARCH
	      Standard platform	dependent installation directory.

	      Information	 returned	  by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=True) or else
	      sysconfig.get_path('platstdlib').

       Python_SITELIB
	      Third-party platform independent installation directory.

	      Information	 returned	  by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=False)    or
	      else sysconfig.get_path('purelib').

       Python_SITEARCH
	      Third-party platform dependent installation directory.

	      Information	 returned	  by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=False)	    or
	      else sysconfig.get_path('platlib').

       Python_SOABI
	      New in version 3.17.

	      Extension	suffix for modules.

	      Information     returned	   by	  distutils.sysconfig.get_con-
	      fig_var('SOABI')	or  computed from distutils.sysconfig.get_con-
	      fig_var('EXT_SUFFIX') or	python-config  --extension-suffix.  If
	      package distutils.sysconfig is not available, sysconfig.get_con-
	      fig_var('SOABI') or  sysconfig.get_config_var('EXT_SUFFIX')  are
	      used.

       Python_Compiler_FOUND
	      System has the Python compiler.

       Python_COMPILER
	      Path to the Python compiler. Only	offered	by IronPython.

       Python_COMPILER_ID

	      A	short string unique to the compiler. Possible values include:

		     o IronPython

       Python_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python_Development_FOUND
	      System has the Python development	artifacts.

       Python_Development.Module_FOUND
	      New in version 3.18.

	      System has the Python development	artifacts for Python module.

       Python_Development.Embed_FOUND
	      New in version 3.18.

	      System  has  the	Python development artifacts for Python	embed-
	      ding.

       Python_INCLUDE_DIRS
	  The Python include directories.

       Python_LINK_OPTIONS
	      New in version 3.19.

	      The Python link options. Some  configurations  require  specific
	      link options for a correct build and execution.

       Python_LIBRARIES
	      The Python libraries.

       Python_LIBRARY_DIRS
	      The Python library directories.

       Python_RUNTIME_LIBRARY_DIRS
	      The Python runtime library directories.

       Python_VERSION
	      Python version.

       Python_VERSION_MAJOR
	      Python major version.

       Python_VERSION_MINOR
	      Python minor version.

       Python_VERSION_PATCH
	      Python patch version.

       Python_PyPy_VERSION
	      New in version 3.18.

	      Python PyPy version.

       Python_NumPy_FOUND
	      New in version 3.14.

	      System has the NumPy.

       Python_NumPy_INCLUDE_DIRS
	      New in version 3.14.

	      The NumPy	include	directories.

       Python_NumPy_VERSION
	      New in version 3.14.

	      The NumPy	version.

   Hints
       Python_ROOT_DIR
	      Define the root directory	of a Python installation.

       Python_USE_STATIC_LIBS

	      o	If  not	 defined,  search  for shared libraries	and static li-
		braries	in that	order.

	      o	If set to TRUE,	search only for	static libraries.

	      o	If set to FALSE, search	only for shared	libraries.

       Python_FIND_ABI
	      New in version 3.16.

	      This variable defines which ABIs,	as defined in PEP 3149,	should
	      be searched.

	      NOTE:
		 This  hint will be honored only when searched for Python ver-
		 sion 3.

	      NOTE:
		 If Python_FIND_ABI is not defined, any	ABI will be searched.

	      The Python_FIND_ABI variable is a	3-tuple	 specifying,  in  that
	      order,  pydebug  (d),  pymalloc (m) and unicode (u) flags.  Each
	      element can be set to one	of the following:

	      o	ON: Corresponding flag is selected.

	      o	OFF: Corresponding flag	is not selected.

	      o	ANY: The two possibilities (ON and OFF)	will be	searched.

	      From this	3-tuple, various ABIs will be searched	starting  from
	      the  most	 specialized to	the most general. Moreover, debug ver-
	      sions will be searched after non-debug ones.

	      For example, if we have:

		 set (Python_FIND_ABI "ON" "ANY" "ANY")

	      The following flags combinations will be appended, in  that  or-
	      der, to the artifact names: dmu, dm, du, and d.

	      And to search any	possible ABIs:

		 set (Python_FIND_ABI "ANY" "ANY" "ANY")

	      The  following combinations, in that order, will be used:	mu, m,
	      u, <empty>, dmu, dm, du and d.

	      NOTE:
		 This hint is useful only on POSIX  systems.  So,  on  Windows
		 systems,  when	 Python_FIND_ABI  is defined, Python distribu-
		 tions from python.org will be found only if  value  for  each
		 flag is OFF or	ANY.

       Python_FIND_STRATEGY
	      New in version 3.15.

	      This   variable	defines	  how	lookup	 will  be  done.   The
	      Python_FIND_STRATEGY variable can	be set to one of  the  follow-
	      ing:

	      o	VERSION:  Try to find the most recent version in all specified
		locations.  This is the	default	if policy CMP0094 is undefined
		or set to OLD.

	      o	LOCATION: Stops	lookup as soon as a version satisfying version
		constraints is founded.	 This is the default if	policy CMP0094
		is set to NEW.

       Python_FIND_REGISTRY
	      New in version 3.13.

	      On Windows the Python_FIND_REGISTRY variable determine the order
	      of preference between registry and environment  variables.   the
	      Python_FIND_REGISTRY  variable  can be set to one	of the follow-
	      ing:

	      o	FIRST: Try to use registry before environment variables.  This
		is the default.

	      o	LAST: Try to use registry after	environment variables.

	      o	NEVER: Never try to use	registry.

       Python_FIND_FRAMEWORK
	      New in version 3.15.

	      On  macOS	the Python_FIND_FRAMEWORK variable determine the order
	      of preference between Apple-style	and unix-style package	compo-
	      nents.   This variable can take same values as CMAKE_FIND_FRAME-
	      WORK variable.

	      NOTE:
		 Value ONLY is not supported so	FIRST will be used instead.

	      If Python_FIND_FRAMEWORK is  not	defined,  CMAKE_FIND_FRAMEWORK
	      variable will be used, if	any.

       Python_FIND_VIRTUALENV
	      New in version 3.15.

	      This  variable defines the handling of virtual environments man-
	      aged by virtualenv or conda. It is meaningful only when  a  vir-
	      tual  environment	 is  active (i.e. the activate script has been
	      evaluated).   In	 this	case,	it   takes   precedence	  over
	      Python_FIND_REGISTRY  and	 CMAKE_FIND_FRAMEWORK  variables.  The
	      Python_FIND_VIRTUALENV variable can be set to one	of the follow-
	      ing:

	      o	FIRST:	The virtual environment	is used	before any other stan-
		dard paths to look-up for the interpreter.  This  is  the  de-
		fault.

	      o	ONLY:  Only the	virtual	environment is used to look-up for the
		interpreter.

	      o	STANDARD: The virtual environment is not used to  look-up  for
		the  interpreter  but environment variable PATH	is always con-
		sidered.  In this case,	 variable  Python_FIND_REGISTRY	 (Win-
		dows)  or  CMAKE_FIND_FRAMEWORK	 (macOS) can be	set with value
		LAST or	NEVER to select	preferably the	interpreter  from  the
		virtual	environment.

	      New in version 3.17: Added support for conda environments.

	      NOTE:
		 If  the  component  Development  is requested,	it is strongly
		 recommended to	also include the component Interpreter to  get
		 expected result.

       Python_FIND_IMPLEMENTATIONS
	      New in version 3.18.

	      This  variable defines, in an ordered list, the different	imple-
	      mentations which will be searched.  The  Python_FIND_IMPLEMENTA-
	      TIONS variable can hold the following values:

	      o	CPython:  this	is  the	standard implementation. Various prod-
		ucts, like Anaconda or ActivePython, rely on this  implementa-
		tion.

	      o	IronPython:  This  implementation  use the CSharp language for
		.NET Framework on top of the Dynamic Language  Runtime	(DLR).
		See IronPython.

	      o	PyPy:  This  implementation  use  RPython language and RPython
		translation toolchain to produce the python interpreter.   See
		PyPy.

	      The default value	is:

	      o	Windows	platform: CPython, IronPython

	      o	Other platforms: CPython

	      NOTE:
		 This  hint  has the lowest priority of	all hints, so even if,
		 for example, you specify IronPython first and CPython in sec-
		 ond,  a  python  product based	on CPython can be selected be-
		 cause,	for example with  Python_FIND_STRATEGY=LOCATION,  each
		 location  will	 be search first for IronPython	and second for
		 CPython.

	      NOTE:
		 When IronPython is specified, on platforms  other  than  Win-
		 dows, the .Net	interpreter (i.e. mono command)	is expected to
		 be available through the PATH variable.

       Python_FIND_UNVERSIONED_NAMES
	      New in version 3.20.

	      This variable defines how	the generic names  will	 be  searched.
	      Currently,  it  only  applies to the generic names of the	inter-
	      preter,  namely,	 python3   or	python2	  and	python.	   The
	      Python_FIND_UNVERSIONED_NAMES  variable can be set to one	of the
	      following	values:

	      o	FIRST: The generic names are searched before the more special-
		ized ones (such	as python2.5 for example).

	      o	LAST:  The  generic names are searched after the more special-
		ized ones.  This is the	default.

	      o	NEVER: The generic name	are not	searched at all.

   Artifacts Specification
       New in version 3.16.

       To solve	special	cases, it is possible to specify  directly  the	 arti-
       facts by	setting	the following variables:

       Python_EXECUTABLE
	      The path to the interpreter.

       Python_COMPILER
	      The path to the compiler.

       Python_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python_LIBRARY
	      The  path	 to  the library. It will be used to compute the vari-
	      ables  Python_LIBRARIES,	Python_LIBRARY_DIRS  and   Python_RUN-
	      TIME_LIBRARY_DIRS.

       Python_INCLUDE_DIR
	      The path to the directory	of the Python headers. It will be used
	      to compute the variable Python_INCLUDE_DIRS.

       Python_NumPy_INCLUDE_DIR
	      The path to the directory	of the NumPy headers. It will be  used
	      to compute the variable Python_NumPy_INCLUDE_DIRS.

       NOTE:
	  All  paths  must be absolute.	Any artifact specified with a relative
	  path will be ignored.

       NOTE:
	  When an artifact is specified, all HINTS  will  be  ignored  and  no
	  search will be performed for this artifact.

	  If  more  than one artifact is specified, it is the user's responsi-
	  bility to ensure the consistency of the various artifacts.

       By default, this	module supports	multiple calls in  different  directo-
       ries  of	 a project with	different version/component requirements while
       providing correct and consistent	results	for each call. To support this
       behavior,  CMake	 cache is not used in the traditional way which	can be
       problematic for interactive specification. So, to enable	also  interac-
       tive  specification, module behavior can	be controlled with the follow-
       ing variable:

       Python_ARTIFACTS_INTERACTIVE
	      New in version 3.18.

	      Selects the behavior of the module. This is a boolean variable:

	      o	If set to TRUE:	Create CMake cache entries for the above arti-
		fact  specification  variables so that users can edit them in-
		teractively.  This disables support for	multiple  version/com-
		ponent requirements.

	      o	If  set	 to FALSE or undefined:	Enable multiple	version/compo-
		nent requirements.

   Commands
       This module defines the command Python_add_library (when	CMAKE_ROLE  is
       PROJECT),  which	has the	same semantics as add_library()	and adds a de-
       pendency	to target Python::Python or, when library type is  MODULE,  to
       target Python::Module and takes care of Python module naming rules:

	  Python_add_library (<name> [STATIC | SHARED |	MODULE [WITH_SOABI]]
			      <source1>	[<source2> ...])

       If the library type is not specified, MODULE is assumed.

       New  in	version	3.17: For MODULE library type, if option WITH_SOABI is
       specified, the module suffix will include the  Python_SOABI  value,  if
       any.

   FindPython2
       New in version 3.12.

       Find  Python  2	interpreter, compiler and development environment (in-
       clude directories and libraries).

       New in version 3.19: When a version is requested, it can	 be  specified
       as  a simple value or as	a range. For a detailed	description of version
       range usage and capabilities, refer to the find_package() command.

       The following components	are supported:

       o Interpreter: search for Python	2 interpreter

       o Compiler: search for Python 2 compiler. Only offered by IronPython.

       o Development: search for development  artifacts	 (include  directories
	 and libraries).

	 New in	version	3.18: This component includes two sub-components which
	 can be	specified independently:

	 o Development.Module: search for artifacts for	Python 2 module	devel-
	   opments.

	 o Development.Embed:  search for artifacts for	Python 2 embedding de-
	   velopments.

       o NumPy:	search for NumPy include directories.

       New in version 3.14: Added the NumPy component.

       If no COMPONENTS	are specified, Interpreter is assumed.

       If component Development	is specified, it implies sub-components	Devel-
       opment.Module and Development.Embed.

       To ensure consistent versions between components	Interpreter, Compiler,
       Development (or one of its sub-components) and NumPy, specify all  com-
       ponents at the same time:

	  find_package (Python2	COMPONENTS Interpreter Development)

       This module looks only for version 2 of Python. This module can be used
       concurrently with FindPython3 module to use both	Python versions.

       The FindPython module can be used if Python version does	not matter for
       you.

       NOTE:
	  If  components Interpreter and Development (or one of	its sub-compo-
	  nents) are both specified, this module search	only  for  interpreter
	  with same platform architecture as the one defined by	CMake configu-
	  ration. This constraint does not apply if only Interpreter component
	  is specified.

   Imported Targets
       This module defines the following Imported Targets:

       Changed	in  version  3.14:  Imported  Targets  are  only  created when
       CMAKE_ROLE is PROJECT.

       Python2::Interpreter
	      Python 2 interpreter. Target defined if component	Interpreter is
	      found.

       Python2::Compiler
	      Python  2	 compiler.  Target  defined  if	 component Compiler is
	      found.

       Python2::Module
	      New in version 3.15.

	      Python 2 library for Python module. Target defined if  component
	      Development.Module is found.

       Python2::Python
	      Python  2	library	for Python embedding. Target defined if	compo-
	      nent Development.Embed is	found.

       Python2::NumPy
	      New in version 3.14.

	      NumPy library for	Python 2. Target defined if component NumPy is
	      found.

   Result Variables
       This module will	set the	following variables in your project (see Stan-
       dard Variable Names):

       Python2_FOUND
	      System has the Python 2 requested	components.

       Python2_Interpreter_FOUND
	      System has the Python 2 interpreter.

       Python2_EXECUTABLE
	      Path to the Python 2 interpreter.

       Python2_INTERPRETER_ID

	      A	short string unique to the interpreter.	 Possible  values  in-
	      clude:

		     o Python

		     o ActivePython

		     o Anaconda

		     o Canopy

		     o IronPython

		     o PyPy

       Python2_STDLIB
	      Standard platform	independent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=True)	    or
	      else sysconfig.get_path('stdlib').

       Python2_STDARCH
	      Standard platform	dependent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=True) or else
	      sysconfig.get_path('platstdlib').

       Python2_SITELIB
	      Third-party platform independent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=False)    or
	      else sysconfig.get_path('purelib').

       Python2_SITEARCH
	      Third-party platform dependent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=False)	    or
	      else sysconfig.get_path('platlib').

       Python2_Compiler_FOUND
	      System has the Python 2 compiler.

       Python2_COMPILER
	      Path to the Python 2 compiler. Only offered by IronPython.

       Python2_COMPILER_ID

	      A	short string unique to the compiler. Possible values include:

		     o IronPython

       Python2_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python2_Development_FOUND
	      System has the Python 2 development artifacts.

       Python2_Development.Module_FOUND
	      New in version 3.18.

	      System has the Python 2 development artifacts for	Python module.

       Python2_Development.Embed_FOUND
	      New in version 3.18.

	      System  has the Python 2 development artifacts for Python	embed-
	      ding.

       Python2_INCLUDE_DIRS
	      The Python 2 include directories.

       Python2_LINK_OPTIONS
	      New in version 3.19.

	      The Python 2 link	options. Some configurations require  specific
	      link options for a correct build and execution.

       Python2_LIBRARIES
	      The Python 2 libraries.

       Python2_LIBRARY_DIRS
	      The Python 2 library directories.

       Python2_RUNTIME_LIBRARY_DIRS
	      The Python 2 runtime library directories.

       Python2_VERSION
	      Python 2 version.

       Python2_VERSION_MAJOR
	      Python 2 major version.

       Python2_VERSION_MINOR
	      Python 2 minor version.

       Python2_VERSION_PATCH
	      Python 2 patch version.

       Python2_PyPy_VERSION
	      New in version 3.18.

	      Python 2 PyPy version.

       Python2_NumPy_FOUND
	      New in version 3.14.

	      System has the NumPy.

       Python2_NumPy_INCLUDE_DIRS
	      New in version 3.14.

	      The NumPy	include	directories.

       Python2_NumPy_VERSION
	      New in version 3.14.

	      The NumPy	version.

   Hints
       Python2_ROOT_DIR
	      Define the root directory	of a Python 2 installation.

       Python2_USE_STATIC_LIBS

	      o	If  not	 defined,  search  for shared libraries	and static li-
		braries	in that	order.

	      o	If set to TRUE,	search only for	static libraries.

	      o	If set to FALSE, search	only for shared	libraries.

       Python2_FIND_STRATEGY
	      New in version 3.15.

	      This  variable  defines  how   lookup   will   be	  done.	   The
	      Python2_FIND_STRATEGY  variable can be set to one	of the follow-
	      ing:

	      o	VERSION: Try to	find the most recent version in	all  specified
		locations.  This is the	default	if policy CMP0094 is undefined
		or set to OLD.

	      o	LOCATION: Stops	lookup as soon as a version satisfying version
		constraints is founded.	 This is the default if	policy CMP0094
		is set to NEW.

       Python2_FIND_REGISTRY
	      New in version 3.13.

	      On Windows the Python2_FIND_REGISTRY variable determine the  or-
	      der  of  preference  between registry and	environment variables.
	      the Python2_FIND_REGISTRY	variable can be	set to one of the fol-
	      lowing:

	      o	FIRST: Try to use registry before environment variables.  This
		is the default.

	      o	LAST: Try to use registry after	environment variables.

	      o	NEVER: Never try to use	registry.

       Python2_FIND_FRAMEWORK
	      New in version 3.15.

	      On macOS the Python2_FIND_FRAMEWORK variable determine the order
	      of  preference between Apple-style and unix-style	package	compo-
	      nents.  This variable can	take same values as  CMAKE_FIND_FRAME-
	      WORK variable.

	      NOTE:
		 Value ONLY is not supported so	FIRST will be used instead.

	      If  Python2_FIND_FRAMEWORK  is not defined, CMAKE_FIND_FRAMEWORK
	      variable will be used, if	any.

       Python2_FIND_VIRTUALENV
	      New in version 3.15.

	      This variable defines the	handling of virtual environments  man-
	      aged  by	virtualenv or conda. It	is meaningful only when	a vir-
	      tual environment is active (i.e. the activate  script  has  been
	      evaluated).   In	 this	case,	it   takes   precedence	  over
	      Python2_FIND_REGISTRY and	CMAKE_FIND_FRAMEWORK  variables.   The
	      Python2_FIND_VIRTUALENV  variable	 can be	set to one of the fol-
	      lowing:

	      o	FIRST: The virtual environment is used before any other	 stan-
		dard  paths  to	 look-up  for the interpreter. This is the de-
		fault.

	      o	ONLY: Only the virtual environment is used to look-up for  the
		interpreter.

	      o	STANDARD:  The	virtual	environment is not used	to look-up for
		the interpreter	but environment	variable PATH is  always  con-
		sidered.   In  this case, variable Python2_FIND_REGISTRY (Win-
		dows) or CMAKE_FIND_FRAMEWORK (macOS) can be  set  with	 value
		LAST  or  NEVER	 to select preferably the interpreter from the
		virtual	environment.

	      New in version 3.17: Added support for conda environments.

	      NOTE:
		 If the	component Development is  requested,  it  is  strongly
		 recommended  to also include the component Interpreter	to get
		 expected result.

       Python2_FIND_IMPLEMENTATIONS
	      New in version 3.18.

	      This variable defines, in	an ordered list, the different	imple-
	      mentations  which	will be	searched. The Python2_FIND_IMPLEMENTA-
	      TIONS variable can hold the following values:

	      o	CPython: this is the standard  implementation.	Various	 prod-
		ucts,  like Anaconda or	ActivePython, rely on this implementa-
		tion.

	      o	IronPython: This implementation	use the	 CSharp	 language  for
		.NET  Framework	 on top	of the Dynamic Language	Runtime	(DLR).
		See IronPython.

	      o	PyPy: This implementation use  RPython	language  and  RPython
		translation  toolchain to produce the python interpreter.  See
		PyPy.

	      The default value	is:

	      o	Windows	platform: CPython, IronPython

	      o	Other platforms: CPython

	      NOTE:
		 This hint has the lowest priority of all hints, so  even  if,
		 for example, you specify IronPython first and CPython in sec-
		 ond, a	python product based on	CPython	can  be	 selected  be-
		 cause,	 for example with Python2_FIND_STRATEGY=LOCATION, each
		 location will be search first for IronPython and  second  for
		 CPython.

	      NOTE:
		 When  IronPython  is  specified, on platforms other than Win-
		 dows, the .Net	interpreter (i.e. mono command)	is expected to
		 be available through the PATH variable.

       Python2_FIND_UNVERSIONED_NAMES
	      New in version 3.20.

	      This  variable  defines  how the generic names will be searched.
	      Currently, it only applies to the	generic	names  of  the	inter-
	      preter,  namely,	python2	 and  python.  The Python2_FIND_UNVER-
	      SIONED_NAMES variable can	be set to one of the following values:

	      o	FIRST: The generic names are searched before the more special-
		ized ones (such	as python2.5 for example).

	      o	LAST:  The  generic names are searched after the more special-
		ized ones.  This is the	default.

	      o	NEVER: The generic name	are not	searched at all.

   Artifacts Specification
       New in version 3.16.

       To solve	special	cases, it is possible to specify  directly  the	 arti-
       facts by	setting	the following variables:

       Python2_EXECUTABLE
	      The path to the interpreter.

       Python2_COMPILER
	      The path to the compiler.

       Python2_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python2_LIBRARY
	      The  path	 to  the library. It will be used to compute the vari-
	      ables Python2_LIBRARIES, Python2_LIBRARY_DIRS  and  Python2_RUN-
	      TIME_LIBRARY_DIRS.

       Python2_INCLUDE_DIR
	      The path to the directory	of the Python headers. It will be used
	      to compute the variable Python2_INCLUDE_DIRS.

       Python2_NumPy_INCLUDE_DIR
	      The path to the directory	of the NumPy headers. It will be  used
	      to compute the variable Python2_NumPy_INCLUDE_DIRS.

       NOTE:
	  All  paths  must be absolute.	Any artifact specified with a relative
	  path will be ignored.

       NOTE:
	  When an artifact is specified, all HINTS  will  be  ignored  and  no
	  search will be performed for this artifact.

	  If  more  than one artifact is specified, it is the user's responsi-
	  bility to ensure the consistency of the various artifacts.

       By default, this	module supports	multiple calls in  different  directo-
       ries  of	 a project with	different version/component requirements while
       providing correct and consistent	results	for each call. To support this
       behavior,  CMake	 cache is not used in the traditional way which	can be
       problematic for interactive specification. So, to enable	also  interac-
       tive  specification, module behavior can	be controlled with the follow-
       ing variable:

       Python2_ARTIFACTS_INTERACTIVE
	      New in version 3.18.

	      Selects the behavior of the module. This is a boolean variable:

	      o	If set to TRUE:	Create CMake cache entries for the above arti-
		fact  specification  variables so that users can edit them in-
		teractively.  This disables support for	multiple  version/com-
		ponent requirements.

	      o	If  set	 to FALSE or undefined:	Enable multiple	version/compo-
		nent requirements.

   Commands
       This module defines the command Python2_add_library (when CMAKE_ROLE is
       PROJECT),  which	has the	same semantics as add_library()	and adds a de-
       pendency	to target Python2::Python or, when library type	is MODULE,  to
       target Python2::Module and takes	care of	Python module naming rules:

	  Python2_add_library (<name> [STATIC |	SHARED | MODULE]
			       <source1> [<source2> ...])

       If library type is not specified, MODULE	is assumed.

   FindPython3
       New in version 3.12.

       Find  Python  3	interpreter, compiler and development environment (in-
       clude directories and libraries).

       New in version 3.19: When a version is requested, it can	 be  specified
       as  a simple value or as	a range. For a detailed	description of version
       range usage and capabilities, refer to the find_package() command.

       The following components	are supported:

       o Interpreter: search for Python	3 interpreter

       o Compiler: search for Python 3 compiler. Only offered by IronPython.

       o Development: search for development  artifacts	 (include  directories
	 and libraries).

	 New in	version	3.18: This component includes two sub-components which
	 can be	specified independently:

	 o Development.Module: search for artifacts for	Python 3 module	devel-
	   opments.

	 o Development.Embed:  search for artifacts for	Python 3 embedding de-
	   velopments.

       o NumPy:	search for NumPy include directories.

       New in version 3.14: Added the NumPy component.

       If no COMPONENTS	are specified, Interpreter is assumed.

       If component Development	is specified, it implies sub-components	Devel-
       opment.Module and Development.Embed.

       To ensure consistent versions between components	Interpreter, Compiler,
       Development (or one of its sub-components) and NumPy, specify all  com-
       ponents at the same time:

	  find_package (Python3	COMPONENTS Interpreter Development)

       This module looks only for version 3 of Python. This module can be used
       concurrently with FindPython2 module to use both	Python versions.

       The FindPython module can be used if Python version does	not matter for
       you.

       NOTE:
	  If  components Interpreter and Development (or one of	its sub-compo-
	  nents) are both specified, this module search	only  for  interpreter
	  with same platform architecture as the one defined by	CMake configu-
	  ration. This constraint does not apply if only Interpreter component
	  is specified.

   Imported Targets
       This module defines the following Imported Targets:

       Changed	in  version  3.14:  Imported  Targets  are  only  created when
       CMAKE_ROLE is PROJECT.

       Python3::Interpreter
	      Python 3 interpreter. Target defined if component	Interpreter is
	      found.

       Python3::Compiler
	      Python  3	 compiler.  Target  defined  if	 component Compiler is
	      found.

       Python3::Module
	      New in version 3.15.

	      Python 3 library for Python module. Target defined if  component
	      Development.Module is found.

       Python3::Python
	      Python  3	library	for Python embedding. Target defined if	compo-
	      nent Development.Embed is	found.

       Python3::NumPy
	      New in version 3.14.

	      NumPy library for	Python 3. Target defined if component NumPy is
	      found.

   Result Variables
       This module will	set the	following variables in your project (see Stan-
       dard Variable Names):

       Python3_FOUND
	      System has the Python 3 requested	components.

       Python3_Interpreter_FOUND
	      System has the Python 3 interpreter.

       Python3_EXECUTABLE
	      Path to the Python 3 interpreter.

       Python3_INTERPRETER_ID

	      A	short string unique to the interpreter.	 Possible  values  in-
	      clude:

		     o Python

		     o ActivePython

		     o Anaconda

		     o Canopy

		     o IronPython

		     o PyPy

       Python3_STDLIB
	      Standard platform	independent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=True)	    or
	      else sysconfig.get_path('stdlib').

       Python3_STDARCH
	      Standard platform	dependent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=True) or else
	      sysconfig.get_path('platstdlib').

       Python3_SITELIB
	      Third-party platform independent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=False,standard_lib=False)    or
	      else sysconfig.get_path('purelib').

       Python3_SITEARCH
	      Third-party platform dependent installation directory.

	      Information	  returned	   by	     distutils.syscon-
	      fig.get_python_lib(plat_specific=True,standard_lib=False)	    or
	      else sysconfig.get_path('platlib').

       Python3_SOABI
	      New in version 3.17.

	      Extension	suffix for modules.

	      Information     returned	   by	  distutils.sysconfig.get_con-
	      fig_var('SOABI') or computed  from  distutils.sysconfig.get_con-
	      fig_var('EXT_SUFFIX')  or	 python3-config	--extension-suffix. If
	      package distutils.sysconfig is not available, sysconfig.get_con-
	      fig_var('SOABI')	or  sysconfig.get_config_var('EXT_SUFFIX') are
	      used.

       Python3_Compiler_FOUND
	      System has the Python 3 compiler.

       Python3_COMPILER
	      Path to the Python 3 compiler. Only offered by IronPython.

       Python3_COMPILER_ID

	      A	short string unique to the compiler. Possible values include:

		     o IronPython

       Python3_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python3_Development_FOUND
	  System has the Python	3 development artifacts.

       Python3_Development.Module_FOUND
	      New in version 3.18.

	      System has the Python 3 development artifacts for	Python module.

       Python3_Development.Embed_FOUND
	      New in version 3.18.

	      System has the Python 3 development artifacts for	Python	embed-
	      ding.

       Python3_INCLUDE_DIRS
	  The Python 3 include directories.

       Python3_LINK_OPTIONS
	      New in version 3.19.

	      The  Python 3 link options. Some configurations require specific
	      link options for a correct build and execution.

       Python3_LIBRARIES
	      The Python 3 libraries.

       Python3_LIBRARY_DIRS
	      The Python 3 library directories.

       Python3_RUNTIME_LIBRARY_DIRS
	      The Python 3 runtime library directories.

       Python3_VERSION
	      Python 3 version.

       Python3_VERSION_MAJOR
	      Python 3 major version.

       Python3_VERSION_MINOR
	      Python 3 minor version.

       Python3_VERSION_PATCH
	      Python 3 patch version.

       Python3_PyPy_VERSION
	      New in version 3.18.

	      Python 3 PyPy version.

       Python3_NumPy_FOUND
	      New in version 3.14.

	      System has the NumPy.

       Python3_NumPy_INCLUDE_DIRS
	      New in version 3.14.

	      The NumPy	include	directories.

       Python3_NumPy_VERSION
	      New in version 3.14.

	      The NumPy	version.

   Hints
       Python3_ROOT_DIR
	      Define the root directory	of a Python 3 installation.

       Python3_USE_STATIC_LIBS

	      o	If not defined,	search for shared  libraries  and  static  li-
		braries	in that	order.

	      o	If set to TRUE,	search only for	static libraries.

	      o	If set to FALSE, search	only for shared	libraries.

       Python3_FIND_ABI
	      New in version 3.16.

	      This variable defines which ABIs,	as defined in PEP 3149,	should
	      be searched.

	      NOTE:
		 If Python3_FIND_ABI is	not defined, any ABI will be searched.

	      The Python3_FIND_ABI variable is a 3-tuple specifying,  in  that
	      order,  pydebug  (d),  pymalloc (m) and unicode (u) flags.  Each
	      element can be set to one	of the following:

	      o	ON: Corresponding flag is selected.

	      o	OFF: Corresponding flag	is not selected.

	      o	ANY: The two possibilities (ON and OFF)	will be	searched.

	      From this	3-tuple, various ABIs will be searched	starting  from
	      the  most	 specialized to	the most general. Moreover, debug ver-
	      sions will be searched after non-debug ones.

	      For example, if we have:

		 set (Python3_FIND_ABI "ON" "ANY" "ANY")

	      The following flags combinations will be appended, in  that  or-
	      der, to the artifact names: dmu, dm, du, and d.

	      And to search any	possible ABIs:

		 set (Python3_FIND_ABI "ANY" "ANY" "ANY")

	      The  following combinations, in that order, will be used:	mu, m,
	      u, <empty>, dmu, dm, du and d.

	      NOTE:
		 This hint is useful only on POSIX  systems.  So,  on  Windows
		 systems,  when	 Python3_FIND_ABI is defined, Python distribu-
		 tions from python.org will be found only if  value  for  each
		 flag is OFF or	ANY.

       Python3_FIND_STRATEGY
	      New in version 3.15.

	      This   variable	defines	  how	lookup	 will  be  done.   The
	      Python3_FIND_STRATEGY variable can be set	to one of the  follow-
	      ing:

	      o	VERSION:  Try to find the most recent version in all specified
		locations.  This is the	default	if policy CMP0094 is undefined
		or set to OLD.

	      o	LOCATION: Stops	lookup as soon as a version satisfying version
		constraints is founded.	 This is the default if	policy CMP0094
		is set to NEW.

       Python3_FIND_REGISTRY
	      New in version 3.13.

	      On  Windows the Python3_FIND_REGISTRY variable determine the or-
	      der of preference	between	registry  and  environment  variables.
	      The Python3_FIND_REGISTRY	variable can be	set to one of the fol-
	      lowing:

	      o	FIRST: Try to use registry before environment variables.  This
		is the default.

	      o	LAST: Try to use registry after	environment variables.

	      o	NEVER: Never try to use	registry.

       Python3_FIND_FRAMEWORK
	      New in version 3.15.

	      On macOS the Python3_FIND_FRAMEWORK variable determine the order
	      of preference between Apple-style	and unix-style package	compo-
	      nents.   This variable can take same values as CMAKE_FIND_FRAME-
	      WORK variable.

	      NOTE:
		 Value ONLY is not supported so	FIRST will be used instead.

	      If Python3_FIND_FRAMEWORK	is not	defined,  CMAKE_FIND_FRAMEWORK
	      variable will be used, if	any.

       Python3_FIND_VIRTUALENV
	      New in version 3.15.

	      This  variable defines the handling of virtual environments man-
	      aged by virtualenv or conda. It is meaningful only when  a  vir-
	      tual  environment	 is  active (i.e. the activate script has been
	      evaluated).   In	 this	case,	it   takes   precedence	  over
	      Python3_FIND_REGISTRY  and  CMAKE_FIND_FRAMEWORK variables.  The
	      Python3_FIND_VIRTUALENV variable can be set to one of  the  fol-
	      lowing:

	      o	FIRST:	The virtual environment	is used	before any other stan-
		dard paths to look-up for the interpreter.  This  is  the  de-
		fault.

	      o	ONLY:  Only the	virtual	environment is used to look-up for the
		interpreter.

	      o	STANDARD: The virtual environment is not used to  look-up  for
		the  interpreter  but environment variable PATH	is always con-
		sidered.  In this case,	variable  Python3_FIND_REGISTRY	 (Win-
		dows)  or  CMAKE_FIND_FRAMEWORK	 (macOS) can be	set with value
		LAST or	NEVER to select	preferably the	interpreter  from  the
		virtual	environment.

	      New in version 3.17: Added support for conda environments.

	      NOTE:
		 If  the  component  Development  is requested,	it is strongly
		 recommended to	also include the component Interpreter to  get
		 expected result.

       Python3_FIND_IMPLEMENTATIONS
	      New in version 3.18.

	      This  variable defines, in an ordered list, the different	imple-
	      mentations which will be searched. The  Python3_FIND_IMPLEMENTA-
	      TIONS variable can hold the following values:

	      o	CPython:  this	is  the	standard implementation. Various prod-
		ucts, like Anaconda or ActivePython, rely on this  implementa-
		tion.

	      o	IronPython:  This  implementation  use the CSharp language for
		.NET Framework on top of the Dynamic Language  Runtime	(DLR).
		See IronPython.

	      o	PyPy:  This  implementation  use  RPython language and RPython
		translation toolchain to produce the python interpreter.   See
		PyPy.

	      The default value	is:

	      o	Windows	platform: CPython, IronPython

	      o	Other platforms: CPython

	      NOTE:
		 This  hint  has the lowest priority of	all hints, so even if,
		 for example, you specify IronPython first and CPython in sec-
		 ond,  a  python  product based	on CPython can be selected be-
		 cause,	for example with Python3_FIND_STRATEGY=LOCATION,  each
		 location  will	 be search first for IronPython	and second for
		 CPython.

	      NOTE:
		 When IronPython is specified, on platforms  other  than  Win-
		 dows, the .Net	interpreter (i.e. mono command)	is expected to
		 be available through the PATH variable.

       Python3_FIND_UNVERSIONED_NAMES
	      New in version 3.20.

	      This variable defines how	the generic names  will	 be  searched.
	      Currently,  it  only  applies to the generic names of the	inter-
	      preter, namely, python3  and  python.   The  Python3_FIND_UNVER-
	      SIONED_NAMES variable can	be set to one of the following values:

	      o	FIRST: The generic names are searched before the more special-
		ized ones (such	as python3.5 for example).

	      o	LAST: The generic names	are searched after the	more  special-
		ized ones.  This is the	default.

	      o	NEVER: The generic name	are not	searched at all.

   Artifacts Specification
       New in version 3.16.

       To  solve  special  cases, it is	possible to specify directly the arti-
       facts by	setting	the following variables:

       Python3_EXECUTABLE
	      The path to the interpreter.

       Python3_COMPILER
	      The path to the compiler.

       Python3_DOTNET_LAUNCHER
	      New in version 3.18.

	      The .Net interpreter. Only used by IronPython implementation.

       Python3_LIBRARY
	      The path to the library. It will be used to  compute  the	 vari-
	      ables  Python3_LIBRARIES,	 Python3_LIBRARY_DIRS and Python3_RUN-
	      TIME_LIBRARY_DIRS.

       Python3_INCLUDE_DIR
	      The path to the directory	of the Python headers. It will be used
	      to compute the variable Python3_INCLUDE_DIRS.

       Python3_NumPy_INCLUDE_DIR
	      The  path	to the directory of the	NumPy headers. It will be used
	      to compute the variable Python3_NumPy_INCLUDE_DIRS.

       NOTE:
	  All paths must be absolute. Any artifact specified with  a  relative
	  path will be ignored.

       NOTE:
	  When	an  artifact  is  specified,  all HINTS	will be	ignored	and no
	  search will be performed for this artifact.

	  If more than one artifact is specified, it is	the  user's  responsi-
	  bility to ensure the consistency of the various artifacts.

       By  default,  this module supports multiple calls in different directo-
       ries of a project with different	version/component  requirements	 while
       providing correct and consistent	results	for each call. To support this
       behavior, CMake cache is	not used in the	traditional way	which  can  be
       problematic  for	interactive specification. So, to enable also interac-
       tive specification, module behavior can be controlled with the  follow-
       ing variable:

       Python3_ARTIFACTS_INTERACTIVE
	      New in version 3.18.

	      Selects the behavior of the module. This is a boolean variable:

	      o	If set to TRUE:	Create CMake cache entries for the above arti-
		fact specification variables so	that users can edit  them  in-
		teractively.   This disables support for multiple version/com-
		ponent requirements.

	      o	If set to FALSE	or undefined: Enable  multiple	version/compo-
		nent requirements.

   Commands
       This module defines the command Python3_add_library (when CMAKE_ROLE is
       PROJECT), which has the same semantics as add_library() and adds	a  de-
       pendency	 to target Python3::Python or, when library type is MODULE, to
       target Python3::Module and takes	care of	Python module naming rules:

	  Python3_add_library (<name> [STATIC |	SHARED | MODULE	[WITH_SOABI]]
			       <source1> [<source2> ...])

       If the library type is not specified, MODULE is assumed.

       New in version 3.17: For	MODULE library type, if	option	WITH_SOABI  is
       specified,  the	module suffix will include the Python3_SOABI value, if
       any.

   FindQt3
       Locate Qt include paths and libraries

       This module defines:

	  QT_INCLUDE_DIR    - where to find qt.h, etc.
	  QT_LIBRARIES	    - the libraries to link against to use Qt.
	  QT_DEFINITIONS    - definitions to use when
			      compiling	code that uses Qt.
	  QT_FOUND	    - If false,	don't try to use Qt.
	  QT_VERSION_STRING - the version of Qt	found

       If you need the multithreaded version of	Qt, set	QT_MT_REQUIRED to TRUE

       Also defined, but not for general use are:

	  QT_MOC_EXECUTABLE, where to find the moc tool.
	  QT_UIC_EXECUTABLE, where to find the uic tool.
	  QT_QT_LIBRARY, where to find the Qt library.
	  QT_QTMAIN_LIBRARY, where to find the qtmain
	   library. This is only required by Qt3 on Windows.

   FindQt4
   Finding and Using Qt4
       This module can be used to find Qt4.  The most important	issue is  that
       the  Qt4	 qmake	is  available via the system path.  This qmake is then
       used to detect basically	everything else.  This module defines a	number
       of IMPORTED targets, macros and variables.

       Typical usage could be something	like:

	  set(CMAKE_AUTOMOC ON)
	  set(CMAKE_INCLUDE_CURRENT_DIR	ON)
	  find_package(Qt4 4.4.3 REQUIRED QtGui	QtXml)
	  add_executable(myexe main.cpp)
	  target_link_libraries(myexe Qt4::QtGui Qt4::QtXml)

       NOTE:
	  When	using IMPORTED targets,	the qtmain.lib static library is auto-
	  matically linked on Windows for WIN32	executables. To	 disable  that
	  globally, set	the QT4_NO_LINK_QTMAIN variable	before finding Qt4. To
	  disable that for a particular	executable, set	the QT4_NO_LINK_QTMAIN
	  target property to TRUE on the executable.

   Qt Build Tools
       Qt  relies  on  some bundled tools for code generation, such as moc for
       meta-object code	generation,``uic`` for widget layout  and  population,
       and  rcc	for virtual filesystem content generation.  These tools	may be
       automatically invoked by	cmake(1) if  the  appropriate  conditions  are
       met.  See cmake-qt(7) for more.

   Qt Macros
       In  some	 cases	it  can	 be necessary or useful	to invoke the Qt build
       tools in	a more-manual way. Several macros are available	to add targets
       for such	uses.

	  macro	QT4_WRAP_CPP(outfiles inputfile	... [TARGET tgt] OPTIONS ...)
		create moc code	from a list of files containing	Qt class with
		the Q_OBJECT declaration.  Per-directory preprocessor definitions
		are also added.	 If the	<tgt> is specified, the
		INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS	from
		the <tgt> are passed to	moc.  Options may be given to moc, such	as
		those found when executing "moc	-help".

	  macro	QT4_WRAP_UI(outfiles inputfile ... OPTIONS ...)
		create code from a list	of Qt designer ui files.
		Options	may be given to	uic, such as those found
		when executing "uic -help"

	  macro	QT4_ADD_RESOURCES(outfiles inputfile ... OPTIONS ...)
		create code from a list	of Qt resource files.
		Options	may be given to	rcc, such as those found
		when executing "rcc -help"

	  macro	QT4_GENERATE_MOC(inputfile outputfile [TARGET tgt])
		creates	a rule to run moc on infile and	create outfile.
		Use this if for	some reason QT4_WRAP_CPP() isn't appropriate, e.g.
		because	you need a custom filename for the moc file or something
		similar.  If the <tgt> is specified, the
		INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS	from
		the <tgt> are passed to	moc.

	  macro	QT4_ADD_DBUS_INTERFACE(outfiles	interface basename)
		Create the interface header and	implementation files with the
		given basename from the	given interface	xml file and add it to
		the list of sources.

		You can	pass additional	parameters to the qdbusxml2cpp call by setting
		properties on the input	file:

		INCLUDE	the given file will be included	in the generate	interface header

		CLASSNAME the generated	class is named accordingly

		NO_NAMESPACE the generated class is not	wrapped	in a namespace

	  macro	QT4_ADD_DBUS_INTERFACES(outfiles inputfile ... )
		Create the interface header and	implementation files
		for all	listed interface xml files.
		The basename will be automatically determined from the name
		of the xml file.

		The source file	properties described for
		QT4_ADD_DBUS_INTERFACE also apply here.

	  macro	QT4_ADD_DBUS_ADAPTOR(outfiles xmlfile parentheader parentclassname
				     [basename]	[classname])
		create a dbus adaptor (header and implementation file) from the	xml file
		describing the interface, and add it to	the list of sources. The adaptor
		forwards the calls to a	parent class, defined in parentheader and named
		parentclassname. The name of the generated files will be
		<basename>adaptor.{cpp,h} where	basename defaults to the basename of the
		xml file.
		If <classname> is provided, then it will be used as the	classname of the
		adaptor	itself.

	  macro	QT4_GENERATE_DBUS_INTERFACE( header [interfacename] OPTIONS ...)
		generate the xml interface file	from the given header.
		If the optional	argument interfacename is omitted, the name of the
		interface file is constructed from the basename	of the header with
		the suffix .xml	appended.
		Options	may be given to	qdbuscpp2xml, such as those found when
		executing "qdbuscpp2xml	--help"

	  macro	QT4_CREATE_TRANSLATION(	qm_files directories ... sources ...
					ts_files ... OPTIONS ...)
		out: qm_files
		in:  directories sources ts_files
		options: flags to pass to lupdate, such	as -extensions to specify
		extensions for a directory scan.
		generates commands to create .ts (via lupdate) and .qm
		(via lrelease) - files from directories	and/or sources.	The ts files are
		created	and/or updated in the source tree (unless given	with full paths).
		The qm files are generated in the build	tree.
		Updating the translations can be done by adding	the qm_files
		to the source list of your library/executable, so they are
		always updated,	or by adding a custom target to	control	when
		they get updated/generated.

	  macro	QT4_ADD_TRANSLATION( qm_files ts_files ... )
		out: qm_files
		in:  ts_files
		generates commands to create .qm from .ts - files. The generated
		filenames can be found in qm_files. The	ts_files
		must exist and are not updated in any way.

	  macro	QT4_AUTOMOC(sourcefile1	sourcefile2 ...	[TARGET	tgt])
		The qt4_automoc	macro is obsolete.  Use	the CMAKE_AUTOMOC feature instead.
		This macro is still experimental.
		It can be used to have moc automatically handled.
		So if you have the files foo.h and foo.cpp, and	in foo.h a
		a class	uses the Q_OBJECT macro, moc has to run	on it. If you don't
		want to	use QT4_WRAP_CPP() (which is reliable and mature), you can insert
		#include "foo.moc"
		in foo.cpp and then give foo.cpp as argument to	QT4_AUTOMOC(). This will
		scan all listed	files at cmake-time for	such included moc files	and if it
		finds them cause a rule	to be generated	to run moc at build time on the
		accompanying header file foo.h.
		If a source file has the SKIP_AUTOMOC property set it will be ignored by
		this macro.
		If the <tgt> is	specified, the INTERFACE_INCLUDE_DIRECTORIES and
		INTERFACE_COMPILE_DEFINITIONS from the <tgt> are passed	to moc.

	  function QT4_USE_MODULES( target [link_type] modules...)
		 This function is obsolete. Use	target_link_libraries with IMPORTED targets
		 instead.
		 Make <target> use the <modules> from Qt. Using	a Qt module means
		 to link to the	library, add the relevant include directories for the
		 module, and add the relevant compiler defines for using the module.
		 Modules are roughly equivalent	to components of Qt4, so usage would be
		 something like:
		  qt4_use_modules(myexe	Core Gui Declarative)
		 to use	QtCore,	QtGui and QtDeclarative. The optional <link_type> argument
		 can be	specified as either LINK_PUBLIC	or LINK_PRIVATE	to specify the
		 same argument to the target_link_libraries call.

   IMPORTED Targets
       A particular Qt library may be used by using the	corresponding IMPORTED
       target with the target_link_libraries() command:

	  target_link_libraries(myexe Qt4::QtGui Qt4::QtXml)

       Using a target in this way causes :cmake(1)` to use the appropriate in-
       clude directories and compile definitions for the target	when compiling
       myexe.

       Targets are aware of their dependencies,	so for example it is not  nec-
       essary  to  list	Qt4::QtCore if another Qt library is listed, and it is
       not necessary to	list Qt4::QtGui	if Qt4::QtDeclarative is listed.  Tar-
       gets  may  be tested for	existence in the usual way with	the if(TARGET)
       command.

       The Qt toolkit may contain both debug and release libraries.   cmake(1)
       will choose the appropriate version based on the	build configuration.

       Qt4::QtCore
	      The QtCore target

       Qt4::QtGui
	      The QtGui	target

       Qt4::Qt3Support
	      The Qt3Support target

       Qt4::QtAssistant
	      The QtAssistant target

       Qt4::QtAssistantClient
	      The QtAssistantClient target

       Qt4::QAxContainer
	      The QAxContainer target (Windows only)

       Qt4::QAxServer
	      The QAxServer target (Windows only)

       Qt4::QtDBus
	      The QtDBus target

       Qt4::QtDeclarative
	      The QtDeclarative	target

       Qt4::QtDesigner
	      The QtDesigner target

       Qt4::QtDesignerComponents
	      The QtDesignerComponents target

       Qt4::QtHelp
	      The QtHelp target

       Qt4::QtMotif
	      The QtMotif target

       Qt4::QtMultimedia
	      The QtMultimedia target

       Qt4::QtNetwork
	      The QtNetwork target

       Qt4::QtNsPLugin
	      The QtNsPLugin target

       Qt4::QtOpenGL
	      The QtOpenGL target

       Qt4::QtScript
	      The QtScript target

       Qt4::QtScriptTools
	      The QtScriptTools	target

       Qt4::QtSql
	      The QtSql	target

       Qt4::QtSvg
	      The QtSvg	target

       Qt4::QtTest
	      The QtTest target

       Qt4::QtUiTools
	      The QtUiTools target

       Qt4::QtWebKit
	      The QtWebKit target

       Qt4::QtXml
	      The QtXml	target

       Qt4::QtXmlPatterns
	      The QtXmlPatterns	target

       Qt4::phonon
	      The phonon target

   Result Variables
	  Below	is a detailed list of variables	that FindQt4.cmake sets.

       Qt4_FOUND
	      If false,	don't try to use Qt 4.

       QT_FOUND
	      If  false, don't try to use Qt. This variable is for compatibil-
	      ity only.

       QT4_FOUND
	      If false,	don't try to use Qt 4. This variable is	 for  compati-
	      bility only.

       QT_VERSION_MAJOR
	      The major	version	of Qt found.

       QT_VERSION_MINOR
	      The minor	version	of Qt found.

       QT_VERSION_PATCH
	      The patch	version	of Qt found.

   FindQuickTime
       Locate QuickTime	This module defines QUICKTIME_LIBRARY QUICKTIME_FOUND,
       if false, do not	try to link to gdal  QUICKTIME_INCLUDE_DIR,  where  to
       find the	headers

       $QUICKTIME_DIR  is an environment variable that would correspond	to the
       ./configure --prefix=$QUICKTIME_DIR

       Created by Eric Wing.

   FindRTI
       Try to find M&S HLA RTI libraries

       This module finds if any	HLA RTI	is installed and locates the  standard
       RTI include files and libraries.

       RTI  is	a simulation infrastructure standardized by IEEE and SISO.  It
       has a well defined C++ API that assures	that  simulation  applications
       are independent on a particular RTI implementation.

	  http://en.wikipedia.org/wiki/Run-Time_Infrastructure_(simulation)

       This code sets the following variables:

	  RTI_INCLUDE_DIR = the	directory where	RTI includes file are found
	  RTI_LIBRARIES	= The libraries	to link	against	to use RTI
	  RTI_DEFINITIONS = -DRTI_USES_STD_FSTREAM
	  RTI_FOUND = Set to FALSE if any HLA RTI was not found

       Report problems to <certi-devel@nongnu.org>

   FindRuby
       Find Ruby

       This module finds if Ruby is installed and determines where the include
       files and libraries are.	 Ruby 1.8 through 2.7 are supported.

       The minimum required version of Ruby can	be specified using  the	 stan-
       dard syntax, e.g.

	  find_package(Ruby 2.5.1 EXACT	REQUIRED)
	  # OR
	  find_package(Ruby 2.4)

       It also determines what the name	of the library is.

       Virtual	environments  such  as RVM are handled as well,	by passing the
       argument	Ruby_FIND_VIRTUALENV

   Result Variables
       This module will	set the	following variables in your project:

       Ruby_FOUND
	      set to true if ruby was found successfully

       Ruby_EXECUTABLE
	      full path	to the ruby binary

       Ruby_INCLUDE_DIRS
	      include dirs to be used when using the ruby library

       Ruby_LIBRARIES
	      New in version 3.18: libraries needed to use ruby	from C.

       Ruby_VERSION
	      the version of ruby which	was found, e.g.	"1.8.7"

       Ruby_VERSION_MAJOR
	      Ruby major version.

       Ruby_VERSION_MINOR
	      Ruby minor version.

       Ruby_VERSION_PATCH
	      Ruby patch version.

       Changed in version 3.18:	Previous versions of CMake used	the RUBY_ pre-
       fix  for	 all variables.	 The following variables are provided for com-
       patibility reasons, don't use them in new code:

       RUBY_EXECUTABLE
	      same as Ruby_EXECUTABLE.

       RUBY_INCLUDE_DIRS
	      same as Ruby_INCLUDE_DIRS.

       RUBY_INCLUDE_PATH
	      same as Ruby_INCLUDE_DIRS.

       RUBY_LIBRARY
	      same as Ruby_LIBRARY.

       RUBY_VERSION
	      same as Ruby_VERSION.

       RUBY_FOUND
	      same as Ruby_FOUND.

   Hints
       New in version 3.18.

       Ruby_ROOT_DIR
	      Define the root directory	of a Ruby installation.

       Ruby_FIND_VIRTUALENV
	      This variable defines the	handling of virtual environments  man-
	      aged by rvm. It is meaningful only when a	virtual	environment is
	      active (i.e. the rvm script has been evaluated or	at  least  the
	      MY_RUBY_HOME  environment	 variable is set).  The	Ruby_FIND_VIR-
	      TUALENV variable can be set to empty or one of the following:

	      o	FIRST: The virtual environment is used before any other	 stan-
		dard  paths  to	 look-up  for the interpreter. This is the de-
		fault.

	      o	ONLY: Only the virtual environment is used to look-up for  the
		interpreter.

	      o	STANDARD:  The	virtual	environment is not used	to look-up for
		the interpreter	(assuming it isn't still in the	PATH...)

   FindSDL
       Locate the SDL library

   Imported targets
       New in version 3.19.

       This module defines the following IMPORTED target:

       SDL::SDL
	      The SDL library, if found

   Result variables
       This module will	set the	following variables in your project:

       SDL_INCLUDE_DIRS
	      where to find SDL.h

       SDL_LIBRARIES
	      the name of the library to link against

       SDL_FOUND
	      if false,	do not try to link to SDL

       SDL_VERSION
	      the human-readable string	containing the version of SDL if found

       SDL_VERSION_MAJOR
	      SDL major	version

       SDL_VERSION_MINOR
	      SDL minor	version

       SDL_VERSION_PATCH
	      SDL patch	version

       New in version 3.19:  Added  the	 SDL_INCLUDE_DIRS,  SDL_LIBRARIES  and
       SDL_VERSION[_<PART>] variables.

   Cache variables
       These variables may optionally be set to	help this module find the cor-
       rect files:

       SDL_INCLUDE_DIR
	      where to find SDL.h

       SDL_LIBRARY
	      the name of the library to link against

   Variables for locating SDL
       This module responds to the flag:

       SDL_BUILDING_LIBRARY
	      If this is defined, then no SDL_main will	be linked  in  because
	      only applications	need main().  Otherwise, it is assumed you are
	      building an application and this module will attempt  to	locate
	      and  set	the  proper link flags as part of the returned SDL_LI-
	      BRARY variable.

   Obsolete variables
       Deprecated since	version	3.19.

       These variables are obsolete and	provided for backwards compatibility:

       SDL_VERSION_STRING
	      the human-readable string	 containing  the  version  of  SDL  if
	      found.  Identical	to SDL_VERSION

       Don't forget to include SDLmain.h and SDLmain.m your project for	the OS
       X framework based version.  (Other versions  link  to  -lSDLmain	 which
       this  module will try to	find on	your behalf.) Also for OS X, this mod-
       ule will	automatically add the -framework Cocoa on your behalf.

       Additional Note:	If you see an empty SDL_LIBRARY_TEMP in	your  configu-
       ration and no SDL_LIBRARY, it means CMake did not find your SDL library
       (SDL.dll, libsdl.so,  SDL.framework,  etc).   Set  SDL_LIBRARY_TEMP  to
       point  to your SDL library, and configure again.	 Similarly, if you see
       an empty	SDLMAIN_LIBRARY, you should set	 this  value  as  appropriate.
       These  values  are used to generate the final SDL_LIBRARY variable, but
       when these values are unset, SDL_LIBRARY	does not get created.

       $SDLDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$SDLDIR used in building	SDL.  l.e.galup	9-20-02

       On  OSX,	this will prefer the Framework version (if found) over others.
       People will have	to manually change the cache values of SDL_LIBRARY  to
       override	this selection or set the CMake	environment CMAKE_INCLUDE_PATH
       to modify the search paths.

       Note that the header path has changed from SDL/SDL.h to just SDL.h This
       needed  to  change because "proper" SDL convention is #include "SDL.h",
       not <SDL/SDL.h>.	 This is done for portability reasons because not  all
       systems place things in SDL/ (see FreeBSD).

   FindSDL_image
       Locate SDL_image	library

       This module defines:

	  SDL_IMAGE_LIBRARIES, the name	of the library to link against
	  SDL_IMAGE_INCLUDE_DIRS, where	to find	the headers
	  SDL_IMAGE_FOUND, if false, do	not try	to link	against
	  SDL_IMAGE_VERSION_STRING - human-readable string containing the
				     version of	SDL_image

       For backward compatibility the following	variables are also set:

	  SDLIMAGE_LIBRARY (same value as SDL_IMAGE_LIBRARIES)
	  SDLIMAGE_INCLUDE_DIR (same value as SDL_IMAGE_INCLUDE_DIRS)
	  SDLIMAGE_FOUND (same value as	SDL_IMAGE_FOUND)

       $SDLDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$SDLDIR used in building	SDL.

       Created by Eric Wing.  This was influenced by the FindSDL.cmake module,
       but with	modifications to recognize OS X	frameworks and additional Unix
       paths (FreeBSD, etc).

   FindSDL_mixer
       Locate SDL_mixer	library

       This module defines:

	  SDL_MIXER_LIBRARIES, the name	of the library to link against
	  SDL_MIXER_INCLUDE_DIRS, where	to find	the headers
	  SDL_MIXER_FOUND, if false, do	not try	to link	against
	  SDL_MIXER_VERSION_STRING - human-readable string containing the
				     version of	SDL_mixer

       For backward compatibility the following	variables are also set:

	  SDLMIXER_LIBRARY (same value as SDL_MIXER_LIBRARIES)
	  SDLMIXER_INCLUDE_DIR (same value as SDL_MIXER_INCLUDE_DIRS)
	  SDLMIXER_FOUND (same value as	SDL_MIXER_FOUND)

       $SDLDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$SDLDIR used in building	SDL.

       Created by Eric Wing.  This was influenced by the FindSDL.cmake module,
       but with	modifications to recognize OS X	frameworks and additional Unix
       paths (FreeBSD, etc).

   FindSDL_net
       Locate SDL_net library

       This module defines:

	  SDL_NET_LIBRARIES, the name of the library to	link against
	  SDL_NET_INCLUDE_DIRS,	where to find the headers
	  SDL_NET_FOUND, if false, do not try to link against
	  SDL_NET_VERSION_STRING - human-readable string containing the	version	of SDL_net

       For backward compatibility the following	variables are also set:

	  SDLNET_LIBRARY (same value as	SDL_NET_LIBRARIES)
	  SDLNET_INCLUDE_DIR (same value as SDL_NET_INCLUDE_DIRS)
	  SDLNET_FOUND (same value as SDL_NET_FOUND)

       $SDLDIR	is an environment variable that	would correspond to the	./con-
       figure --prefix=$SDLDIR used in building	SDL.

       Created by Eric Wing.  This was influenced by the FindSDL.cmake module,
       but with	modifications to recognize OS X	frameworks and additional Unix
       paths (FreeBSD, etc).

   FindSDL_sound
       Locates the SDL_sound library

       This module depends on SDL being	found and must be called  AFTER	 Find-
       SDL.cmake is called.

       This module defines

	  SDL_SOUND_INCLUDE_DIR, where to find SDL_sound.h
	  SDL_SOUND_FOUND, if false, do	not try	to link	to SDL_sound
	  SDL_SOUND_LIBRARIES, this contains the list of libraries that	you need
	    to link against.
	  SDL_SOUND_EXTRAS, this is an optional	variable for you to add	your own
	    flags to SDL_SOUND_LIBRARIES. This is prepended to SDL_SOUND_LIBRARIES.
	    This is available mostly for cases this module failed to anticipate	for
	    and	you must add additional	flags. This is marked as ADVANCED.
	  SDL_SOUND_VERSION_STRING, human-readable string containing the
	    version of SDL_sound

       This module also	defines	(but you shouldn't need	to use directly)

	  SDL_SOUND_LIBRARY, the name of just the SDL_sound library you	would link
	  against. Use SDL_SOUND_LIBRARIES for you link	instructions and not this one.

       And might define	the following as needed

	  MIKMOD_LIBRARY
	  MODPLUG_LIBRARY
	  OGG_LIBRARY
	  VORBIS_LIBRARY
	  SMPEG_LIBRARY
	  FLAC_LIBRARY
	  SPEEX_LIBRARY

       Typically,  you should not use these variables directly,	and you	should
       use SDL_SOUND_LIBRARIES which contains SDL_SOUND_LIBRARY	and the	 other
       audio libraries (if needed) to successfully compile on your system.

       Created	by  Eric Wing.	This module is a bit more complicated than the
       other FindSDL* family modules.  The reason is  that  SDL_sound  can  be
       compiled	 in a large variety of different ways which are	independent of
       platform.  SDL_sound may	dynamically link against other 3rd  party  li-
       braries	to  get	 additional  codec support, such as Ogg	Vorbis,	SMPEG,
       ModPlug,	MikMod,	FLAC, Speex, and potentially others.  Under some  cir-
       cumstances which	I don't	fully understand, there	seems to be a require-
       ment that dependent libraries of	libraries you use must also be explic-
       itly  linked  against in	order to successfully compile.	SDL_sound does
       not currently have any system in	place to know how it was compiled.  So
       this  CMake  module  does the hard work in trying to discover which 3rd
       party libraries are required for	building (if any).  This module	uses a
       brute  force approach to	create a test program that uses	SDL_sound, and
       then tries to build it.	If the build fails, it parses the error	output
       for known symbol	names to figure	out which libraries are	needed.

       Responds	 to  the  $SDLDIR and $SDLSOUNDDIR environmental variable that
       would correspond	to the ./configure --prefix=$SDLDIR used  in  building
       SDL.

       On  OSX,	this will prefer the Framework version (if found) over others.
       People will have	to manually change the cache values of SDL_LIBRARY  to
       override	 this selectionor set the CMake	environment CMAKE_INCLUDE_PATH
       to modify the search paths.

   FindSDL_ttf
       Locate SDL_ttf library

       This module defines:

	  SDL_TTF_LIBRARIES, the name of the library to	link against
	  SDL_TTF_INCLUDE_DIRS,	where to find the headers
	  SDL_TTF_FOUND, if false, do not try to link against
	  SDL_TTF_VERSION_STRING - human-readable string containing the	version	of SDL_ttf

       For backward compatibility the following	variables are also set:

	  SDLTTF_LIBRARY (same value as	SDL_TTF_LIBRARIES)
	  SDLTTF_INCLUDE_DIR (same value as SDL_TTF_INCLUDE_DIRS)
	  SDLTTF_FOUND (same value as SDL_TTF_FOUND)

       $SDLDIR is an environment variable that would correspond	to the	./con-
       figure --prefix=$SDLDIR used in building	SDL.

       Created by Eric Wing.  This was influenced by the FindSDL.cmake module,
       but with	modifications to recognize OS X	frameworks and additional Unix
       paths (FreeBSD, etc).

   FindSelfPackers
       Find upx

       This module looks for some executable packers (i.e.  software that com-
       press executables or shared libs	into on-the-fly	 self-extracting  exe-
       cutables	or shared libs.	 Examples:

	  UPX: http://wildsau.idv.uni-linz.ac.at/mfx/upx.html

   FindSquish
       -- Typical Use

       This module can be used to find Squish.

	  SQUISH_FOUND			  If false, don't try to use Squish
	  SQUISH_VERSION		  The full version of Squish found
	  SQUISH_VERSION_MAJOR		  The major version of Squish found
	  SQUISH_VERSION_MINOR		  The minor version of Squish found
	  SQUISH_VERSION_PATCH		  The patch version of Squish found

	  SQUISH_INSTALL_DIR		  The Squish installation directory
					  (containing bin, lib,	etc)
	  SQUISH_SERVER_EXECUTABLE	  The squishserver executable
	  SQUISH_CLIENT_EXECUTABLE	  The squishrunner executable

	  SQUISH_INSTALL_DIR_FOUND	  Was the install directory found?
	  SQUISH_SERVER_EXECUTABLE_FOUND  Was the server executable found?
	  SQUISH_CLIENT_EXECUTABLE_FOUND  Was the client executable found?

       It  provides the	function squish_add_test() for adding a	squish test to
       cmake using Squish >= 4.x:

	  squish_add_test(cmakeTestName
	    AUT	targetName SUITE suiteName TEST	squishTestName
	    [SETTINGSGROUP group] [PRE_COMMAND command]	[POST_COMMAND command] )

       Changed in version 3.18:	In previous CMake versions, this function  was
       named squish_v4_add_test.

       The arguments have the following	meaning:

       cmakeTestName
	      this will	be used	as the first argument for add_test()

       AUT targetName
	      the name of the cmake target which will be used as AUT, i.e. the
	      executable which will be tested.

       SUITE suiteName
	      this is either the full path to the squish suite,	 or  just  the
	      last  directory  of the suite, i.e. the suite name. In this case
	      the CMakeLists.txt which calls squish_add_test() must be located
	      in the parent directory of the suite directory.

       TEST squishTestName
	      the  name	 of the	squish test, i.e. the name of the subdirectory
	      of the test inside the suite directory.

       SETTINGSGROUP group
	      deprecated, this argument	will be	ignored.

       PRE_COMMAND command
	      if specified, the	given command will be executed before starting
	      the squish test.

       POST_COMMAND command
	      same  as	PRE_COMMAND,  but  after the squish test has been exe-
	      cuted.

	  enable_testing()
	  find_package(Squish 6.5)
	  if (SQUISH_FOUND)
	     squish_add_test(myTestName
	       AUT myApp
	       SUITE ${CMAKE_SOURCE_DIR}/tests/mySuite
	       TEST someSquishTest
	       )
	  endif	()

       For users of Squish version 3.x the macro squish_v3_add_test() is  pro-
       vided:

	  squish_v3_add_test(testName applicationUnderTest testCase envVars testWrapper)
	  Use this macro to add	a test using Squish 3.x.

	  enable_testing()
	  find_package(Squish 3.0)
	  if (SQUISH_FOUND)
	    squish_v3_add_test(myTestName myApplication	testCase envVars testWrapper)
	  endif	()

   FindSQLite3
       New in version 3.14.

       Find the	SQLite libraries, v3

   IMPORTED targets
       This module defines the following IMPORTED target:

       SQLite::SQLite3

   Result variables
       This module will	set the	following variables if found:

       SQLite3_INCLUDE_DIRS
	      where to find sqlite3.h, etc.

       SQLite3_LIBRARIES
	      the libraries to link against to use SQLite3.

       SQLite3_VERSION
	      version of the SQLite3 library found

       SQLite3_FOUND
	      TRUE if found

   FindSubversion
       Extract information from	a subversion working copy

       The module defines the following	variables:

	  Subversion_SVN_EXECUTABLE - path to svn command line client
	  Subversion_VERSION_SVN - version of svn command line client
	  Subversion_FOUND - true if the command line client was found
	  SUBVERSION_FOUND - same as Subversion_FOUND, set for compatibility reasons

       The  minimum  required version of Subversion can	be specified using the
       standard	syntax,	e.g. find_package(Subversion 1.4).

       If the command line client executable is	found two macros are defined:

	  Subversion_WC_INFO(<dir> <var-prefix>	[IGNORE_SVN_FAILURE])
	  Subversion_WC_LOG(<dir> <var-prefix>)

       Subversion_WC_INFO extracts information of a subversion working copy at
       a  given	 location.  This macro defines the following variables if run-
       ning Subversion's info command on <dir> succeeds; otherwise a  SEND_ER-
       ROR message is generated.

       New  in	version	 3.13:	The  error can be ignored by providing the IG-
       NORE_SVN_FAILURE	option,	which causes these variables to	 remain	 unde-
       fined.

	  <var-prefix>_WC_URL -	url of the repository (at <dir>)
	  <var-prefix>_WC_ROOT - root url of the repository
	  <var-prefix>_WC_REVISION - current revision
	  <var-prefix>_WC_LAST_CHANGED_AUTHOR -	author of last commit
	  <var-prefix>_WC_LAST_CHANGED_DATE - date of last commit
	  <var-prefix>_WC_LAST_CHANGED_REV - revision of last commit
	  <var-prefix>_WC_INFO - output	of command `svn	info <dir>'

       Subversion_WC_LOG  retrieves  the log message of	the base revision of a
       subversion working copy at a given location.  This  macro  defines  the
       variable:

	  <var-prefix>_LAST_CHANGED_LOG	- last log of base revision

       Example usage:

	  find_package(Subversion)
	  if(SUBVERSION_FOUND)
	    Subversion_WC_INFO(${PROJECT_SOURCE_DIR} Project)
	    message("Current revision is ${Project_WC_REVISION}")
	    Subversion_WC_LOG(${PROJECT_SOURCE_DIR} Project)
	    message("Last changed log is ${Project_LAST_CHANGED_LOG}")
	  endif()

   FindSWIG
       Find the	Simplified Wrapper and Interface Generator (SWIG) executable.

       This module finds an installed SWIG and determines its version.

       New in version 3.18: If a COMPONENTS or OPTIONAL_COMPONENTS argument is
       given to	the find_package() command, it will also  determine  supported
       target languages.

       New  in	version	3.19: When a version is	requested, it can be specified
       as a simple value or as a range.	For a detailed description of  version
       range usage and capabilities, refer to the find_package() command.

       The module defines the following	variables:

       SWIG_FOUND
	      Whether  SWIG and	any required components	were found on the sys-
	      tem.

       SWIG_EXECUTABLE
	      Path to the SWIG executable.

       SWIG_DIR
	      Path to  the  installed  SWIG  Lib  directory  (result  of  swig
	      -swiglib).

       SWIG_VERSION
	      SWIG executable version (result of swig -version).

       SWIG_<lang>_FOUND
	      If  COMPONENTS or	OPTIONAL_COMPONENTS are	requested, each	avail-
	      able target language <lang> (lowercase) will be set to TRUE.

       Any COMPONENTS given to find_package should be the names	 of  supported
       target  languages  as provided to the LANGUAGE argument of swig_add_li-
       brary, such as python or	perl5. Language	names must be lowercase.

       All information is collected from the SWIG_EXECUTABLE, so  the  version
       to  be  found  can be changed from the command line by means of setting
       SWIG_EXECUTABLE.

       Example usage requiring SWIG 4.0	or higher and Python language support,
       with optional Fortran support:

	  find_package(SWIG 4.0	COMPONENTS python OPTIONAL_COMPONENTS fortran)
	  if(SWIG_FOUND)
	    message("SWIG found: ${SWIG_EXECUTABLE}")
	    if(NOT SWIG_fortran_FOUND)
	      message(WARNING "SWIG Fortran bindings cannot be generated")
	    endif()
	  endif()

   FindTCL
       TK_INTERNAL_PATH	was removed.

       This  module finds if Tcl is installed and determines where the include
       files and libraries are.	 It also determines what the name of  the  li-
       brary is.  This code sets the following variables:

	  TCL_FOUND		 = Tcl was found
	  TK_FOUND		 = Tk was found
	  TCLTK_FOUND		 = Tcl and Tk were found
	  TCL_LIBRARY		 = path	to Tcl library (tcl tcl80)
	  TCL_INCLUDE_PATH	 = path	to where tcl.h can be found
	  TCL_TCLSH		 = path	to tclsh binary	(tcl tcl80)
	  TK_LIBRARY		 = path	to Tk library (tk tk80 etc)
	  TK_INCLUDE_PATH	 = path	to where tk.h can be found
	  TK_WISH		 = full	path to	the wish executable

       In an effort to remove some clutter and clear up	some issues for	people
       who are not necessarily Tcl/Tk gurus/developers,	 some  variables  were
       moved or	removed.  Changes compared to CMake 2.4	are:

	  => they were only useful for people writing Tcl/Tk extensions.
	  => these libs	are not	packaged by default with Tcl/Tk	distributions.
	     Even when Tcl/Tk is built from source, several flavors of debug libs
	     are created and there is no real reason to	pick a single one
	     specifically (say,	amongst	tcl84g,	tcl84gs, or tcl84sgx).
	     Let's leave that choice to	the user by allowing him to assign
	     TCL_LIBRARY to any	Tcl library, debug or not.
	  => this ended	up being only a	Win32 variable,	and there is a lot of
	     confusion regarding the location of this file in an installed Tcl/Tk
	     tree anyway (see 8.5 for example).	If you need the	internal path at
	     this point	it is safer you	ask directly where the *source*	tree is
	     and dig from there.

   FindTclsh
       Find tclsh

       This  module finds if TCL is installed and determines where the include
       files and libraries are.	 It also determines what the name of  the  li-
       brary is.  This code sets the following variables:

	  TCLSH_FOUND =	TRUE if	tclsh has been found
	  TCL_TCLSH = the path to the tclsh executable

   FindTclStub
       TCL_STUB_LIBRARY_DEBUG and TK_STUB_LIBRARY_DEBUG	were removed.

       This module finds Tcl stub libraries.  It first finds Tcl include files
       and libraries by	calling	FindTCL.cmake.	How to Use the Tcl  Stubs  Li-
       brary:

	  http://tcl.activestate.com/doc/howto/stubs.html

       Using Stub Libraries:

	  http://safari.oreilly.com/0130385603/ch48lev1sec3

       This code sets the following variables:

	  TCL_STUB_LIBRARY	 = path	to Tcl stub library
	  TK_STUB_LIBRARY	 = path	to Tk stub library
	  TTK_STUB_LIBRARY	 = path	to ttk stub library

       In an effort to remove some clutter and clear up	some issues for	people
       who are not necessarily Tcl/Tk gurus/developers,	 some  variables  were
       moved or	removed.  Changes compared to CMake 2.4	are:

	  => these libs	are not	packaged by default with Tcl/Tk	distributions.
	     Even when Tcl/Tk is built from source, several flavors of debug libs
	     are created and there is no real reason to	pick a single one
	     specifically (say,	amongst	tclstub84g, tclstub84gs, or tclstub84sgx).
	     Let's leave that choice to	the user by allowing him to assign
	     TCL_STUB_LIBRARY to any Tcl library, debug	or not.

   FindThreads
       This module determines the thread library of the	system.

   Imported Targets
       New in version 3.1.

       This module defines the following IMPORTED target:

       Threads::Threads
	      The thread library, if found.

   Result Variables
       The following variables are set:

       Threads_FOUND
	      If a supported thread library was	found.

       CMAKE_THREAD_LIBS_INIT
	      The thread library to use. This may be empty if the thread func-
	      tions are	provided by the	system libraries and no	special	 flags
	      are needed to use	them.

       CMAKE_USE_WIN32_THREADS_INIT
	      If the found thread library is the win32 one.

       CMAKE_USE_PTHREADS_INIT
	      If the found thread library is pthread compatible.

       CMAKE_HP_PTHREADS_INIT
	      If the found thread library is the HP thread library.

   Variables Affecting Behavior
       THREADS_PREFER_PTHREAD_FLAG
	      New in version 3.1.

	      If the use of the	-pthread compiler and linker flag is preferred
	      then the caller can set this variable to TRUE. The compiler flag
	      can  only	 be used with the imported target. Use of both the im-
	      ported target as well as this switch is highly  recommended  for
	      new code.

	      This  variable has no effect if the system libraries provide the
	      thread  functions,  i.e.	when  CMAKE_THREAD_LIBS_INIT  will  be
	      empty.

   FindTIFF
       Find the	TIFF library (libtiff, https://libtiff.gitlab.io/libtiff/).

   Optional COMPONENTS
       This  module supports the optional component CXX, for use with the COM-
       PONENTS argument	of the find_package() command. This component  has  an
       associated imported target, as described	below.

   Imported targets
       New in version 3.5.

       This module defines the following IMPORTED targets:

       TIFF::TIFF
	      The TIFF library,	if found.

       TIFF::CXX
	      New in version 3.19.

	      The  C++	wrapper	 libtiffxx, if requested by the	COMPONENTS CXX
	      option, if the compiler is not  MSVC  (which  includes  the  C++
	      wrapper in libtiff), and if found.

   Result variables
       This module will	set the	following variables in your project:

       TIFF_FOUND
	      true if the TIFF headers and libraries were found

       TIFF_INCLUDE_DIR
	      the directory containing the TIFF	headers

       TIFF_INCLUDE_DIRS
	      the directory containing the TIFF	headers

       TIFF_LIBRARIES
	      TIFF libraries to	be linked

   Cache variables
       The following cache variables may also be set:

       TIFF_INCLUDE_DIR
	      the directory containing the TIFF	headers

       TIFF_LIBRARY_RELEASE
	      the path to the TIFF library for release configurations

       TIFF_LIBRARY_DEBUG
	      the path to the TIFF library for debug configurations

       TIFFXX_LIBRARY_RELEASE
	      the path to the TIFFXX library for release configurations

       TIFFXX_LIBRARY_DEBUG
	      the path to the TIFFXX library for debug configurations

       New in version 3.4: Debug and Release variants are found	separately.

   FindUnixCommands
       Find Unix commands, including the ones from Cygwin

       This module looks for the Unix commands bash, cp, gzip, mv, rm, and tar
       and stores the result in	the variables BASH, CP,	GZIP, MV, RM, and TAR.

   FindVTK
       This module no longer exists.

       This module existed in versions of CMake	prior to 3.1, but became  only
       a  thin	wrapper	around find_package(VTK	NO_MODULE) to provide compati-
       bility for projects using long-outdated	conventions.   Now  find_pack-
       age(VTK)	will search for	VTKConfig.cmake	directly.

   FindVulkan
       New in version 3.7.

       Find  Vulkan,  which  is	a low-overhead,	cross-platform 3D graphics and
       computing API.

   IMPORTED Targets
       This module defines IMPORTED target Vulkan::Vulkan, if Vulkan has  been
       found.

       New in version 3.19: This module	defines	IMPORTED target	Vulkan::glslc,
       if Vulkan and the GLSLC SPIR-V compiler has been	found.

   Result Variables
       This module defines the following variables:

	  Vulkan_FOUND		- "True" if Vulkan was found
	  Vulkan_INCLUDE_DIRS	- include directories for Vulkan
	  Vulkan_LIBRARIES	- link against this library to use Vulkan

       The module will also define three cache variables:

	  Vulkan_INCLUDE_DIR	    - the Vulkan include directory
	  Vulkan_LIBRARY	    - the path to the Vulkan library
	  Vulkan_GLSLC_EXECUTABLE   - the path to the GLSL SPIR-V compiler

   Hints
       New in version 3.18.

       The VULKAN_SDK environment variable optionally specifies	 the  location
       of the Vulkan SDK root directory	for the	given architecture. It is typ-
       ically set by sourcing the toplevel setup-env.sh	script of  the	Vulkan
       SDK directory into the shell environment.

   FindWget
       Find wget

       This module looks for wget.  This module	defines	the following values:

	  WGET_EXECUTABLE: the full path to the	wget tool.
	  WGET_FOUND: True if wget has been found.

   FindWish
       Find wish installation

       This  module finds if TCL is installed and determines where the include
       files and libraries are.	 It also determines what the name of  the  li-
       brary is.  This code sets the following variables:

	  TK_WISH = the	path to	the wish executable

       if UNIX is defined, then	it will	look for the cygwin version first

   FindwxWidgets
       Find a wxWidgets	(a.k.a., wxWindows) installation.

       This  module finds if wxWidgets is installed and	selects	a default con-
       figuration to use.  wxWidgets is	a modular  library.   To  specify  the
       modules	that  you will use, you	need to	name them as components	to the
       package:

       find_package(wxWidgets COMPONENTS core base ... OPTIONAL_COMPONENTS net
       ...)

       New  in	version	3.4: Support for find_package()	version	argument; web-
       view component.

       New in version 3.14: OPTIONAL_COMPONENTS	support.

       There are two search branches: a	windows	style and a unix  style.   For
       windows,	 the  following	variables are searched for and set to defaults
       in case of multiple choices.  Change them if the	defaults are  not  de-
       sired (i.e., these are the only variables you should change to select a
       configuration):

	  wxWidgets_ROOT_DIR	  - Base wxWidgets directory
				    (e.g., C:/wxWidgets-2.6.3).
	  wxWidgets_LIB_DIR	  - Path to wxWidgets libraries
				    (e.g., C:/wxWidgets-2.6.3/lib/vc_lib).
	  wxWidgets_CONFIGURATION - Configuration to use
				    (e.g., msw,	mswd, mswu, mswunivud, etc.)
	  wxWidgets_EXCLUDE_COMMON_LIBRARIES
				  - Set	to TRUE	to exclude linking of
				    commonly required libs (e.g., png tiff
				    jpeg zlib regex expat).

       For unix	style it uses the wx-config utility.  You can  select  between
       debug/release, unicode/ansi, universal/non-universal, and static/shared
       in the QtDialog or ccmake interfaces by turning	ON/OFF	the  following
       variables:

	  wxWidgets_USE_DEBUG
	  wxWidgets_USE_UNICODE
	  wxWidgets_USE_UNIVERSAL
	  wxWidgets_USE_STATIC

       There is	also a wxWidgets_CONFIG_OPTIONS	variable for all other options
       that need to be passed to the wx-config utility.	 For example,  to  use
       the base	toolkit	found in the /usr/local	path, set the variable (before
       calling the FIND_PACKAGE	command) as such:

	  set(wxWidgets_CONFIG_OPTIONS --toolkit=base --prefix=/usr)

       The following are set after the configuration is	done for both  windows
       and unix	style:

	  wxWidgets_FOUND	     - Set to TRUE if wxWidgets	was found.
	  wxWidgets_INCLUDE_DIRS     - Include directories for WIN32
				       i.e., where to find "wx/wx.h" and
				       "wx/setup.h"; possibly empty for	unices.
	  wxWidgets_LIBRARIES	     - Path to the wxWidgets libraries.
	  wxWidgets_LIBRARY_DIRS     - compile time link dirs, useful for
				       rpath on	UNIX. Typically	an empty string
				       in WIN32	environment.
	  wxWidgets_DEFINITIONS	     - Contains	defines	required to compile/link
				       against WX, e.g.	WXUSINGDLL
	  wxWidgets_DEFINITIONS_DEBUG- Contains	defines	required to compile/link
				       against WX debug	builds,	e.g. __WXDEBUG__
	  wxWidgets_CXX_FLAGS	     - Include dirs and	compiler flags for
				       unices, empty on	WIN32. Essentially
				       "`wx-config --cxxflags`".
	  wxWidgets_USE_FILE	     - Convenience include file.

       New in version 3.11: The	following environment variables	can be used as
       hints: WX_CONFIG, WXRC_CMD.

       Sample usage:

	  # Note that for MinGW	users the order	of libs	is important!
	  find_package(wxWidgets COMPONENTS gl core base OPTIONAL_COMPONENTS net)
	  if(wxWidgets_FOUND)
	    include(${wxWidgets_USE_FILE})
	    # and for each of your dependent executable/library	targets:
	    target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})
	  endif()

       If wxWidgets is required	(i.e., not an optional part):

	  find_package(wxWidgets REQUIRED gl core base OPTIONAL_COMPONENTS net)
	  include(${wxWidgets_USE_FILE})
	  # and	for each of your dependent executable/library targets:
	  target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})

   FindX11
       Find X11	installation

       Try to find X11 on UNIX systems.	The following values are defined

	  X11_FOUND	   - True if X11 is available
	  X11_INCLUDE_DIR  - include directories to use	X11
	  X11_LIBRARIES	   - link against these	to use X11

       and also	the following more fine	grained	variables and targets:

       New in version 3.14: Imported targets.

	  X11_ICE_INCLUDE_PATH,		 X11_ICE_LIB,	     X11_ICE_FOUND,	   X11::ICE
	  X11_SM_INCLUDE_PATH,		 X11_SM_LIB,	     X11_SM_FOUND,	   X11::SM
	  X11_X11_INCLUDE_PATH,		 X11_X11_LIB,				   X11::X11
	  X11_Xaccessrules_INCLUDE_PATH,
	  X11_Xaccessstr_INCLUDE_PATH,			     X11_Xaccess_FOUND
	  X11_Xau_INCLUDE_PATH,		 X11_Xau_LIB,	     X11_Xau_FOUND,	   X11::Xau
	  X11_xcb_INCLUDE_PATH,		 X11_xcb_LIB,	     X11_xcb_FOUND,	   X11::xcb
	  X11_X11_xcb_INCLUDE_PATH,	 X11_X11_xcb_LIB,    X11_X11_xcb_FOUND,	   X11::X11_xcb
	  X11_xcb_icccm_INCLUDE_PATH,	 X11_xcb_icccm_LIB,  X11_xcb_icccm_FOUND,  X11::xcb_icccm
	  X11_xcb_util_INCLUDE_PATH,	 X11_xcb_util_LIB,   X11_xcb_util_FOUND,   X11::xcb_util
	  X11_xcb_xfixes_INCLUDE_PATH,	 X11_xcb_xfixes_LIB, X11_xcb_xfixes_FOUND, X11::xcb_xfixes
	  X11_xcb_xkb_INCLUDE_PATH,	 X11_xcb_xkb_LIB,    X11_xcb_xkb_FOUND,	   X11::xcb_xkb
	  X11_Xcomposite_INCLUDE_PATH,	 X11_Xcomposite_LIB, X11_Xcomposite_FOUND, X11::Xcomposite
	  X11_Xcursor_INCLUDE_PATH,	 X11_Xcursor_LIB,    X11_Xcursor_FOUND,	   X11::Xcursor
	  X11_Xdamage_INCLUDE_PATH,	 X11_Xdamage_LIB,    X11_Xdamage_FOUND,	   X11::Xdamage
	  X11_Xdmcp_INCLUDE_PATH,	 X11_Xdmcp_LIB,	     X11_Xdmcp_FOUND,	   X11::Xdmcp
	  X11_Xext_INCLUDE_PATH,	 X11_Xext_LIB,	     X11_Xext_FOUND,	   X11::Xext
	  X11_Xxf86misc_INCLUDE_PATH,	 X11_Xxf86misc_LIB,  X11_Xxf86misc_FOUND,  X11::Xxf86misc
	  X11_Xxf86vm_INCLUDE_PATH,	 X11_Xxf86vm_LIB     X11_Xxf86vm_FOUND,	   X11::Xxf86vm
	  X11_Xfixes_INCLUDE_PATH,	 X11_Xfixes_LIB,     X11_Xfixes_FOUND,	   X11::Xfixes
	  X11_Xft_INCLUDE_PATH,		 X11_Xft_LIB,	     X11_Xft_FOUND,	   X11::Xft
	  X11_Xi_INCLUDE_PATH,		 X11_Xi_LIB,	     X11_Xi_FOUND,	   X11::Xi
	  X11_Xinerama_INCLUDE_PATH,	 X11_Xinerama_LIB,   X11_Xinerama_FOUND,   X11::Xinerama
	  X11_Xkb_INCLUDE_PATH,
	  X11_Xkblib_INCLUDE_PATH,			     X11_Xkb_FOUND,	   X11::Xkb
	  X11_xkbcommon_INCLUDE_PATH,	 X11_xkbcommon_LIB,  X11_xkbcommon_FOUND,  X11::xkbcommon
	  X11_xkbcommon_X11_INCLUDE_PATH,X11_xkbcommon_X11_LIB,X11_xkbcommon_X11_FOUND,X11::xkbcommon_X11
	  X11_xkbfile_INCLUDE_PATH,	 X11_xkbfile_LIB,    X11_xkbfile_FOUND,	   X11::xkbfile
	  X11_Xmu_INCLUDE_PATH,		 X11_Xmu_LIB,	     X11_Xmu_FOUND,	   X11::Xmu
	  X11_Xpm_INCLUDE_PATH,		 X11_Xpm_LIB,	     X11_Xpm_FOUND,	   X11::Xpm
	  X11_Xtst_INCLUDE_PATH,	 X11_Xtst_LIB,	     X11_Xtst_FOUND,	   X11::Xtst
	  X11_Xrandr_INCLUDE_PATH,	 X11_Xrandr_LIB,     X11_Xrandr_FOUND,	   X11::Xrandr
	  X11_Xrender_INCLUDE_PATH,	 X11_Xrender_LIB,    X11_Xrender_FOUND,	   X11::Xrender
	  X11_XRes_INCLUDE_PATH,	 X11_XRes_LIB,	     X11_XRes_FOUND,	   X11::XRes
	  X11_Xss_INCLUDE_PATH,		 X11_Xss_LIB,	     X11_Xss_FOUND,	   X11::Xss
	  X11_Xt_INCLUDE_PATH,		 X11_Xt_LIB,	     X11_Xt_FOUND,	   X11::Xt
	  X11_Xutil_INCLUDE_PATH,			     X11_Xutil_FOUND,	   X11::Xutil
	  X11_Xv_INCLUDE_PATH,		 X11_Xv_LIB,	     X11_Xv_FOUND,	   X11::Xv
	  X11_dpms_INCLUDE_PATH,	 (in X11_Xext_LIB),  X11_dpms_FOUND
	  X11_XShm_INCLUDE_PATH,	 (in X11_Xext_LIB),  X11_XShm_FOUND
	  X11_Xshape_INCLUDE_PATH,	 (in X11_Xext_LIB),  X11_Xshape_FOUND
	  X11_XSync_INCLUDE_PATH,	 (in X11_Xext_LIB),  X11_XSync_FOUND
	  X11_Xaw_INCLUDE_PATH,		 X11_Xaw_LIB	     X11_Xaw_FOUND	   X11::Xaw

       New in version 3.14:  Renamed  Xxf86misc,  X11_Xxf86misc,  X11_Xxf86vm,
       X11_xkbfile, X11_Xtst, and X11_Xss libraries to match their file	names.
       Deprecated the X11_Xinput library.  Old names are still	available  for
       compatibility.

       New in version 3.14: Added the X11_Xext_INCLUDE_PATH variable.

       New  in	version	3.18: Added the	xcb, X11-xcb, xcb-icccm, xcb-xkb, xkb-
       common, and xkbcommon-X11 libraries.

       New in version 3.19: Added the Xaw, xcb_util, and xcb_xfixes libraries.

   FindXalanC
       New in version 3.5.

       Find the	Apache Xalan-C++  XSL  transform  processor  headers  and  li-
       braries.

   Imported targets
       This module defines the following IMPORTED targets:

       XalanC::XalanC
	      The Xalan-C++ xalan-c library, if	found.

   Result variables
       This module will	set the	following variables in your project:

       XalanC_FOUND
	      true if the Xalan	headers	and libraries were found

       XalanC_VERSION
	      Xalan release version

       XalanC_INCLUDE_DIRS
	      the  directory  containing  the  Xalan headers; note XercesC_IN-
	      CLUDE_DIRS is also required

       XalanC_LIBRARIES
	      Xalan libraries to be linked; note XercesC_LIBRARIES is also re-
	      quired

   Cache variables
       The following cache variables may also be set:

       XalanC_INCLUDE_DIR
	      the directory containing the Xalan headers

       XalanC_LIBRARY
	      the Xalan	library

   FindXCTest
       New in version 3.3.

       Functions to help creating and executing	XCTest bundles.

       An  XCTest  bundle is a CFBundle	with a special product-type and	bundle
       extension. The Mac Developer Library provides more information  in  the
       Testing with Xcode document.

   Module Functions
       xctest_add_bundle
	      The  xctest_add_bundle  function	creates	 a XCTest bundle named
	      <target> which will test the target <testee>.  Supported	target
	      types for	testee are Frameworks and App Bundles:

		 xctest_add_bundle(
		   <target>  # Name of the XCTest bundle
		   <testee>  # Target name of the testee
		   )

       xctest_add_test
	      The  xctest_add_test  function  adds  an	XCTest	bundle	to the
	      project to be run	by ctest(1). The test will be named <name> and
	      tests <bundle>:

		 xctest_add_test(
		   <name>    # Test name
		   <bundle>  # Target name of XCTest bundle
		   )

   Module Variables
       The following variables are set by including this module:

       XCTest_FOUND
	      True if the XCTest Framework and executable were found.

       XCTest_EXECUTABLE
	      The  path	to the xctest command line tool	used to	execute	XCTest
	      bundles.

       XCTest_INCLUDE_DIRS
	      The directory containing the XCTest Framework headers.

       XCTest_LIBRARIES
	      The location of the XCTest Framework.

   FindXercesC
       New in version 3.1.

       Find the	Apache Xerces-C++ validating XML parser	headers	and libraries.

   Imported targets
       New in version 3.5.

       This module defines the following IMPORTED targets:

       XercesC::XercesC
	      The Xerces-C++ xerces-c library, if found.

   Result variables
       This module will	set the	following variables in your project:

       XercesC_FOUND
	      true if the Xerces headers and libraries were found

       XercesC_VERSION
	      Xerces release version

       XercesC_INCLUDE_DIRS
	      the directory containing the Xerces headers

       XercesC_LIBRARIES
	      Xerces libraries to be linked

   Cache variables
       The following cache variables may also be set:

       XercesC_INCLUDE_DIR
	      the directory containing the Xerces headers

       XercesC_LIBRARY
	      the Xerces library

       New in version 3.4: Debug and Release variants are found	separately.

   FindXMLRPC
       Find xmlrpc

       Find the	native XMLRPC headers and libraries.

	  XMLRPC_INCLUDE_DIRS	   - where to find xmlrpc.h, etc.
	  XMLRPC_LIBRARIES	   - List of libraries when using xmlrpc.
	  XMLRPC_FOUND		   - True if xmlrpc found.

       XMLRPC modules may be specified as components  for  this	 find  module.
       Modules may be listed by	running	"xmlrpc-c-config".  Modules include:

	  c++		 C++ wrapper code
	  libwww-client	 libwww-based client
	  cgi-server	 CGI-based server
	  abyss-server	 ABYSS-based server

       Typical usage:

	  find_package(XMLRPC REQUIRED libwww-client)

   FindZLIB
       Find the	native ZLIB includes and library.

   IMPORTED Targets
       New in version 3.1.

       This module defines IMPORTED target ZLIB::ZLIB, if ZLIB has been	found.

   Result Variables
       This module defines the following variables:

	  ZLIB_INCLUDE_DIRS   -	where to find zlib.h, etc.
	  ZLIB_LIBRARIES      -	List of	libraries when using zlib.
	  ZLIB_FOUND	      -	True if	zlib found.

	  ZLIB_VERSION_STRING -	The version of zlib found (x.y.z)
	  ZLIB_VERSION_MAJOR  -	The major version of zlib
	  ZLIB_VERSION_MINOR  -	The minor version of zlib
	  ZLIB_VERSION_PATCH  -	The patch version of zlib
	  ZLIB_VERSION_TWEAK  -	The tweak version of zlib

       New in version 3.4: Debug and Release variants are found	separately.

   Backward Compatibility
       The following variable are provided for backward	compatibility

	  ZLIB_MAJOR_VERSION  -	The major version of zlib
	  ZLIB_MINOR_VERSION  -	The minor version of zlib
	  ZLIB_PATCH_VERSION  -	The patch version of zlib

   Hints
       A  user may set ZLIB_ROOT to a zlib installation	root to	tell this mod-
       ule where to look.

DEPRECATED MODULES
   Deprecated Utility Modules
   AddFileDependencies
       Deprecated since	version	3.20.

       Add dependencies	to a source file.

	  add_file_dependencies(<source> <files>...)

       Adds the	given <files> to the dependencies of file <source>.

       Do not use this command in new code.  It	is just	a wrapper around:

	  set_property(SOURCE <source> APPEND PROPERTY OBJECT_DEPENDS <files>...)

       Instead use the set_property() command to append	to the	OBJECT_DEPENDS
       source file property directly.

   CMakeDetermineVSServicePack
       Deprecated since	version	3.0: Do	not use.

       The   functionality   of	  this	module	has  been  superseded  by  the
       CMAKE_<LANG>_COMPILER_VERSION variable that contains the	compiler  ver-
       sion number.

       Determine the Visual Studio service pack	of the 'cl' in use.

       Usage:

	  if(MSVC)
	    include(CMakeDetermineVSServicePack)
	    DetermineVSServicePack( my_service_pack )
	    if(	my_service_pack	)
	      message(STATUS "Detected:	${my_service_pack}")
	    endif()
	  endif()

       Function	 DetermineVSServicePack	 sets the given	variable to one	of the
       following values	or an empty string if unknown:

	  vc80,	vc80sp1
	  vc90,	vc90sp1
	  vc100, vc100sp1
	  vc110, vc110sp1, vc110sp2, vc110sp3, vc110sp4

   CMakeExpandImportedTargets
       Deprecated since	version	3.4: Do	not use.

       This module was once needed to expand imported targets to the  underly-
       ing libraries they reference on disk for	use with the try_compile() and
       try_run() commands.  These commands now support imported	 libraries  in
       their  LINK_LIBRARIES options (since CMake 2.8.11 for try_compile() and
       since CMake 3.2 for try_run()).

       This module does	not support the	policy CMP0022 NEW behavior or use  of
       the  INTERFACE_LINK_LIBRARIES  property	because	 generator expressions
       cannot be evaluated during configuration.

	  CMAKE_EXPAND_IMPORTED_TARGETS(<var> LIBRARIES	lib1 lib2...libN
					[CONFIGURATION <config>])

       CMAKE_EXPAND_IMPORTED_TARGETS() takes a list of libraries and  replaces
       all  imported  targets  contained  in  this list	with their actual file
       paths of	the referenced libraries on disk, including the	libraries from
       their  link  interfaces.	  If a CONFIGURATION is	given, it uses the re-
       spective	configuration of the imported targets if  it  exists.	If  no
       CONFIGURATION   is   given,   it	 uses  the  first  configuration  from
       ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.

	  cmake_expand_imported_targets(expandedLibs
	    LIBRARIES ${CMAKE_REQUIRED_LIBRARIES}
	    CONFIGURATION "${CMAKE_TRY_COMPILE_CONFIGURATION}" )

   CMakeForceCompiler
       Deprecated since	version	3.6: Do	not use.

       The macros provided by this  module  were  once	intended  for  use  by
       cross-compiling	toolchain  files  when CMake was not able to automati-
       cally detect the	compiler identification.  Since	 the  introduction  of
       this module, CMake's compiler identification capabilities have improved
       and can now be taught to	 recognize  any	 compiler.   Furthermore,  the
       suite of	information CMake detects from a compiler is now too extensive
       to be provided by toolchain files using these macros.

       One common use case for this module was to skip CMake's	checks	for  a
       working	compiler when using a cross-compiler that cannot link binaries
       without special flags or	custom linker scripts.	This case is now  sup-
       ported  by  setting  the	 CMAKE_TRY_COMPILE_TARGET_TYPE variable	in the
       toolchain file instead.

					----

       Macro CMAKE_FORCE_C_COMPILER has	the following signature:

	  CMAKE_FORCE_C_COMPILER(<compiler> <compiler-id>)

       It sets CMAKE_C_COMPILER	to the given compiler and the  cmake  internal
       variable	 CMAKE_C_COMPILER_ID  to  the  given compiler-id.  It also by-
       passes the check	for working compiler and  basic	 compiler  information
       tests.

       Macro CMAKE_FORCE_CXX_COMPILER has the following	signature:

	  CMAKE_FORCE_CXX_COMPILER(<compiler> <compiler-id>)

       It sets CMAKE_CXX_COMPILER to the given compiler	and the	cmake internal
       variable	CMAKE_CXX_COMPILER_ID to the given compiler-id.	 It  also  by-
       passes  the  check  for working compiler	and basic compiler information
       tests.

       Macro CMAKE_FORCE_Fortran_COMPILER has the following signature:

	  CMAKE_FORCE_Fortran_COMPILER(<compiler> <compiler-id>)

       It sets CMAKE_Fortran_COMPILER to the given compiler and	the cmake  in-
       ternal variable CMAKE_Fortran_COMPILER_ID to the	given compiler-id.  It
       also bypasses the check for working compiler and	basic compiler	infor-
       mation tests.

       So a simple toolchain file could	look like this:

	  include (CMakeForceCompiler)
	  set(CMAKE_SYSTEM_NAME	Generic)
	  CMAKE_FORCE_C_COMPILER   (chc12 MetrowerksHicross)
	  CMAKE_FORCE_CXX_COMPILER (chc12 MetrowerksHicross)

   CMakeParseArguments
       This  module  once implemented the cmake_parse_arguments() command that
       is now implemented natively by CMake.  It is now	an  empty  placeholder
       for compatibility with projects that include it to get the command from
       CMake 3.4 and lower.

   Documentation
       Deprecated since	version	3.18: This module does nothing,	unless	policy
       CMP0106 is set to OLD.

       This  module  provides support for the VTK documentation	framework.  It
       relies on several tools (Doxygen, Perl, etc).

   MacroAddFileDependencies
       Deprecated since	version	3.14.

	  MACRO_ADD_FILE_DEPENDENCIES(<source> <files>...)

       Do not use this command in new code.  It	is just	a wrapper around:

	  set_property(SOURCE <source> APPEND PROPERTY OBJECT_DEPENDS <files>...)

       Instead use the set_property() command to append	to the	OBJECT_DEPENDS
       source file property directly.

   TestCXXAcceptsFlag
       Deprecated since	version	3.0: See CheckCXXCompilerFlag.

       Check if	the CXX	compiler accepts a flag.

	  CHECK_CXX_ACCEPTS_FLAG(<flags> <variable>)

       <flags>
	      the flags	to try

       <variable>
	      variable to store	the result

   UseJavaClassFilelist
       Changed	in version 3.20: This module was previously documented by mis-
       take and	was never meant	for direct inclusion by	project	code.  See the
       UseJava module.

   UseJavaSymlinks
       Changed	in version 3.20: This module was previously documented by mis-
       take and	was never meant	for direct inclusion by	project	code.  See the
       UseJava module.

   UsePkgConfig
       Obsolete	pkg-config module for CMake, use FindPkgConfig instead.

       This module defines the following macro:

       PKGCONFIG(package includedir libdir linkflags cflags)

       Calling	PKGCONFIG  will	 fill the desired information into the 4 given
       arguments,      e.g.	  PKGCONFIG(libart-2.0	    LIBART_INCLUDE_DIR
       LIBART_LINK_DIR	LIBART_LINK_FLAGS LIBART_CFLAGS) if pkg-config was NOT
       found or	the specified software package	doesn't	 exist,	 the  variable
       will  be	 empty	when the function returns, otherwise they will contain
       the respective information

   Use_wxWindows
       Deprecated since	version	2.8.10:	Use  find_package(wxWidgets)  and  in-
       clude(${wxWidgets_USE_FILE}) instead.

       This  convenience  include  finds if wxWindows is installed and set the
       appropriate libs, incdirs, flags	etc.   author  Jan  Woetzel  <jw  -at-
       mip.informatik.uni-kiel.de> (07/2003)

       USAGE:

	  just include Use_wxWindows.cmake
	  in your projects CMakeLists.txt

       include(	${CMAKE_MODULE_PATH}/Use_wxWindows.cmake)

	  if you are sure you need GL then

       set(WXWINDOWS_USE_GL 1)

	  *before* you include this file.

   WriteBasicConfigVersionFile
       Deprecated  since  version  3.0:	 Use  the  identical command write_ba-
       sic_package_version_file() from module CMakePackageConfigHelpers.

	  WRITE_BASIC_CONFIG_VERSION_FILE( filename
	    [VERSION major.minor.patch]
	    COMPATIBILITY (AnyNewerVersion|SameMajorVersion|SameMinorVersion|ExactVersion)
	    [ARCH_INDEPENDENT]
	    )

   WriteCompilerDetectionHeader
       Deprecated since	version	3.20: This module is available only if	policy
       CMP0120 is not set to NEW.  Do not use it in new	code.

       New in version 3.1.

       This module provides the	function write_compiler_detection_header().

       This  function can be used to generate a	file suitable for preprocessor
       inclusion which contains	macros to be used in source code:

	  write_compiler_detection_header(
		    FILE <file>
		    PREFIX <prefix>
		    [OUTPUT_FILES_VAR <output_files_var> OUTPUT_DIR <output_dir>]
		    COMPILERS <compiler> [...]
		    FEATURES <feature> [...]
		    [BARE_FEATURES <feature> [...]]
		    [VERSION <version>]
		    [PROLOG <prolog>]
		    [EPILOG <epilog>]
		    [ALLOW_UNKNOWN_COMPILERS]
		    [ALLOW_UNKNOWN_COMPILER_VERSIONS]
	  )

       This generates the file <file> with macros which	all  have  the	prefix
       <prefix>.

       By  default,  all  content is written directly to the <file>.  The OUT-
       PUT_FILES_VAR may be specified to cause the  compiler-specific  content
       to be written to	separate files.	 The separate files are	then available
       in the <output_files_var> and may be consumed by	the caller for instal-
       lation  for example.  The OUTPUT_DIR specifies a	relative path from the
       main <file> to the compiler-specific files. For example:

	  write_compiler_detection_header(
	    FILE climbingstats_compiler_detection.h
	    PREFIX ClimbingStats
	    OUTPUT_FILES_VAR support_files
	    OUTPUT_DIR compilers
	    COMPILERS GNU Clang	MSVC Intel
	    FEATURES cxx_variadic_templates
	  )
	  install(FILES
	    ${CMAKE_CURRENT_BINARY_DIR}/climbingstats_compiler_detection.h
	    DESTINATION	include
	  )
	  install(FILES
	    ${support_files}
	    DESTINATION	include/compilers
	  )

       VERSION may be used to specify the API version to be generated.	Future
       versions	 of  CMake may introduce alternative APIs.  A given API	is se-
       lected by any <version> value greater than or equal to the  version  of
       CMake  that introduced the given	API and	less than the version of CMake
       that introduced its succeeding API.  The	value of the CMAKE_MINIMUM_RE-
       QUIRED_VERSION  variable	 is  used if no	explicit version is specified.
       (As of CMake version 3.20.4 there is only one API version.)

       PROLOG may be specified as text content to write	at the	start  of  the
       header.	EPILOG may be specified	as text	content	to write at the	end of
       the header

       At least	one <compiler> and one <feature> must  be  listed.   Compilers
       which  are  known  to  CMake, but not specified are detected and	a pre-
       processor #error	is generated for them.	A preprocessor macro  matching
       <PREFIX>_COMPILER_IS_<compiler> is generated for	each compiler known to
       CMake to	contain	the value 0 or 1.

       Possible	compiler identifiers are documented with the CMAKE_<LANG>_COM-
       PILER_ID	 variable.   Available	features  in this version of CMake are
       listed  in  the	CMAKE_C_KNOWN_FEATURES	and   CMAKE_CXX_KNOWN_FEATURES
       global properties.  See the cmake-compile-features(7) manual for	infor-
       mation on compile features.

       New in version 3.2: Added MSVC and AppleClang compiler support.

       New in version 3.6: Added Intel compiler	support.

       Changed in version 3.8: The {c,cxx}_std_* meta-features are ignored  if
       requested.

       New  in	version	 3.8:  ALLOW_UNKNOWN_COMPILERS	and ALLOW_UNKNOWN_COM-
       PILER_VERSIONS cause the	module to generate conditions that  treat  un-
       known  compilers	as simply lacking all features.	 Without these options
       the default behavior is to generate a #error for	unknown	compilers  and
       versions.

       New in version 3.12: BARE_FEATURES will define the compatibility	macros
       with the	name used in newer versions of the language standard,  so  the
       code can	use the	new feature name unconditionally.

   Feature Test	Macros
       For  each  compiler,  a	preprocessor macro is generated	matching <PRE-
       FIX>_COMPILER_IS_<compiler> which has the content either	0  or  1,  de-
       pending	on  the	compiler in use. Preprocessor macros for compiler ver-
       sion components are generated matching  <PREFIX>_COMPILER_VERSION_MAJOR
       <PREFIX>_COMPILER_VERSION_MINOR	 and   <PREFIX>_COMPILER_VERSION_PATCH
       containing decimal values for the corresponding compiler	version	compo-
       nents, if defined.

       A preprocessor test is generated	based on the compiler version denoting
       whether each feature is enabled.	 A preprocessor	macro  matching	 <PRE-
       FIX>_COMPILER_<FEATURE>,	 where	<FEATURE>  is the upper-case <feature>
       name, is	generated to contain the value 0 or 1 depending	on whether the
       compiler	in use supports	the feature:

	  write_compiler_detection_header(
	    FILE climbingstats_compiler_detection.h
	    PREFIX ClimbingStats
	    COMPILERS GNU Clang	AppleClang MSVC	Intel
	    FEATURES cxx_variadic_templates
	  )

	  #if ClimbingStats_COMPILER_CXX_VARIADIC_TEMPLATES
	  template<typename... T>
	  void someInterface(T t...) { /* ... */ }
	  #else
	  // Compatibility versions
	  template<typename T1>
	  void someInterface(T1	t1) { /* ... */	}
	  template<typename T1,	typename T2>
	  void someInterface(T1	t1, T2 t2) { /*	... */ }
	  template<typename T1,	typename T2, typename T3>
	  void someInterface(T1	t1, T2 t2, T3 t3) { /* ... */ }
	  #endif

   Symbol Macros
       Some  additional	symbol-defines are created for particular features for
       use as symbols which may	be conditionally defined empty:

	  class	MyClass	ClimbingStats_FINAL
	  {
	      ClimbingStats_CONSTEXPR int someInterface() { return 42; }
	  };

       The ClimbingStats_FINAL macro will expand to final if the compiler (and
       its  flags) support the cxx_final feature, and the ClimbingStats_CONST-
       EXPR macro will expand to constexpr if cxx_constexpr is supported.

       If BARE_FEATURES	cxx_final was given as argument	the final keyword will
       be defined for old compilers, too.

       The  following  features	 generate  corresponding symbol	defines	and if
       they are	available as BARE_FEATURES:

	    +------------------+--------------------+-------------+------+
	    |Feature	       | Define		    | Symbol	  | bare |
	    +------------------+--------------------+-------------+------+
	    |c_restrict	       | <PREFIX>_RE-	    | restrict	  | yes	 |
	    |		       | STRICT		    |		  |	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_constexpr     | <PREFIX>_CONST-    | constexpr	  | yes	 |
	    |		       | EXPR		    |		  |	 |
	    +------------------+--------------------+-------------+------+

	    |cxx_deleted_func- | <PRE-		    | =	delete	  |	 |
	    |tions	       | FIX>_DELETED_FUNC- |		  |	 |
	    |		       | TION		    |		  |	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_extern_tem-   | <PREFIX>_EX-	    | extern	  |	 |
	    |plates	       | TERN_TEMPLATE	    |		  |	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_final	       | <PREFIX>_FINAL	    | final	  | yes	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_noexcept      | <PREFIX>_NOEXCEPT  | noexcept	  | yes	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_noexcept      | <PREFIX>_NOEX-	    | noexcept(X) |	 |
	    |		       | CEPT_EXPR(X)	    |		  |	 |
	    +------------------+--------------------+-------------+------+
	    |cxx_override      | <PREFIX>_OVERRIDE  | override	  | yes	 |
	    +------------------+--------------------+-------------+------+

   Compatibility Implementation	Macros
       Some features are suitable for wrapping in a macro with a backward com-
       patibility implementation if the	compiler does not support the feature.

       When  the  cxx_static_assert feature is not provided by the compiler, a
       compatibility implementation is available via  the  <PREFIX>_STATIC_AS-
       SERT(COND)   and	 <PREFIX>_STATIC_ASSERT_MSG(COND,  MSG)	 function-like
       macros. The macros expand to static_assert where	that compiler  feature
       is  available,  and to a	compatibility implementation otherwise.	In the
       first form, the condition  is  stringified  in  the  message  field  of
       static_assert.	In  the	 second	form, the message MSG is passed	to the
       message field of	static_assert, or ignored if using the	backward  com-
       patibility implementation.

       The  cxx_attribute_deprecated feature provides a	macro definition <PRE-
       FIX>_DEPRECATED,	which expands to either	 the  standard	[[deprecated]]
       attribute   or	a   compiler-specific	decorator   such  as  __attri-
       bute__((__deprecated__))	used by	GNU compilers.

       The cxx_alignas feature provides	a  macro  definition  <PREFIX>_ALIGNAS
       which  expands  to  either  the	standard  alignas  decorator or	a com-
       piler-specific decorator	such as	__attribute__ ((__aligned__)) used  by
       GNU compilers.

       The  cxx_alignof	 feature  provides a macro definition <PREFIX>_ALIGNOF
       which expands to	either	the  standard  alignof	decorator  or  a  com-
       piler-specific decorator	such as	__alignof__ used by GNU	compilers.

	    +-----------------+------------------+----------------+------+
	    |Feature	      |	Define		 | Symbol	  | bare |
	    +-----------------+------------------+----------------+------+
	    |cxx_alignas      |	<PREFIX>_ALIGNAS | alignas	  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_alignof      |	<PREFIX>_ALIGNOF | alignof	  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_nullptr      |	<PREFIX>_NULLPTR | nullptr	  | yes	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_static_as-   |	<PRE-		 | static_assert  |	 |
	    |sert	      |	FIX>_STATIC_AS-	 |		  |	 |
	    |		      |	SERT		 |		  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_static_as-   |	<PRE-		 | static_assert  |	 |
	    |sert	      |	FIX>_STATIC_AS-	 |		  |	 |
	    |		      |	SERT_MSG	 |		  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_attri-	      |	<PREFIX>_DEPRE-	 | [[deprecated]] |	 |
	    |bute_deprecated  |	CATED		 |		  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_attri-	      |	<PREFIX>_DEPRE-	 | [[deprecated]] |	 |
	    |bute_deprecated  |	CATED_MSG	 |		  |	 |
	    +-----------------+------------------+----------------+------+
	    |cxx_thread_local |	<PRE-		 | thread_local	  |	 |
	    |		      |	FIX>_THREAD_LO-	 |		  |	 |
	    |		      |	CAL		 |		  |	 |
	    +-----------------+------------------+----------------+------+

       A use-case which	arises with such deprecation macros is the deprecation
       of an entire library.  In that case, all	public API in the library  may
       be  decorated with the <PREFIX>_DEPRECATED macro.  This results in very
       noisy build output when building	the library itself, so the  macro  may
       be  may	be  defined to empty in	that case when building	the deprecated
       library:

	  add_library(compat_support ${srcs})
	  target_compile_definitions(compat_support
	    PRIVATE
	      CompatSupport_DEPRECATED=
	  )

   Example Usage
       NOTE:
	  This section was migrated from the cmake-compile-features(7)	manual
	  since	 it relies on the WriteCompilerDetectionHeader module which is
	  removed by policy CMP0120.

       Compile features	may be preferred if available, without creating	a hard
       requirement.   For example, a library may provide alternative implemen-
       tations depending on  whether  the  cxx_variadic_templates  feature  is
       available:

	  #if Foo_COMPILER_CXX_VARIADIC_TEMPLATES
	  template<int I, int... Is>
	  struct Interface;

	  template<int I>
	  struct Interface<I>
	  {
	    static int accumulate()
	    {
	      return I;
	    }
	  };

	  template<int I, int... Is>
	  struct Interface
	  {
	    static int accumulate()
	    {
	      return I + Interface<Is...>::accumulate();
	    }
	  };
	  #else
	  template<int I1, int I2 = 0, int I3 =	0, int I4 = 0>
	  struct Interface
	  {
	    static int accumulate() { return I1	+ I2 + I3 + I4;	}
	  };
	  #endif

       Such an interface depends on using the correct preprocessor defines for
       the compiler features.  CMake can generate  a  header  file  containing
       such defines using the WriteCompilerDetectionHeader module.  The	module
       contains	the write_compiler_detection_header function which accepts pa-
       rameters	to control the content of the generated	header file:

	  write_compiler_detection_header(
	    FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
	    PREFIX Foo
	    COMPILERS GNU
	    FEATURES
	      cxx_variadic_templates
	  )

       Such  a	header	file  may  be  used internally in the source code of a
       project,	and it may be installed	and used in the	interface  of  library
       code.

       For  each feature listed	in FEATURES, a preprocessor definition is cre-
       ated in the header file,	and defined to either 1	or 0.

       Additionally, some features call	for additional defines,	 such  as  the
       cxx_final  and  cxx_override features. Rather than being	used in	#ifdef
       code, the final keyword is abstracted by	a symbol which is  defined  to
       either  final,  a compiler-specific equivalent, or to empty.  That way,
       C++ code	can be written to unconditionally use the symbol, and compiler
       support determines what it is expanded to:

	  struct Interface {
	    virtual void Execute() = 0;
	  };

	  struct Concrete Foo_FINAL {
	    void Execute() Foo_OVERRIDE;
	  };

       In  this	 case, Foo_FINAL will expand to	final if the compiler supports
       the keyword, or to empty	otherwise.

       In this use-case, the project code may wish to enable a particular lan-
       guage  standard if available from the compiler. The CXX_STANDARD	target
       property	may be set to the desired language standard for	 a  particular
       target, and the CMAKE_CXX_STANDARD variable may be set to influence all
       following targets:

	  write_compiler_detection_header(
	    FILE "${CMAKE_CURRENT_BINARY_DIR}/foo_compiler_detection.h"
	    PREFIX Foo
	    COMPILERS GNU
	    FEATURES
	      cxx_final	cxx_override
	  )

	  # Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
	  # which will expand to 'final' if the	compiler supports the requested
	  # CXX_STANDARD.
	  add_library(foo foo.cpp)
	  set_property(TARGET foo PROPERTY CXX_STANDARD	11)

	  # Includes foo_compiler_detection.h and uses the Foo_FINAL symbol
	  # which will expand to 'final' if the	compiler supports the feature,
	  # even though	CXX_STANDARD is	not set	explicitly.  The requirement of
	  # cxx_constexpr causes CMake to set CXX_STANDARD internally, which
	  # affects the	compile	flags.
	  add_library(foo_impl foo_impl.cpp)
	  target_compile_features(foo_impl PRIVATE cxx_constexpr)

       The write_compiler_detection_header function also creates compatibility
       code  for other features	which have standard equivalents.  For example,
       the cxx_static_assert feature is	 emulated  with	 a  template  and  ab-
       stracted	 via the <PREFIX>_STATIC_ASSERT	and <PREFIX>_STATIC_ASSERT_MSG
       function-macros.

   Deprecated Find Modules
   FindCUDA
       Deprecated since	version	3.10.

       It is no	longer necessary to use	this module or call find_package(CUDA)
       for  compiling  CUDA code. Instead, list	CUDA among the languages named
       in the top-level	call to	the project() command, or call the enable_lan-
       guage() command with CUDA.  Then	one can	add CUDA (.cu) sources to pro-
       grams directly in calls to add_library()	and add_executable().

       New in version 3.17: To find and	use the	 CUDA  toolkit	libraries  the
       FindCUDAToolkit module has superseded this module.  It works whether or
       not the CUDA language is	enabled.

   Documentation of Deprecated Usage
       Tools for building CUDA C files:	libraries and build dependencies.

       This script locates the NVIDIA CUDA C tools.  It	should work on	Linux,
       Windows,	 and macOS and should be reasonably up to date with CUDA C re-
       leases.

       New in version 3.19: QNX	support.

       This script makes use of	the standard find_package() arguments of <VER-
       SION>,  REQUIRED	 and  QUIET.   CUDA_FOUND will report if an acceptable
       version of CUDA was found.

       The script will prompt the user to specify CUDA_TOOLKIT_ROOT_DIR	if the
       prefix  cannot be determined by the location of nvcc in the system path
       and REQUIRED is specified to find_package().  To	use  a	different  in-
       stalled	 version   of	the   toolkit  set  the	 environment  variable
       CUDA_BIN_PATH  before  running  cmake   (e.g.	CUDA_BIN_PATH=/usr/lo-
       cal/cuda1.0  instead  of	the default /usr/local/cuda) or	set CUDA_TOOL-
       KIT_ROOT_DIR after configuring.	If you change the value	of  CUDA_TOOL-
       KIT_ROOT_DIR,  various components that depend on	the path will be relo-
       cated.

       It might	be necessary to	set CUDA_TOOLKIT_ROOT_DIR manually on  certain
       platforms,  or to use a CUDA runtime not	installed in the default loca-
       tion.  In newer versions	of the toolkit the CUDA	 library  is  included
       with  the  graphics  driver  -- be sure that the	driver version matches
       what is needed by the CUDA runtime version.

   Input Variables
       The following variables affect the behavior of the macros in the	script
       (in  alphabetical  order).  Note	that any of these flags	can be changed
       multiple	times in  the  same  directory	before	calling	 cuda_add_exe-
       cutable(),   cuda_add_library(),	  cuda_compile(),  cuda_compile_ptx(),
       cuda_compile_fatbin(), cuda_compile_cubin() or cuda_wrap_srcs():

       CUDA_64_BIT_DEVICE_CODE (Default: host bit size)
	      Set to ON	to compile for 64 bit device code, OFF for 32 bit  de-
	      vice  code.   Note that making this different from the host code
	      when generating object or	C files	 from  CUDA  code  just	 won't
	      work,  because  size_t  gets  defined  by	 nvcc in the generated
	      source.  If you compile to PTX and then load the file  yourself,
	      you can mix bit sizes between device and host.

       CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE (Default:	ON)
	      Set  to  ON  if you want the custom build	rule to	be attached to
	      the source file in Visual	Studio.	 Turn OFF if you add the  same
	      cuda file	to multiple targets.

	      This  allows  the	 user  to build	the target from	the CUDA file;
	      however, bad things can happen if	the CUDA source	file is	 added
	      to multiple targets.  When performing parallel builds it is pos-
	      sible for	the custom build command to be run more	than once  and
	      in parallel causing cryptic build	errors.	 VS runs the rules for
	      every source file	in the target, and a source can	have only  one
	      rule  no matter how many projects	it is added to.	 When the rule
	      is run from multiple targets race	conditions can	occur  on  the
	      generated	 file.	 Eventually  everything	will get built,	but if
	      the user is unaware of this behavior, there  may	be  confusion.
	      It would be nice if this script could detect the reuse of	source
	      files across multiple targets and	turn the option	 off  for  the
	      user, but	no good	solution could be found.

       CUDA_BUILD_CUBIN	(Default: OFF)
	      Set  to  ON to enable and	extra compilation pass with the	-cubin
	      option in	Device mode. The output	is parsed and register,	shared
	      memory usage is printed during build.

       CUDA_BUILD_EMULATION (Default: OFF for device mode)
	      Set to ON	for Emulation mode. -D_DEVICEEMU is defined for	CUDA C
	      files when CUDA_BUILD_EMULATION is TRUE.

       CUDA_LINK_LIBRARIES_KEYWORD (Default: "")
	      New in version 3.9.

	      The <PRIVATE|PUBLIC|INTERFACE> keyword to	use for	internal  tar-
	      get_link_libraries()  calls.  The	 default  is to	use no keyword
	      which uses the old "plain" form of target_link_libraries(). Note
	      that  is	matters	 because  whatever is used inside the FindCUDA
	      module must also be  used	 outside  -  the  two  forms  of  tar-
	      get_link_libraries() cannot be mixed.

       CUDA_GENERATED_OUTPUT_DIR (Default: CMAKE_CURRENT_BINARY_DIR)
	      Set to the path you wish to have the generated files placed.  If
	      it is blank output files will  be	 placed	 in  CMAKE_CURRENT_BI-
	      NARY_DIR.	   Intermediate	  files	  will	always	be  placed  in
	      CMAKE_CURRENT_BINARY_DIR/CMakeFiles.

       CUDA_HOST_COMPILATION_CPP (Default: ON)
	      Set to OFF for C compilation of host code.

       CUDA_HOST_COMPILER (Default: CMAKE_C_COMPILER)
	      Set the host compiler to be used by nvcc.	 Ignored if -ccbin  or
	      --compiler-bindir	 is  already present in	the CUDA_NVCC_FLAGS or
	      CUDA_NVCC_FLAGS_<CONFIG> variables.  For Visual Studio  targets,
	      the  host	compiler is constructed	with one or more visual	studio
	      macros such as $(VCInstallDir), that expands  out	 to  the  path
	      when the command is run from within VS.

	      New  in version 3.13: If the CUDAHOSTCXX environment variable is
	      set it will be used as the default.

       CUDA_NVCC_FLAGS,	CUDA_NVCC_FLAGS_<CONFIG>
	      Additional NVCC command line arguments.	NOTE:  multiple	 argu-
	      ments   must   be	  semi-colon  delimited	 (e.g.	--compiler-op-
	      tions;-Wall)

	      New in version 3.6: Contents of these variables may use  genera-
	      tor expressions.

       CUDA_PROPAGATE_HOST_FLAGS (Default: ON)
	      Set  to ON to propagate CMAKE_{C,CXX}_FLAGS and their configura-
	      tion dependent counterparts (e.g.	CMAKE_C_FLAGS_DEBUG) automati-
	      cally to the host	compiler through nvcc's	-Xcompiler flag.  This
	      helps make the generated host code match the rest	of the	system
	      better.	Sometimes  certain  flags give nvcc problems, and this
	      will help	you turn the flag propagation off.  This does not  af-
	      fect  the	flags supplied directly	to nvcc	via CUDA_NVCC_FLAGS or
	      through the OPTION flags specified  through  cuda_add_library(),
	      cuda_add_executable(),  or  cuda_wrap_srcs().   Flags  used  for
	      shared library compilation are not affected by this flag.

       CUDA_SEPARABLE_COMPILATION (Default: OFF)
	      If set this will enable separable	compilation for	all CUDA  run-
	      time object files.  If used outside of cuda_add_executable() and
	      cuda_add_library()  (e.g.	 calling  cuda_wrap_srcs()  directly),
	      cuda_compute_separable_compilation_object_file_name()	   and
	      cuda_link_separable_compilation_objects()	should be called.

       CUDA_SOURCE_PROPERTY_FORMAT
	      New in version 3.3.

	      If this source file property is set, it can override the	format
	      specified	 to cuda_wrap_srcs() (OBJ, PTX,	CUBIN, or FATBIN).  If
	      an input source file is not a .cu	file, setting this  file  will
	      cause  it	 to  be	 treated  as a .cu file. See documentation for
	      set_source_files_properties on how to set	this property.

       CUDA_USE_STATIC_CUDA_RUNTIME (Default: ON)
	      New in version 3.3.

	      When enabled the static version of the CUDA runtime library will
	      be  used	in  CUDA_LIBRARIES.  If	the version of CUDA configured
	      doesn't support this option, then	it will	be silently disabled.

       CUDA_VERBOSE_BUILD (Default: OFF)
	      Set to ON	to see all the commands	used when  building  the  CUDA
	      file.   When  using  a  Makefile generator the value defaults to
	      VERBOSE (run make	VERBOSE=1 to  see  output),  although  setting
	      CUDA_VERBOSE_BUILD to ON will always print the output.

   Commands
       The  script creates the following functions and macros (in alphabetical
       order):

	  cuda_add_cufft_to_target(<cuda_target>)

       Adds the	cufft library to the target  (can  be  any  target).   Handles
       whether you are in emulation mode or not.

	  cuda_add_cublas_to_target(<cuda_target>)

       Adds  the  cublas  library  to the target (can be any target).  Handles
       whether you are in emulation mode or not.

	  cuda_add_executable(<cuda_target> <file>...
			      [WIN32] [MACOSX_BUNDLE] [EXCLUDE_FROM_ALL] [OPTIONS ...])

       Creates an executable <cuda_target> which is made up of the files spec-
       ified.	All  of	 the  non CUDA C files are compiled using the standard
       build rules specified by	CMake and the CUDA files are compiled  to  ob-
       ject  files  using  nvcc	 and  the host compiler.  In addition CUDA_IN-
       CLUDE_DIRS is added automatically to include_directories().  Some stan-
       dard  CMake  target  calls can be used on the target after calling this
       macro (e.g. set_target_properties() and	target_link_libraries()),  but
       setting	properties  that adjust	compilation flags will not affect code
       compiled	by  nvcc.   Such  flags	 should	 be  modified  before  calling
       cuda_add_executable(), cuda_add_library() or cuda_wrap_srcs().

	  cuda_add_library(<cuda_target> <file>...
			   [STATIC | SHARED | MODULE] [EXCLUDE_FROM_ALL] [OPTIONS ...])

       Same as cuda_add_executable() except that a library is created.

	  cuda_build_clean_target()

       Creates a convenience target that deletes all the dependency files gen-
       erated.	You should make	clean after running this target	to ensure  the
       dependency files	get regenerated.

	  cuda_compile(<generated_files> <file>... [STATIC | SHARED | MODULE]
		       [OPTIONS	...])

       Returns	a  list	 of  generated files from the input source files to be
       used with add_library() or add_executable().

	  cuda_compile_ptx(<generated_files> <file>... [OPTIONS	...])

       Returns a list of PTX files generated from the input source files.

	  cuda_compile_fatbin(<generated_files>	<file>... [OPTIONS ...])

       New in version 3.1.

       Returns a list of FATBIN	files generated	from the input source files.

	  cuda_compile_cubin(<generated_files> <file>... [OPTIONS ...])

       New in version 3.1.

       Returns a list of CUBIN files generated from the	input source files.

	  cuda_compute_separable_compilation_object_file_name(<output_file_var>
							      <cuda_target>
							      <object_files>)

       Compute the name	of the intermediate link file used for separable  com-
       pilation.   This	 file  name is typically passed	into CUDA_LINK_SEPARA-
       BLE_COMPILATION_OBJECTS.	  output_file_var   is	 produced   based   on
       cuda_target  the	 list of objects files that need separable compilation
       as specified by <object_files>.	If the <object_files> list  is	empty,
       then <output_file_var> will be empty.  This function is called automat-
       ically for cuda_add_library()  and  cuda_add_executable().   Note  that
       this is a function and not a macro.

	  cuda_include_directories(path0 path1 ...)

       Sets  the  directories that should be passed to nvcc (e.g. nvcc -Ipath0
       -Ipath1 ...). These paths usually contain other .cu files.

	  cuda_link_separable_compilation_objects(<output_file_var> <cuda_target>
						  <nvcc_flags> <object_files>)

       Generates the link object required by separable	compilation  from  the
       given  object  files.   This  is	called automatically for cuda_add_exe-
       cutable() and cuda_add_library(), but can be called manually when using
       cuda_wrap_srcs()	 directly.   When  called  from	 cuda_add_library() or
       cuda_add_executable() the <nvcc_flags> passed in	are the	 same  as  the
       flags passed in via the OPTIONS argument.  The only nvcc	flag added au-
       tomatically  is	the  bitness  flag  as	specified  by  CUDA_64_BIT_DE-
       VICE_CODE.  Note	that this is a function	instead	of a macro.

	  cuda_select_nvcc_arch_flags(<out_variable> [<target_CUDA_architecture> ...])

       Selects GPU arch	flags for nvcc based on	target_CUDA_architecture.

       Values for target_CUDA_architecture:

       o Auto: detects local machine GPU compute arch at runtime.

       o Common	and All: cover common and entire subsets of architectures.

       o <name>:  one  of  Fermi, Kepler, Maxwell, Kepler+Tegra, Kepler+Tesla,
	 Maxwell+Tegra,	Pascal.

       o <ver>,	<ver>(<ver>), <ver>+PTX, where <ver> is	one of 2.0, 2.1,  3.0,
	 3.2, 3.5, 3.7,	5.0, 5.2, 5.3, 6.0, 6.2.

       Returns list of flags to	be added to CUDA_NVCC_FLAGS in <out_variable>.
       Additionally, sets <out_variable>_readable  to  the  resulting  numeric
       list.

       Example:

	  cuda_select_nvcc_arch_flags(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
	  list(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})

       More  info  on  CUDA architectures: https://en.wikipedia.org/wiki/CUDA.
       Note that this is a function instead of a macro.

	  cuda_wrap_srcs(<cuda_target> <format>	<generated_files> <file>...
			 [STATIC | SHARED | MODULE] [OPTIONS ...])

       This  is	 where	all   the   magic   happens.	cuda_add_executable(),
       cuda_add_library(),  cuda_compile(),  and  cuda_compile_ptx()  all call
       this function under the hood.

       Given the list of files <file>... this macro generates custom  commands
       that  generate  either  PTX or linkable objects (use PTX	or OBJ for the
       <format>	argument to switch).  Files that don't end with	 .cu  or  have
       the HEADER_FILE_ONLY property are ignored.

       The arguments passed in after OPTIONS are extra command line options to
       give to nvcc.  You can also specify per configuration options by	speci-
       fying  the  name	of the configuration followed by the options.  General
       options must precede configuration specific options.  Not all  configu-
       rations need to be specified, only the ones provided will be used.  For
       example:

	  cuda_add_executable(...
	    OPTIONS -DFLAG=2 "-DFLAG_OTHER=space in flag"
	    DEBUG -g
	    RELEASE --use_fast_math
	    RELWITHDEBINFO --use_fast_math;-g
	    MINSIZEREL --use_fast_math)

       For certain configurations (namely  VS  generating  object  files  with
       CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE  set  to	ON), no	generated file
       will be produced	for the	given cuda file.  This is because when you add
       the  cuda file to Visual	Studio it knows	that this file produces	an ob-
       ject file and will link in the resulting	object file automatically.

       This script will	also generate a	separate cmake script that is used  at
       build time to invoke nvcc.  This	is for several reasons:

       o nvcc can return negative numbers as return values which confuses Vis-
	 ual Studio into thinking that the command succeeded.  The script  now
	 checks	the error codes	and produces errors when there was a problem.

       o nvcc  has been	known to not delete incomplete results when it encoun-
	 ters problems.	 This confuses build systems into thinking the	target
	 was  generated	 when in fact an unusable file exists.	The script now
	 deletes the output files if there was an error.

       o By putting all	the options that affect	the build into a file and then
	 make  the  build rule dependent on the	file, the output files will be
	 regenerated when the options change.

       This script also	looks at optional arguments STATIC, SHARED, or	MODULE
       to  determine  when  to	target the object compilation for a shared li-
       brary.  BUILD_SHARED_LIBS is ignored in cuda_wrap_srcs(), but it	is re-
       spected in cuda_add_library().  On some systems special flags are added
       for building objects intended for  shared  libraries.   A  preprocessor
       macro,  <target_name>_EXPORTS is	defined	when a shared library compila-
       tion is detected.

       Flags passed into add_definitions with -D or /D	are  passed  along  to
       nvcc.

   Result Variables
       The script defines the following	variables:

       CUDA_VERSION_MAJOR
	      The major	version	of cuda	as reported by nvcc.

       CUDA_VERSION_MINOR
	      The minor	version.

       CUDA_VERSION, CUDA_VERSION_STRING
	      Full version in the X.Y format.

       CUDA_HAS_FP16
	      New  in  version	3.6:  Whether a	short float (float16, fp16) is
	      supported.

       CUDA_TOOLKIT_ROOT_DIR
	      Path to the CUDA Toolkit (defined	if not set).

       CUDA_SDK_ROOT_DIR
	      Path to the CUDA SDK.  Use this to find files in the SDK.	  This
	      script  will  not	directly support finding specific libraries or
	      headers, as that isn't supported by  NVIDIA.   If	 you  want  to
	      change  libraries	 when  the path	changes	see the	FindCUDA.cmake
	      script for an example of how to clear  these  variables.	 There
	      are  also	examples of how	to use the CUDA_SDK_ROOT_DIR to	locate
	      headers or libraries, if you so choose (at your own risk).

       CUDA_INCLUDE_DIRS
	      Include directory	for cuda  headers.   Added  automatically  for
	      cuda_add_executable() and	cuda_add_library().

       CUDA_LIBRARIES
	      Cuda RT library.

       CUDA_CUFFT_LIBRARIES
	      Device or	emulation library for the Cuda FFT implementation (al-
	      ternative	to cuda_add_cufft_to_target() macro)

       CUDA_CUBLAS_LIBRARIES
	      Device or	emulation library for  the  Cuda  BLAS	implementation
	      (alternative to cuda_add_cublas_to_target() macro).

       CUDA_cudart_static_LIBRARY
	      Statically  linkable  cuda  runtime library.  Only available for
	      CUDA version 5.5+.

       CUDA_cudadevrt_LIBRARY
	      New in version 3.7: Device runtime library.  Required for	 sepa-
	      rable compilation.

       CUDA_cupti_LIBRARY
	      CUDA Profiling Tools Interface library.  Only available for CUDA
	      version 4.0+.

       CUDA_curand_LIBRARY
	      CUDA Random Number Generation library.  Only available for  CUDA
	      version 3.2+.

       CUDA_cusolver_LIBRARY
	      New  in version 3.2: CUDA	Direct Solver library.	Only available
	      for CUDA version 7.0+.

       CUDA_cusparse_LIBRARY
	      CUDA Sparse Matrix library.  Only	 available  for	 CUDA  version
	      3.2+.

       CUDA_npp_LIBRARY
	      NVIDIA Performance Primitives lib.  Only available for CUDA ver-
	      sion 4.0+.

       CUDA_nppc_LIBRARY
	      NVIDIA Performance Primitives lib	(core).	  Only	available  for
	      CUDA version 5.5+.

       CUDA_nppi_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 5.5 - 8.0.

       CUDA_nppial_LIBRARY
	      NVIDIA Performance  Primitives  lib  (image  processing).	  Only
	      available	for CUDA version 9.0.

       CUDA_nppicc_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 9.0.

       CUDA_nppicom_LIBRARY
	      NVIDIA Performance  Primitives  lib  (image  processing).	  Only
	      available	for CUDA version 9.0 - 10.2.  Replaced by nvjpeg.

       CUDA_nppidei_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 9.0.

       CUDA_nppif_LIBRARY
	      NVIDIA Performance  Primitives  lib  (image  processing).	  Only
	      available	for CUDA version 9.0.

       CUDA_nppig_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 9.0.

       CUDA_nppim_LIBRARY
	      NVIDIA Performance  Primitives  lib  (image  processing).	  Only
	      available	for CUDA version 9.0.

       CUDA_nppist_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 9.0.

       CUDA_nppisu_LIBRARY
	      NVIDIA Performance  Primitives  lib  (image  processing).	  Only
	      available	for CUDA version 9.0.

       CUDA_nppitc_LIBRARY
	      NVIDIA  Performance  Primitives  lib  (image  processing).  Only
	      available	for CUDA version 9.0.

       CUDA_npps_LIBRARY
	      NVIDIA Performance Primitives  lib  (signal  processing).	  Only
	      available	for CUDA version 5.5+.

       CUDA_nvcuvenc_LIBRARY
	      CUDA  Video  Encoder  library.   Only available for CUDA version
	      3.2+.  Windows only.

       CUDA_nvcuvid_LIBRARY
	      CUDA Video Decoder library.  Only	 available  for	 CUDA  version
	      3.2+.  Windows only.

       CUDA_nvToolsExt_LIBRARY
	      New in version 3.16: NVIDA CUDA Tools Extension library.	Avail-
	      able for CUDA version 5+.

       CUDA_OpenCL_LIBRARY
	      New in version 3.16: NVIDA CUDA OpenCL library.	Available  for
	      CUDA version 5+.

   FindPythonInterp
       Deprecated  since  version  3.12: Use FindPython3, FindPython2 or Find-
       Python instead.

       Find python interpreter

       This module finds if Python interpreter	is  installed  and  determines
       where the executables are.  This	code sets the following	variables:

	  PYTHONINTERP_FOUND	     - Was the Python executable found
	  PYTHON_EXECUTABLE	     - path to the Python interpreter

	  PYTHON_VERSION_STRING	     - Python version found e.g. 2.5.2
	  PYTHON_VERSION_MAJOR	     - Python major version found e.g. 2
	  PYTHON_VERSION_MINOR	     - Python minor version found e.g. 5
	  PYTHON_VERSION_PATCH	     - Python patch version found e.g. 2

       The  Python_ADDITIONAL_VERSIONS	variable can be	used to	specify	a list
       of version numbers that should be taken into account when searching for
       Python.	 You  need  to	set  this  variable  before calling find_pack-
       age(PythonInterp).

       If calling  both	 find_package(PythonInterp)  and  find_package(Python-
       Libs),  call  find_package(PythonInterp)	first to get the currently ac-
       tive Python version by default with a consistent	version	of  PYTHON_LI-
       BRARIES.

       NOTE:
	  A  call  to find_package(PythonInterp	${V}) for python version V may
	  find a python	executable with	no version suffix.  In	this  case  no
	  attempt  is  made  to	 avoid python executables from other versions.
	  Use FindPython3, FindPython2 or FindPython instead.

   FindPythonLibs
       Deprecated since	version	3.12: Use FindPython3,	FindPython2  or	 Find-
       Python instead.

       Find python libraries

       This  module  finds if Python is	installed and determines where the in-
       clude files and libraries are.  It also determines what the name	of the
       library is.  This code sets the following variables:

	  PYTHONLIBS_FOUND	     - have the	Python libs been found
	  PYTHON_LIBRARIES	     - path to the python library
	  PYTHON_INCLUDE_PATH	     - path to where Python.h is found (deprecated)
	  PYTHON_INCLUDE_DIRS	     - path to where Python.h is found
	  PYTHON_DEBUG_LIBRARIES     - path to the debug library (deprecated)
	  PYTHONLIBS_VERSION_STRING  - version of the Python libs found	(since CMake 2.8.8)

       The  Python_ADDITIONAL_VERSIONS	variable can be	used to	specify	a list
       of version numbers that should be taken into account when searching for
       Python.	 You  need  to	set  this  variable  before calling find_pack-
       age(PythonLibs).

       If you'd	like to	specify	the installation of Python to use, you	should
       modify the following cache variables:

	  PYTHON_LIBRARY	     - path to the python library
	  PYTHON_INCLUDE_DIR	     - path to where Python.h is found

       If  calling  both  find_package(PythonInterp)  and find_package(Python-
       Libs), call find_package(PythonInterp) first to get the	currently  ac-
       tive  Python version by default with a consistent version of PYTHON_LI-
       BRARIES.

   FindQt
       Deprecated since	version	3.14: This module is available only if	policy
       CMP0084 is not set to NEW.

       Searches	for all	installed versions of Qt3 or Qt4.

       This  module  cannot  handle Qt5	or any later versions.	For those, see
       cmake-qt(7).

       This module should only be used if your project can work	with  multiple
       versions	 of  Qt.   If  not,  you  should  just directly	use FindQt4 or
       FindQt3.	 If multiple versions of Qt are	found on the machine, then The
       user must set the option	DESIRED_QT_VERSION to the version they want to
       use.  If	only one version of qt is found	on the machine,	then  the  DE-
       SIRED_QT_VERSION	 is  set  to  that version and the matching FindQt3 or
       FindQt4 module is included.  Once  the  user  sets  DESIRED_QT_VERSION,
       then the	FindQt3	or FindQt4 module is included.

	  QT_REQUIRED if this is set to	TRUE then if CMake can
		      not find Qt4 or Qt3 an error is raised
		      and a message is sent to the user.

	  DESIRED_QT_VERSION OPTION is created
	  QT4_INSTALLED	is set to TRUE if qt4 is found.
	  QT3_INSTALLED	is set to TRUE if qt3 is found.

   FindwxWindows
       Deprecated since	version	3.0: Replaced by FindwxWidgets.

       Find wxWindows (wxWidgets) installation

       This  module  finds  if wxWindows/wxWidgets is installed	and determines
       where the include files and libraries are.  It also determines what the
       name of the library is.	This code sets the following variables:

	  WXWINDOWS_FOUND     =	system has WxWindows
	  WXWINDOWS_LIBRARIES =	path to	the wxWindows libraries
				on Unix/Linux with additional
				linker flags from
				"wx-config --libs"
	  CMAKE_WXWINDOWS_CXX_FLAGS  = Compiler	flags for wxWindows,
				       essentially "`wx-config --cxxflags`"
				       on Linux
	  WXWINDOWS_INCLUDE_DIR	     = where to	find "wx/wx.h" and "wx/setup.h"
	  WXWINDOWS_LINK_DIRECTORIES = link directories, useful	for rpath on
					Unix
	  WXWINDOWS_DEFINITIONS	     = extra defines

       OPTIONS If you need OpenGL support please

	  set(WXWINDOWS_USE_GL 1)

       in your CMakeLists.txt before you include this file.

	  HAVE_ISYSTEM	    - true required to replace -I by -isystem on g++

       For  convenience	 include  Use_wxWindows.cmake in your project's	CMake-
       Lists.txt using include(${CMAKE_CURRENT_LIST_DIR}/Use_wxWindows.cmake).

       USAGE

	  set(WXWINDOWS_USE_GL 1)
	  find_package(wxWindows)

       NOTES wxWidgets 2.6.x is	supported for monolithic builds	e.g.  compiled
       in wx/build/msw dir as:

	  nmake	-f makefile.vc BUILD=debug SHARED=0 USE_OPENGL=1 MONOLITHIC=1

       DEPRECATED

	  CMAKE_WX_CAN_COMPILE
	  WXWINDOWS_LIBRARY
	  CMAKE_WX_CXX_FLAGS
	  WXWINDOWS_INCLUDE_PATH

       AUTHOR	 Jan	Woetzel	   <http://www.mip.informatik.uni-kiel.de/~jw>
       (07/2003-01/2006)

   Legacy CPack	Modules
       These modules used to be	mistakenly exposed to the user,	and have  been
       moved  out  of  user  visibility.  They are for CPack internal use, and
       should never be used directly.

   CPackArchive
       New in version 3.9.

       The documentation for the CPack Archive generator has moved here: CPack
       Archive Generator

   CPackBundle
       The  documentation for the CPack	Bundle generator has moved here: CPack
       Bundle Generator

   CPackCygwin
       The documentation for the CPack Cygwin generator	has moved here:	 CPack
       Cygwin Generator

   CPackDeb
       The documentation for the CPack DEB generator has moved here: CPack DEB
       Generator

   CPackDMG
       The documentation for the CPack DragNDrop  generator  has  moved	 here:
       CPack DragNDrop Generator

   CPackFreeBSD
       New in version 3.10.

       The documentation for the CPack FreeBSD generator has moved here: CPack
       FreeBSD Generator

   CPackNSIS
       The documentation for the CPack NSIS generator has  moved  here:	 CPack
       NSIS Generator

   CPackNuGet
       New in version 3.12.

       The  documentation  for the CPack NuGet generator has moved here: CPack
       NuGet Generator

   CPackPackageMaker
       The documentation for the CPack PackageMaker generator has moved	 here:
       CPack PackageMaker Generator

   CPackProductBuild
       New in version 3.7.

       The  documentation for the CPack	productbuild generator has moved here:
       CPack productbuild Generator

   CPackRPM
       The documentation for the CPack RPM generator has moved here: CPack RPM
       Generator

   CPackWIX
       The documentation for the CPack WIX generator has moved here: CPack WIX
       Generator

COPYRIGHT
       2000-2021 Kitware, Inc. and Contributors

3.20.4				 Aug 26, 2021		      CMAKE-MODULES(7)

NAME | UTILITY MODULES | FIND MODULES | DEPRECATED MODULES | COPYRIGHT

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=cmake-modules&sektion=7&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help