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	behavior  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 behavior 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  specify how many
	      threads will be used for compression.

	      A	positive integer can be	 used  to  specify  an	exact  desired
	      thread count.

	      When  given a negative integer CPack will	use the	absolute value
	      as the upper limit but may choose	a lower	 value	based  on  the
	      available	hardware concurrency.

	      Given 0 CPack will try to	use all	available CPU cores.

	      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.

	      New  in  version	3.21:  Official	 CMake	binaries  available on
	      cmake.org	now ship with a	liblzma	that  supports	parallel  com-
	      pression.	 Older versions	did not.

   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.

		     New in version 3.21.

		     Component or group	names listed as	dependencies may  con-
		     tain hyphens.  This requires QtIFW	3.1 or later.

	      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.

		     New in version 3.21.

		     Component or group	names listed as	dependencies may  con-
		     tain hyphens.  This requires QtIFW	3.1 or later.

	      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 a
			    few	options	based on the main  project.   The  op-
			    tions added	are typically only those needed	to use
			    the	same generator as the main  project,  but  the
			    CMAKE_GENERATOR  option  can  be given to override
			    this.  The project is responsible for  adding  any
			    toolchain  details,	 flags	or  other  settings it
			    wants to re-use from the main project or otherwise
			    specify   (see  CMAKE_ARGS,	 CMAKE_CACHE_ARGS  and
			    CMAKE_CACHE_DEFAULT_ARGS below).

			    For	 non-CMake  external  projects,	 the   CONFIG-
			    URE_COMMAND	 option	 must  be used to override the
			    default configure command  (generator  expressions
			    are	 supported). For projects that require no con-
			    figure 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.

		     If	 both  the  main  project and the external project use
		     make as their build tool, the build step of the  external
		     project  is  invoked  as  a recursive make	using $(MAKE).
		     This will communicate some	build tool settings  from  the
		     main project to the external project.  If either the main
		     project or	external project is not	using make,  no	 build
		     tool  settings  will  be  passed  to the external project
		     other than	those established by the configure step	 (i.e.
		     running  ninja -v in the main project will	not pass -v to
		     the external project's build step,	even if	it  also  uses
		     ninja as its build	tool).

		     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	   703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.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	  703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0
		 )

		 FetchContent_Declare(
		   myCompanyIcons
		   URL	    https://intranet.mycompany.com/assets/iconset_1.12.tar.gz
		   URL_HASH MD5=5588a7b18261c20068beabfb4f530b87
		 )

		 FetchContent_Declare(
		   myCompanyCertificates
		   SVN_REPOSITORY svn+ssh://svn.mycompany.com/srv/svn/trunk/certs
		   SVN_REVISION	  -r12345
		 )

	      Where contents are being fetched from a remote location and  you
	      do  not  control	that server, it	is advisable to	use a hash for
	      GIT_TAG rather than a branch or tag name.	 A commit hash is more
	      secure  and  helps  to  confirm that the downloaded contents are
	      what you expected.

   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 favor	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	   703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0
	  )
	  FetchContent_Declare(
	    Catch2
	    GIT_REPOSITORY https://github.com/catchorg/Catch2.git
	    GIT_TAG	   de6fe184a9ac1a06895cdd1c9b437f0a0bdf14ad # v2.13.4
	  )

	  # 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	   ae50d9b9902526efd6c7a1907d09739f959c6297 # v3.15.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	   v2.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 information 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
       This file provides support for Java.  It	is assumed that	 FindJava  has
       already	been loaded.  See FindJava for information on how to load Java
       into your CMake project.

   Synopsis
	  Creating and Installing JARS
	    add_jar (<target_name> [SOURCES] <source1> [<source2>...] ...)
	    install_jar	(<target_name> DESTINATION <destination> [COMPONENT <component>])
	    install_jni_symlink	(<target_name> DESTINATION <destination> [COMPONENT <component>])

	  Header Generation
	    create_javah ((TARGET <target> | GENERATED_FILES <VAR>) CLASSES <class>... ...)

	  Exporting JAR	Targets
	    install_jar_exports	(TARGETS <jars>... FILE	<filename> DESTINATION <destination> ...)
	    export_jars	(TARGETS <jars>... [NAMESPACE <namespace>] FILE	<filename>)

	  Finding JARs
	    find_jar (<VAR> NAMES <name1> [<name2>...] [PATHS <path1> [<path2>... ENV <var>]] ...)

	  Creating Java	Documentation
	    create_javadoc (<VAR> (PACKAGES <pkg1> [<pkg2>...] | FILES <file1> [<file2>...]) ...)

   Creating And	Installing JARs
       add_jar
	      Creates a	jar file containing java objects and, optionally,  re-
	      sources:

		 add_jar(<target_name>
			 [SOURCES] <source1> [<source2>...] [<resource1>...]
			 [RESOURCES NAMESPACE <ns1> <resource1>... [NAMESPACE <nsX> <resourceX>...]... ]
			 [INCLUDE_JARS <jar1> [<jar2>...]]
			 [ENTRY_POINT <entry>]
			 [VERSION <version>]
			 [MANIFEST <manifest>]
			 [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.

	      SOURCES
		     Compiles  the  specified source files and adds the	result
		     in	the jar	file.

		     New in version 3.4: Support for response files,  prefixed
		     by	@.

	      RESOURCES
		     New in version 3.21.

		     Adds  the	named <resource> files to the jar by stripping
		     the source	file path and placing the  file	 beneath  <ns>
		     within the	jar.

		     For example:

			RESOURCES NAMESPACE "/com/my/namespace"	"a/path/to/resource.txt"

		     results   in  a  resource	accessible  via	 /com/my/name-
		     space/resource.txt	within the jar.

		     Resources may be added without adjusting the namespace by
		     adding  them  to the list of SOURCES (original behavior),
		     in	 this  case,  resource	paths  must  be	 relative   to
		     CMAKE_CURRENT_SOURCE_DIR.	Adding resources without using
		     the RESOURCES parameter in	out of source builds will  al-
		     most certainly result in confusion.

		     NOTE:
			Adding resources via the SOURCES parameter relies upon
			a hard-coded list of file extensions which are	tested
			to  determine  whether	they compile (e.g. File.java).
			SOURCES	files which match the extensions are compiled.
			Files  which do	not match are treated as resources. To
			include	uncompiled resources matching those  file  ex-
			tensions use the RESOURCES parameter.

	      INCLUDE_JARS
		     The  list of jars are added to the	classpath when compil-
		     ing the java sources and also to the dependencies of  the
		     target. INCLUDE_JARS also accepts other target names cre-
		     ated by add_jar().	For backwards compatibility, jar files
		     listed  as	 sources  are ignored (as they have been since
		     the first version of this module).

	      ENTRY_POINT
		     Defines an	entry point in the jar file.

	      VERSION
		     Adds a version to the target output name.

		     The following example will	create a  jar  file  with  the
		     name shibboleet-1.2.0.jar and will	create a symlink shib-
		     boleet.jar	pointing to the	jar with the version  informa-
		     tion.

			add_jar(shibboleet shibbotleet.java VERSION 1.2.0)

	      MANIFEST
		     Defines a custom manifest for the jar.

	      OUTPUT_NAME
		     Specify a different output	name for the target.

	      OUTPUT_DIR
		     Sets  the directory where the jar file will be generated.
		     If	not specified, CMAKE_CURRENT_BINARY_DIR	is used	as the
		     output directory.

	      GENERATE_NATIVE_HEADERS
		     New in version 3.11.

		     Generates native header files for methods declared	as na-
		     tive. 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.

		     This option requires, at least, version 1.8 of the	JDK.

		     For an optimum usage of this option, it is	recommended to
		     include module JNI	before any call	to add_jar(). The pro-
		     duced target for native headers can then be used to  com-
		     pile  C/C++ sources with the target_link_libraries() com-
		     mand.

			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: DESTINATION sub-option now  supports
		     the  possibility  to specify different output directories
		     for BUILD and INSTALL steps. If BUILD  directory  is  not
		     specified,	a default directory will be used.

		     To	 export	the interface target generated by GENERATE_NA-
		     TIVE_HEADERS option, sub-option INSTALL of	DESTINATION is
		     required:

			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)

	      Some variables can be set	to customize the behavior of add_jar()
	      as well as the java compiler:

	      CMAKE_JAVA_COMPILE_FLAGS
		     Specify additional	flags to java compiler.

	      CMAKE_JAVA_INCLUDE_PATH
		     Specify additional	paths to the class path.

	      CMAKE_JNI_TARGET
		     If	the target is a	JNI library, sets this	boolean	 vari-
		     able  to  TRUE  to	enable creation	of a JNI symbolic link
		     (see also install_jni_symlink()).

	      CMAKE_JAR_CLASSES_PREFIX
		     If	multiple jars should be	produced from  the  same  java
		     source filetree, to prevent the accumulation of duplicate
		     class    files    in    subsequent	   jars,     set/reset
		     CMAKE_JAR_CLASSES_PREFIX prior to calling the add_jar():

			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)

	      The  add_jar()  function sets the	following target properties on
	      <target_name>:

	      INSTALL_FILES
		     The files which should be installed.   This  is  used  by
		     install_jar().

	      JNI_SYMLINK
		     The  JNI symlink which should be installed.  This is used
		     by	install_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.

	      NATIVE_HEADERS_DIRECTORY
		     New in version 3.20.

		     The directory where native	headers	are generated. Defined
		     when option GENERATE_NATIVE_HEADERS is specified.

       install_jar
	      This command installs the	jar file to the	given destination:

		 install_jar(<target_name> <destination>)
		 install_jar(<target_name> DESTINATION <destination> [COMPONENT	<component>])

	      This command installs the	<target_name> file 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.

	      DESTINATION
		     Specify the directory on disk to which a file will	be in-
		     stalled.

	      COMPONENT
		     Specify an	installation component name with which the in-
		     stall  rule is associated,	such as	"runtime" or "develop-
		     ment".

	      The install_jar()	command	sets the following  target  properties
	      on <target_name>:

	      INSTALL_DESTINATION
		     Holds  the	 <destination> as described above, and is used
		     by	install_jar_exports().

       install_jni_symlink
	      Installs JNI symlinks for	target generated by add_jar():

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

	      DESTINATION
		     Specify the directory on disk to which a file will	be in-
		     stalled.

	      COMPONENT
		     Specify an	installation component name with which the in-
		     stall  rule is associated,	such as	"runtime" or "develop-
		     ment".

	      Utilize the following commands to	create 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})

   Header Generation
       create_javah
	      New in version 3.4.

	      Generates	C header files for java	classes:

		 create_javah(TARGET <target> |	GENERATED_FILES	<VAR>
			      CLASSES <class>...
			      [CLASSPATH <classpath>...]
			      [DEPENDS <depend>...]
			      [OUTPUT_NAME <path>|OUTPUT_DIR <path>]
			      )

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

	      Create C header files from java classes. These files provide the
	      connective 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 GENERATED_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
	      encapsulates header files	generation. E.g.

		 create_javah(TARGET target_headers
		   CLASSES org.cmake.HelloWorld
		   CLASSPATH hello.jar
		 )

	      Both signatures share same options.

	      CLASSES
		     Specifies Java classes used to generate headers.

	      CLASSPATH
		     Specifies	various	 paths to look up classes. Here	.class
		     files, jar	files or targets created  by  command  add_jar
		     can be used.

	      DEPENDS
		     Targets on	which the javah	target depends.

	      OUTPUT_NAME
		     Concatenates  the	resulting  header  files  for  all the
		     classes listed by option CLASSES into <path>.   Same  be-
		     havior as option -o of javah tool.

	      OUTPUT_DIR
		     Sets  the directory where the header files	will be	gener-
		     ated.  Same behavior as option -d of javah	tool.  If  not
		     specified,	CMAKE_CURRENT_BINARY_DIR is used as the	output
		     directory.

   Exporting JAR Targets
       install_jar_exports
	      New in version 3.7.

	      Installs a target	export file:

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

	      TARGETS
		     List of targets created by	add_jar() command.

	      NAMESPACE
		     New in version 3.9.

		     The <namespace> value will	be prepend to the target names
		     as	they are written to the	import file.

	      FILE   Specify name of the export	file.

	      DESTINATION
		     Specify the directory on disk to which a file will	be in-
		     stalled.

	      COMPONENT
		     Specify an	installation component name with which the in-
		     stall  rule is associated,	such as	"runtime" or "develop-
		     ment".

       export_jars
	      New in version 3.7.

	      Writes a target export file:

		 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 ex-
	      port().

	      TARGETS
		     List of targets created by	add_jar() command.

	      NAMESPACE
		     New in version 3.9.

		     The <namespace> value will	be prepend to the target names
		     as	they are written to the	import file.

	      FILE   Specify name of the export	file.

   Finding JARs
       find_jar
	      Finds the	specified jar file:

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

	      NAMES  Specify one or more possible names	for the	jar file.

	      PATHS  Specify  directories to search in addition	to the default
		     locations.	 The ENV var sub-option	 reads	paths  from  a
		     system environment	variable.

	      VERSIONS
		     Specify jar versions.

	      DOC    Specify  the documentation	string for the <VAR> cache en-
		     try.

   Creating Java Documentation
       create_javadoc
	      Creates java documentation based on files	and packages:

		 create_javadoc(<VAR>
				(PACKAGES <pkg1> [<pkg2>...] | FILES <file1> [<file2>...])
				[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)]
				)

	      The create_javadoc() command can be used to create java documen-
	      tation.  There are two main signatures for create_javadoc().

	      The  first  signature  works  with  package names	on a path with
	      source files:

		 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(my_example_doc
				FILES java/A.java java/B.java
				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. For more details
	      please read the javadoc manpage.

	      PACKAGES
		     Specify java packages.

	      FILES  Specify java source files.	If relative paths  are	speci-
		     fied, they	are relative to	CMAKE_CURRENT_SOURCE_DIR.

	      SOURCEPATH
		     Specify  the directory where to look for packages.	By de-
		     fault, CMAKE_CURRENT_SOURCE_DIR directory is used.

	      CLASSPATH
		     Specify where to find user	class files. Same behavior  as
		     option -classpath of javadoc tool.

	      INSTALLPATH
		     Specify  where  to	install	the java documentation.	If you
		     specified,	 the  documentation  will  be	installed   to
		     ${CMAKE_INSTALL_PREFIX}/share/javadoc/<VAR>.

	      DOCTITLE
		     Specify  the  title to place near the top of the overview
		     summary file.   Same  behavior  as	 option	 -doctitle  of
		     javadoc tool.

	      WINDOWTITLE
		     Specify  the  title to be placed in the HTML <title> tag.
		     Same behavior as option -windowtitle of javadoc tool.

	      AUTHOR When value	TRUE is	specified, includes the	 @author  text
		     in	 the  generated	docs. Same behavior as option  -author
		     of	javadoc	tool.

	      USE    When value	TRUE is	specified, creates class  and  package
		     usage  pages.   Includes one Use page for each documented
		     class and	package.  Same	behavior  as  option  -use  of
		     javadoc tool.

	      VERSION
		     When  value  TRUE is specified, includes the version text
		     in	the generated docs. Same behavior as  option  -version
		     of	javadoc	tool.

   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.

	      Changed in version 3.21: Generated library use  standard	naming
	      conventions  for	CSharp	language when policy CMP0122 is	set to
	      NEW. Otherwise, the legacy behavior is applied.

	      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,
	      Ninja and	Xcode generators. Default value	is FALSE.

	      New in version 3.21: Added the support of	Xcode generator.

       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	variable  is  only  meaningful	for  Makefile,
	      Ninja and	Xcode generators. Default value	is FALSE.

	      Source file property USE_SWIG_DEPENDENCIES, if not defined, will
	      be initialized with the value of this variable.

	      New in version 3.21: Added the support of	Xcode generator.

   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.

       At least	one of the C, CXX, or Fortran languages	must be	enabled.

   Input Variables
       The following variables may be set to influence this module's behavior:

       BLA_STATIC
	      if ON use	static linkage

       BLA_VENDOR
	      Set to one of the	BLAS/LAPACK Vendors to search  for  BLAS  only
	      from  the	specified vendor.  If not set, all vendors are consid-
	      ered.

       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
       This module defines the following IMPORTED targets:

       BLAS::BLAS
	      New in version 3.18.

	      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

   BLAS/LAPACK Vendors
       Generic
	      Generic reference	implementation

       ACML, ACML_MP, ACML_GPU
	      AMD Core Math Library

       Apple, NAS
	      Apple BLAS (Accelerate), and Apple NAS (vecLib)

       Arm, Arm_mp, Arm_ilp64, Arm_ilp64_mp
	      New in version 3.18.

	      Arm Performance Libraries

       ATLAS  Automatically Tuned Linear Algebra Software

       CXML, DXML
	      Compaq/Digital Extended Math Library

       EML, EML_mt
	      New in version 3.20.

	      Elbrus Math Library

       FLAME  New in version 3.11.

	      BLIS Framework

       FlexiBLAS
	      New in version 3.19.

       Fujitsu_SSL2, Fujitsu_SSL2BLAMP
	      New in version 3.20.

	      Fujitsu SSL2 serial and parallel blas/lapack

       Goto   GotoBLAS

       IBMESSL
	      IBM Engineering and Scientific Subroutine	Library

       Intel  Intel MKL	32 bit and 64 bit obsolete versions

       Intel10_32
	      Intel MKL	v10 32 bit, threaded code

       Intel10_64lp
	      Intel MKL	v10+ 64	bit, threaded code, lp64 model

       Intel10_64lp_seq
	      Intel MKL	v10+ 64	bit, sequential	code, lp64 model

       Intel10_64ilp
	      New in version 3.13.

	      Intel MKL	v10+ 64	bit, threaded code, ilp64 model

       Intel10_64ilp_seq
	      New in version 3.13.

	      Intel MKL	v10+ 64	bit, sequential	code, ilp64 model

       Intel10_64_dyn
	      New in version 3.17.

	      Intel MKL	v10+ 64	bit, single dynamic library

       NVHPC  New in version 3.21.

	      NVIDIA HPC SDK

       OpenBLAS
	      New in version 3.6.

       PhiPACK
	      Portable High Performance	ANSI C (PHiPAC)

       SCSL   Scientific Computing Software Library

       SGIMATH
	      SGI Scientific Mathematical Library

       SunPerf
	      Sun Performance Library

   Intel MKL
       To use the Intel	MKL implementation of BLAS, a project must  enable  at
       least  one  of  the C or	CXX languages.	Set BLA_VENDOR to an Intel MKL
       variant either on the command-line as -DBLA_VENDOR=Intel10_64lp	or  in
       project code:

	  set(BLA_VENDOR Intel10_64lp)
	  find_package(BLAS)

       In  order  to  build a project using Intel MKL, and end user must first
       establish an Intel MKL environment:

       Intel oneAPI
	      Source the full Intel environment	script:

		 . /opt/intel/oneapi/setvars.sh

	      Or, source the MKL component environment script:

		 . /opt/intel/oneapi/mkl/latest/env/vars.sh

       Intel Classic
	      Source the full Intel environment	script:

		 . /opt/intel/bin/compilervars.sh intel64

	      Or, source the MKL component environment script:

		 . /opt/intel/mkl/bin/mklvars.sh intel64

       The above environment scripts set the MKLROOT environment  variable  to
       the  top	 of  the  MKL installation.  They also add the location	of the
       runtime libraries to the	dynamic	library	 loader	 environment  variable
       for  your  platform (e.g. LD_LIBRARY_PATH).  This is necessary for pro-
       grams linked against MKL	to run.

       NOTE:
	  As of	Intel oneAPI 2021.2, loading only the MKL component  does  not
	  make	all  of	 its dependencies available.  In particular, the iomp5
	  library must be available separately,	or provided  by	 also  loading
	  the compiler component environment:

	      .	/opt/intel/oneapi/compiler/latest/env/vars.sh

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

   Arguments
       [<version>]
	      The [<version>] argument requests	a version with which the pack-
	      age  found should	be compatible. See find_package	version	format
	      for more details.

   Options
       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_MINOR
	      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/

   IMPORTED Targets
       New in version 3.21.

       This module defines the IMPORTED	targets:

       DevIL::IL
	      Defined if the system has	DevIL.

       DevIL::ILU
	      Defined if the system has	DevIL Utilities.

       DevIL::ILUT
	      Defined if the system has	DevIL Utility Toolkit.

   Result Variables
       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  applica-
	      tion.

       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 li-
	      brary interfaces with OpenGL. It is not strictly needed  in  ap-
	      plications.

       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.

       DevIL_ILUT_FOUND
	      New in version 3.21.

	      This is set to TRUE if the ILUT library is found.

   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.  CMake	 vari-
       ables are named DOXYGEN_<name> for the Doxygen settings specified here.

	  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 target.
	  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	target.
	  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_VERSION
	      New in version 3.21.

	      The version of iconv found (x.y)

       Iconv_VERSION_MAJOR
	      New in version 3.21.

	      The major	version	of iconv

       Iconv_VERSION_MINOR
	      New in version 3.21.

	      The minor	version	of iconv

       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.

       NOTE:
	  Some libiconv	implementations	don't  embed  the  version  number  in
	  their	 header	files.	In this	case the variables Iconv_VERSION* will
	  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.

       Intl_VERSION
	      New in version 3.21.

	      The version of intl found	(x.y.z)

       Intl_VERSION_MAJOR
	      New in version 3.21.

	      The major	version	of intl

       Intl_VERSION_MINOR
	      New in version 3.21.

	      The minor	version	of intl

       Intl_VERSION_PATCH
	      New in version 3.21.

	      The patch	version	of intl

       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:
	  Some libintl implementations don't embed the version number in their
	  header files.	 In this case  the  variables  Intl_VERSION*  will  be
	  empty.

       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
       LAPACK linear-algebra interface.

       At least	one of the C, CXX, or Fortran languages	must be	enabled.

   Input Variables
       The following variables may be set to influence this module's behavior:

       BLA_STATIC
	      if ON use	static linkage

       BLA_VENDOR
	      Set  to  one  of the BLAS/LAPACK Vendors to search for BLAS only
	      from the specified vendor.  If not set, all vendors are  consid-
	      ered.

       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
       This module defines the following IMPORTED targets:

       LAPACK::LAPACK
	      New in version 3.18.

	      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

   Intel MKL
       To use the Intel	MKL implementation of LAPACK, a	project	must enable at
       least  one  of  the C or	CXX languages.	Set BLA_VENDOR to an Intel MKL
       variant either on the command-line as -DBLA_VENDOR=Intel10_64lp	or  in
       project code:

	  set(BLA_VENDOR Intel10_64lp)
	  find_package(LAPACK)

       In  order  to  build a project using Intel MKL, and end user must first
       establish an Intel MKL environment.  See	the FindBLAS module section on
       Intel MKL for details.

   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 behavior is platform spe-
       cific:

       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 behavior:

       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 behavior	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, organized
	      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 initialization 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.

   FindMsys
       New in version 3.21.

       Find MSYS, a POSIX-compatible environment that runs natively on	Micro-
       soft Windows

   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 targets if Vulkan has been found:

       Vulkan::Vulkan
	      The main Vulkan library.

       Vulkan::glslc
	      New in version 3.19.

	      The GLSLC	SPIR-V compiler, if it has been	found.

       Vulkan::Headers
	      New in version 3.21.

	      Provides just Vulkan headers include paths, if  found.   No  li-
	      brary is included	in this	target.	 This can be useful for	appli-
	      cations that load	Vulkan library dynamically.

       Vulkan::glslangValidator
	      New in version 3.21.

	      The glslangValidator tool, if found.  It is used to compile GLSL
	      and HLSL shaders into SPIR-V.

   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
	  Vulkan_GLSLANG_VALIDATOR_EXECUTABLE -	the path to the	glslangValidator tool

   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.21.3 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
       WARNING:
	  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  di-
       rectly to targets similar to other languages.

       New  in	version	3.17: To find and use the CUDA toolkit libraries manu-
       ally, use the FindCUDAToolkit module instead.  It works	regardless  of
       the CUDA	language being 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.21.3				 Nov 04, 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