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

ALL MODULES
   AddFileDependencies
       ADD_FILE_DEPENDENCIES(source_file depend_files...)

       Adds the	given files as dependencies to source_file

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

	  FIXUP_BUNDLE(<app> <libs> <dirs>)

       Fix  up	a  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.

       As  an  optional	 parameter  (IGNORE_ITEM)  a list of file names	can be
       passed,	 which	 are   then   ignored	(e.g.	 IGNORE_ITEM	"vcre-
       dist_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.

       As an optional parameter	(IGNORE_ITEM) a	list  of  file	names  can  be
       passed,	  which	   are	 then	ignored	  (e.g.	  IGNORE_ITEM	"vcre-
       dist_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  sim-
       ply return 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" di-
       rectory	in  <bundle_var>  and the path to its main executable in <exe-
       cutable_var>

	  GET_BUNDLE_ALL_EXECUTABLES(<bundle> <exes_var>)

       Scans the given bundle recursively for all executable files and accumu-
       lates them into a variable.

	  GET_ITEM_KEY(<item> <key_var>)

       Given  a	file (item) name, generate a key that should be	unique consid-
       ering the set of	libraries that need copying or fixing  up  to  make  a
       bundle  standalone.  This is essentially	the file name including	exten-
       sion 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 list of keys, clearing all the variables associated 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  a  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 the  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.

       As an optional parameter	(IGNORE_ITEM) a	list  of  file	names  can  be
       passed,	  which	   are	 then	ignored	  (e.g.	  IGNORE_ITEM	"vcre-
       dist_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_embedded_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	embedded 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.

       As  an  optional	 parameter  (IGNORE_ITEM)  a list of file names	can be
       passed,	 which	 are   then   ignored	(e.g.	 IGNORE_ITEM	"vcre-
       dist_x86.exe;vcredist_x64.exe")

	  VERIFY_BUNDLE_SYMLINKS(<bundle> <result_var> <info_var>)

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

   CheckCCompilerFlag
       Check whether the C compiler supports a given flag.

       CHECK_C_COMPILER_FLAG(<flag> <var>)

	  <flag> - the compiler	flag
	  <var>	 - variable to store the result
		   Will	be created as an internal cache	variable.

       This  internally	 calls	the  check_c_source_compiles  macro  and  sets
       CMAKE_REQUIRED_DEFINITIONS to <flag>.  See  help	 for  CheckCSourceCom-
       piles  for  a listing of	variables that can otherwise modify the	build.
       The result only tells that the compiler does not	give an	error  message
       when it encounters the flag.  If	the flag has any effect	or even	a spe-
       cific one is beyond the scope of	this module.

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

       CHECK_C_SOURCE_COMPILES(<code> <var> [FAIL_REGEX	<fail-regex>])

	  <code>       - source	code to	try to compile,	must define 'main'
	  <var>	       - variable to store whether the source code compiled
			 Will be created as an internal	cache variable.
	  <fail-regex> - fail if test output matches this regex

       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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckCSourceRuns
       Check if	the given C source code	compiles and runs.

       CHECK_C_SOURCE_RUNS(<code> <var>)

	  <code>   - source code to try	to compile
	  <var>	   - variable to store the result
		     (1	for success, empty for failure)
		     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_INCLUDES = list of include directories
	  CMAKE_REQUIRED_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckCXXCompilerFlag
       Check whether the CXX compiler supports a given flag.

       CHECK_CXX_COMPILER_FLAG(<flag> <var>)

	  <flag> - the compiler	flag
	  <var>	 - variable to store the result

       This internally calls  the  check_cxx_source_compiles  macro  and  sets
       CMAKE_REQUIRED_DEFINITIONS  to <flag>.  See help	for CheckCXXSourceCom-
       piles for a listing of variables	that can otherwise modify  the	build.
       The  result only	tells that the compiler	does not give an error message
       when it encounters the flag.  If	the flag has any effect	or even	a spe-
       cific one is beyond the scope of	this module.

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

       CHECK_CXX_SOURCE_COMPILES(<code>	<var> [FAIL_REGEX <fail-regex>])

	  <code>       - source	code to	try to compile,	must define 'main'
	  <var>	       - variable to store whether the source code compiled
			 Will be created as an internal	cache variable.
	  <fail-regex> - fail if test output matches this regex

       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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckCXXSourceRuns
       Check if	the given C++ source code compiles and runs.

       CHECK_CXX_SOURCE_RUNS(<code> <var>)

	  <code>   - source code to try	to compile
	  <var>	   - variable to store the result
		     (1	for success, empty for failure)
		     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_INCLUDES = list of include directories
	  CMAKE_REQUIRED_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

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

       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_SYM-
       BOL_EXISTS() can	 be  used  to  check  in  C++  files,  as  opposed  to
       CHECK_SYMBOL_EXISTS(), which works only for C.

       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.	 If the	symbol is a type or enum value it will not  be	recog-
       nized (consider using CheckTypeSize or CheckCSourceCompiles).

       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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckFortranCompilerFlag
       Check whether the Fortran compiler supports a given flag.

       CHECK_Fortran_COMPILER_FLAG(<flag> <var>)

	  <flag> - the compiler	flag
	  <var>	 - variable to store the result
		   Will	be created as an internal cache	variable.

       This internally calls the check_fortran_source_compiles macro and  sets
       CMAKE_REQUIRED_DEFINITIONS to <flag>.  See help for CheckFortranSource-
       Compiles	for a listing of  variables  that  can	otherwise  modify  the
       build.	The result only	tells that the compiler	does not give an error
       message when it encounters the flag.  If	the flag  has  any  effect  or
       even a specific one is beyond the scope of this module.

   CheckFortranFunctionExists
       macro which checks if the Fortran function exists

       CHECK_FORTRAN_FUNCTION_EXISTS(FUNCTION VARIABLE)

	  FUNCTION - the name of the Fortran function
	  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_LIBRARIES = list of libraries to link

   CheckFortranSourceCompiles
       Check if	given Fortran source compiles and links	into an	executable:

	  CHECK_Fortran_SOURCE_COMPILES(<code> <var> [FAIL_REGEX <fail-regex>]
					[SRC_EXT <ext>])

       The arguments are:

       <code> Source code to try to compile.  It must define a	PROGRAM	 entry
	      point.

       <var>  Variable	to  store  whether  the	source code compiled.  Will be
	      created as an internal cache variable.

       FAIL_REGEX <fail-regex>
	      Fail if test output matches this regex.

       SRC_EXT <ext>
	      Use source extension .<ext> instead of the default .F.

       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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckFunctionExists
       Check if	a C function can be linked:

	  check_function_exists(<function> <variable>)

       Check  that  the	 <function> is provided	by libraries on	the system and
       store the result	in a <variable>. <variable> 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_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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = 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
	      list of macros to	define (-DFOO=bar)

       CMAKE_REQUIRED_INCLUDES
	      list of include directories

       CMAKE_REQUIRED_QUIET
	      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
	      list of macros to	define (-DFOO=bar)

       CMAKE_REQUIRED_INCLUDES
	      list of include directories

       CMAKE_REQUIRED_QUIET
	      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 in C.

       CHECK_INCLUDE_FILES

		 CHECK_INCLUDE_FILES("<includes>" <variable>)

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

       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_QUIET
	      execute quietly without messages

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

   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.

       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 (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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckPrototypeDefinition
       Check if	the protoype we	expect is correct.

       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 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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

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

	  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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

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

   CheckSymbolExists
       Check if	a symbol exists	as a function, variable, or macro

       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.	  If  the symbol is a type or enum value it will not be	recog-
       nized (consider using CheckTypeSize or CheckCSourceCompiles).   If  the
       check  needs  to	 be  done  in C++, consider using CHECK_CXX_SYMBOL_EX-
       ISTS(), which does the same as CHECK_SYMBOL_EXISTS(), but in C++.

       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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CheckTypeSize
       Check sizeof a type

	  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	 "${VARIABLE}"
       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	internal 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 in-
       dicates that the	type size varies across	architectures.	In  this  case
       "${VARIABLE}_CODE"  contains C preprocessor tests mapping from each ar-
       chitecture macro	to the corresponding type size.	 The list of architec-
       ture macros is stored in	"${VARIABLE}_KEYS", and	the value for each key
       is stored in "${VARIABLE}-${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 headers, thus supporting
       checks of types defined in the headers.

       If LANGUAGE is set, the specified compiler will be used to perform  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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages
	  CMAKE_EXTRA_INCLUDE_FILES = list of extra headers to include

   CheckVariableExists
       Check if	the 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_LIBRARIES = list of libraries to link
	  CMAKE_REQUIRED_QUIET = execute quietly without messages

   CMakeAddFortranSubdirectory
       Use MinGW gfortran from VS if a fortran compiler	is not found.

       The  'add_fortran_subdirectory'	function  adds	a  subdirectory	 to  a
       project that contains a fortran	only  sub-project.   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  libraries  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 the MS .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.   When	the option is not presented a default value is
       used, but any value set by the user is preserved	for when the option is
       presented again.	 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.   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  re-
       tains its old value.

   CMakeDetermineVSServicePack
       Deprecated.  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.  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}" )

   CMakeFindDependencyMacro
	  find_dependency(<dep>	[<version> [EXACT]])

       find_dependency() wraps a find_package()	call for a package dependency.
       It  is designed to be used in a <package>Config.cmake file, and it for-
       wards the correct parameters for	EXACT, QUIET and REQUIRED  which  were
       passed  to  the original	find_package() call.  It also sets an informa-
       tive diagnostic message if the dependency could not be found.

   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-
	      tan/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

   CMakeForceCompiler
       Deprecated.  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)

   CMakeGraphVizOptions
       The builtin graphviz support of CMake.

   Variables specific to the graphviz support
       CMake can generate graphviz files, showing the dependencies between the
       targets	in  a  project	and  also  external libraries which are	linked
       against.	 When CMake is run with	the --graphviz=foo.dot option, it will
       produce:

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

       o a  foo.dot.<target> file for each target, file	showing	on which other
	 targets the respective	target depends

       o a foo.dot.<target>.dependers file, showing which other	targets	depend
	 on the	respective target

       This  can  result  in  huge  graphs.   Using  the file CMakeGraphVizOp-
       tions.cmake the look and	content	of the generated graphs	can be	influ-
       enced.	This file is searched first in ${CMAKE_BINARY_DIR} and then in
       ${CMAKE_SOURCE_DIR}.  If	found, it is read and the variables set	in  it
       are used	to adjust options for the generated graphviz files.

       GRAPHVIZ_GRAPH_TYPE
	      The graph	type.

	      o	Mandatory : NO

	      o	Default	  : "digraph"

	      Valid graph types	are:

	      o	"graph"	: Nodes	are joined with	lines

	      o	"digraph" : Nodes are joined with arrows showing direction

	      o	"strict	 graph"	 :  Like "graph" but max one line between each
		node

	      o	"strict	digraph" : Like	"graph"	but max	one line between  each
		node in	each direction

       GRAPHVIZ_GRAPH_NAME
	      The graph	name.

	      o	Mandatory : NO

	      o	Default	  : "GG"

       GRAPHVIZ_GRAPH_HEADER
	      The header written at the	top of the graphviz file.

	      o	Mandatory : NO

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

       GRAPHVIZ_NODE_PREFIX
	      The prefix for each node in the graphviz file.

	      o	Mandatory : NO

	      o	Default	  : "node"

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

	      o	Mandatory : NO

	      o	Default	  : TRUE

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

	      o	Mandatory : NO

	      o	Default	  : TRUE

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

	      o	Mandatory : NO

	      o	Default	  : TRUE

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

	      o	Mandatory : NO

	      o	Default	  : TRUE

       GRAPHVIZ_EXTERNAL_LIBS
	      Set  this	to FALSE to exclude external libraries from the	gener-
	      ated graphs.

	      o	Mandatory : NO

	      o	Default	  : TRUE

       GRAPHVIZ_IGNORE_TARGETS
	      A	list of	regular	expressions for	ignoring targets.

	      o	Mandatory : NO

	      o	Default	  : empty

       GRAPHVIZ_GENERATE_PER_TARGET
	      Set this to FALSE	to exclude per target graphs foo.dot.<target>.

	      o	Mandatory : NO

	      o	Default	  : TRUE

       GRAPHVIZ_GENERATE_DEPENDERS
	      Set this to  FALSE  to  exclude  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  <Name>Config.cmake   or
       <Name>-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.

       If the INSTALL_PREFIX argument is passed, this is used as base path  to
       calculate all the relative paths.  The <path> argument must be an abso-
       lute path.  If this argument is not  passed,  the  CMAKE_INSTALL_PREFIX
       variable	will be	used instead.  The default value is good when generat-
       ing 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(<package_name>) should	be called at  the  end
       of  the	FooConfig.cmake	file if	the package supports components.  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 re-
       quired components.  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|ExactVersion> )

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

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

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

       The COMPATIBILITY mode AnyNewerVersion means that the installed package
       version	will  be  considered  compatible if it is newer	or exactly the
       same as the requested version.  This mode should	be used	 for  packages
       which  are  fully  backward compatible, also across major versions.  If
       SameMajorVersion	is used	 instead,  then	 the  behaviour	 differs  from
       AnyNewerVersion	in  that  the major version number must	be the same as
       requested, e.g.	version	2.0 will not be	considered compatible  if  1.0
       is  requested.	This  mode should be used for packages which guarantee
       backward	compatibility within the same major version.  If  ExactVersion
       is  used,  then	the  package  is only considered compatible if the re-
       quested version matches exactly its own version number (not considering
       the  tweak  version).   For example, version 1.2.3 of a package is only
       considered compatible 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 cus-
       tom ConfigVersion.cmake file instead of using this macro.

       Internally,  this macro executes	configure_file() to create the result-
       ing version file.  Depending on the COMPATIBLITY, either	the file  Bas-
       icConfigVersion-SameMajorVersion.cmake.in or BasicConfigVersion-AnyNew-
       erVersion.cmake.in is used.  Please note	that these two files  are  in-
       ternal  to CMake	and you	should not call	configure_file() on them your-
       self, but they can be used as starting point  to	 create	 more  sophis-
       ticted 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)

   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.

   CMakePrintHelpers
       Convenience  macros  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 macro 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_DIRS)

       This will print the LOCATION and	INTERFACE_INCLUDE_DIRS properties  for
       both targets foo	and bar.

       CMAKE_PRINT_VARIABLES(var1 var2 ..  varN)

       This  macro 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 file can be	used for 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_LIBRARIES,  CMAKE_REQUIRED_INCLUDES  and CMAKE_EXTRA_IN-
       CLUDE_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.

   CPackBundle
       CPack Bundle generator (Mac OS X) specific options

   Variables specific to CPack Bundle generator
       Installers built	on Mac OS X using the Bundle generator use the	afore-
       mentioned  DragNDrop (CPACK_DMG_xxx) variables, plus the	following Bun-
       dle-specific parameters (CPACK_BUNDLE_xxx).

       CPACK_BUNDLE_NAME
	      The name of the generated	bundle.	This appears in	the OSX	finder
	      as the bundle name. Required.

       CPACK_BUNDLE_PLIST
	      Path  to	an  OSX	plist file that	will be	used for the generated
	      bundle. This assumes that	the caller has generated or  specified
	      their own	Info.plist file. Required.

       CPACK_BUNDLE_ICON
	      Path  to	an OSX icon file that will be used as the icon for the
	      generated	bundle.	This is	the  icon  that	 appears  in  the  OSX
	      finder  for  the	bundle,	and in the OSX dock when the bundle is
	      opened.  Required.

       CPACK_BUNDLE_STARTUP_COMMAND
	      Path to a	startup	script.	This is	a path	to  an	executable  or
	      script  that  will be run	whenever an end-user double-clicks the
	      generated	bundle in the OSX Finder. Optional.

       CPACK_BUNDLE_APPLE_CERT_APP
	      The name of your Apple supplied code signing certificate for the
	      application.   The name usually takes the	form "Developer	ID Ap-
	      plication: [Name]" or  "3rd  Party  Mac  Developer  Application:
	      [Name]". If this variable	is not set the application will	not be
	      signed.

       CPACK_BUNDLE_APPLE_ENTITLEMENTS
	      The name of the plist file that contains your apple entitlements
	      for  sandboxing your application.	This file is required for sub-
	      mission to the Mac App Store.

       CPACK_BUNDLE_APPLE_CODESIGN_FILES
	      A	list of	additional files that you wish to be  signed.  You  do
	      not  need	 to list the main application folder, or the main exe-
	      cutable. You should list any frameworks and plugins that are in-
	      cluded in	your app bundle.

       CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER
	      Additional  parameter  that  will	 passed	 to codesign.  Default
	      value: "--deep -f"

       CPACK_COMMAND_CODESIGN
	      Path to the codesign(1) command used to sign  applications  with
	      an  Apple	 cert. This variable can be used to override the auto-
	      matically	detected command  (or  specify	its  location  if  the
	      auto-detection fails to find it.)

   CPackComponent
       Build binary and	source package installers

   Variables concerning	CPack Components
       The  CPackComponent  module  is	the module which handles the component
       part of CPack.  See CPack module	for general information	about CPack.

       For certain kinds of binary installers  (including  the	graphical  in-
       stallers	 on Mac	OS X and Windows), CPack generates installers that al-
       low users to select individual application components to	install.   The
       contents	 of each of the	components are identified by the COMPONENT ar-
       gument of CMake's INSTALL command.  These components can	 be  annotated
       with  user-friendly  names  and descriptions, inter-component dependen-
       cies, etc., and grouped in various ways to customize the	resulting  in-
       staller.	  See  the cpack_add_* commands, described below, for more in-
       formation about component-specific installations.

       Component-specific installation allows users to select specific sets of
       components  to install during the install process.  Installation	compo-
       nents are identified by the COMPONENT argument of CMake's INSTALL  com-
       mands, and should be further described by the following CPack commands:

       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.

       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 family (TGZ,	ZIP, ...) gen-
	      erates several packages files when asked for  component  packag-
	      ing.   They  group  the  component  differently depending	on the
	      value of this variable:

	      o	ONE_PER_GROUP (default): creates one package file  per	compo-
		nent group

	      o	ALL_COMPONENTS_IN_ONE :	creates	a single package with all (re-
		quested) component

	      o	IGNORE : creates one package per component, i.e. IGNORE	compo-
		nent group

	      One can specify different	grouping for different CPack generator
	      by using a CPACK_PROJECT_CONFIG_FILE.

       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.

       cpack_add_component

       Describes a CPack installation component	named by the  COMPONENT	 argu-
       ment to a CMake INSTALL command.

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

       The  cmake_add_component	 command  describes an installation component,
       which the user can opt to install or remove as part  of	the  graphical
       installation  process.	compname is the	name of	the component, as pro-
       vided to	the COMPONENT argument of one or more CMake INSTALL commands.

       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.

       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.

       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.

       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 Mac OS X, installers that download components	on-the-fly can only be
       built and installed on system using Mac OS X 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.

   CPackCygwin
       Cygwin CPack generator (Cygwin).

   Variables specific to CPack Cygwin generator
       The following variable is specific to installers	build  on  and/or  for
       Cygwin:

       CPACK_CYGWIN_PATCH_NUMBER
	      The  Cygwin  patch  number.  FIXME: This documentation is	incom-
	      plete.

       CPACK_CYGWIN_PATCH_FILE
	      The Cygwin patch file.  FIXME: This documentation	is incomplete.

       CPACK_CYGWIN_BUILD_SCRIPT
	      The Cygwin build script.	FIXME: This  documentation  is	incom-
	      plete.

   CPackDeb
       The built in (binary) CPack Deb generator (Unix only)

   Variables specific to CPack Debian (DEB) generator
       CPackDeb	 may be	used to	create Deb package using CPack.	 CPackDeb is a
       CPack generator thus it uses the	CPACK_XXX variables used by CPack.

       CPackDeb	generator should work on any Linux host	but  it	 will  produce
       better  deb  package  when Debian specific tools	dpkg-xxx are usable on
       the build system.

       CPackDeb	has specific features which are	controlled  by	the  specifics
       CPACK_DEBIAN_XXX	variables.

       CPACK_DEBIAN_<COMPONENT>_XXXX  variables	 may  be used in order to have
       component specific values.  Note	however	that <COMPONENT> refers	to the
       grouping	 name written in upper case. It	may be either a	component name
       or a component GROUP name.

       Here are	some CPackDeb wiki resources that are here for	historic  rea-
       sons and	are no longer maintained but may still prove useful:

	  o https://cmake.org/Wiki/CMake:CPackConfiguration

	  o https://cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29

       List of CPackDEB	specific variables:

       CPACK_DEB_COMPONENT_INSTALL
	      Enable component packaging for CPackDEB

	      o	Mandatory : NO

	      o	Default	  : OFF

	      If enabled (ON) multiple packages	are generated.	By  default  a
	      single package containing	files of all components	is generated.

       CPACK_DEBIAN_PACKAGE_NAME

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME
	      Set Package control field	(variable is automatically transformed
	      to lower case).

	      o	Mandatory : YES

	      o	Default	  :

		o CPACK_PACKAGE_NAME for non-component based installations

		o CPACK_DEBIAN_PACKAGE_NAME  suffixed  with  -<COMPONENT>  for
		  component-based installations.

	      See
	      https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

       CPACK_DEBIAN_FILE_NAME

       CPACK_DEBIAN_<COMPONENT>_FILE_NAME
	      Package file name.

	      o	Mandatory : YES

	      o	Default	  : <CPACK_PACKAGE_FILE_NAME>[-<component>].deb

	      This  may	 be  set  to DEB-DEFAULT to allow CPackDeb to generate
	      package file name	by itself in deb format:

		 <PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

	      Alternatively provided package file name must end	with .deb suf-
	      fix.

	      NOTE:
		 Preferred  setting  of	 this  variable	is DEB-DEFAULT but for
		 backward compatibility	with CPackDeb in CMake prior  to  ver-
		 sion 3.6 this feature is disabled by default.

	      NOTE:
		 By using non default filenames	duplicate names	may occur. Du-
		 plicate files get overwritten and it is up to the packager to
		 set the variables in a	manner that will prevent such errors.

       CPACK_DEBIAN_PACKAGE_VERSION
	      The Debian package version

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_VERSION

       CPACK_DEBIAN_PACKAGE_RELEASE
	      The Debian package release - Debian revision number.

	      o	Mandatory : YES

	      o	Default	  : 1

	      This  is	the numbering of the DEB package itself, i.e. the ver-
	      sion of the packaging and	not the	version	of  the	 content  (see
	      CPACK_DEBIAN_PACKAGE_VERSION).  One may change the default value
	      if the previous packaging	was buggy and/or you want to put  here
	      a	fancy Linux distro specific numbering.

       CPACK_DEBIAN_PACKAGE_ARCHITECTURE

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE
	      The Debian package architecture

	      o	Mandatory : YES

	      o	Default	   :  Output  of dpkg --print-architecture (or i386 if
		dpkg is	not found)

       CPACK_DEBIAN_PACKAGE_DEPENDS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS
	      Sets the Debian dependencies of this package.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_DEPENDS for  component-based  installa-
		  tions.

	      NOTE:
		 If   CPACK_DEBIAN_PACKAGE_SHLIBDEPS   or   more  specifically
		 CPACK_DEBIAN__COMPONENT__PACKAGE_SHLIBDEPS is	set  for  this
		 component,  the  discovered  dependencies will	be appended to
		 CPACK_DEBIAN__COMPONENT__PACKAGE_DEPENDS      instead	    of
		 CPACK_DEBIAN_PACKAGE_DEPENDS.				    If
		 CPACK_DEBIAN__COMPONENT__PACKAGE_DEPENDS is an	empty  string,
		 only  the  automatically  discovered dependencies will	be set
		 for this component.

	      Example:

		 set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libc6 (<	2.4)")

       CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS
	      Sets inter component dependencies	if  listed  with  CPACK_COMPO-
	      NENT_<compName>_DEPENDS variables.

	      o	Mandatory : NO

	      o	Default	  : -

       CPACK_DEBIAN_PACKAGE_MAINTAINER
	      The Debian package maintainer

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_CONTACT

       CPACK_DEBIAN_PACKAGE_DESCRIPTION

       CPACK_COMPONENT_<COMPONENT>_DESCRIPTION
	      The Debian package description

	      o	Mandatory : YES

	      o	Default	  :

		o CPACK_DEBIAN_PACKAGE_DESCRIPTION if set or

		o CPACK_PACKAGE_DESCRIPTION_SUMMARY

       CPACK_DEBIAN_PACKAGE_SECTION

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION
	      Set Section control field	e.g. admin, devel, doc,	...

	      o	Mandatory : YES

	      o	Default	  : "devel"

	      See
	      https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

       CPACK_DEBIAN_ARCHIVE_TYPE
	      The archive format used for creating the Debian package.

	      o	Mandatory : YES

	      o	Default	  : "paxr"

	      Possible values are:

	      o	paxr

	      o	gnutar

	      NOTE:
		 Default  pax  archive	format is the most portable format and
		 generates packages that do not	treat sparse files  specially.
		 GNU tar format	on the other hand supports longer filenames.

       CPACK_DEBIAN_COMPRESSION_TYPE
	      The compression used for creating	the Debian package.

	      o	Mandatory : YES

	      o	Default	  : "gzip"

	      Possible values are:

	      o	lzma

	      o	xz

	      o	bzip2

	      o	gzip

       CPACK_DEBIAN_PACKAGE_PRIORITY

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY
	      Set  Priority  control field e.g.	required, important, standard,
	      optional,	extra

	      o	Mandatory : YES

	      o	Default	  : "optional"

	      See
	      https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

       CPACK_DEBIAN_PACKAGE_HOMEPAGE
	      The URL of the web site for this package,	preferably  (when  ap-
	      plicable)	 the  site  from  which	the original source can	be ob-
	      tained and any additional	upstream documentation or  information
	      may be found.

	      o	Mandatory : NO

	      o	Default	  : -

	      NOTE:
		 The  content  of  this	field is a simple URL without any sur-
		 rounding characters such as <>.

       CPACK_DEBIAN_PACKAGE_SHLIBDEPS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS
	      May be set to ON in order	to use dpkg-shlibdeps to generate bet-
	      ter package dependency list.

	      o	Mandatory : NO

	      o	Default	  :

		o CPACK_DEBIAN_PACKAGE_SHLIBDEPS if set	or

		o OFF

	      NOTE:
		 You  may need set CMAKE_INSTALL_RPATH to an appropriate value
		 if you	use this feature, because if you don't	dpkg-shlibdeps
		 may	fail	to   find   your   own	 shared	  libs.	   See
		 https://cmake.org/Wiki/CMake_RPATH_handling.

       CPACK_DEBIAN_PACKAGE_DEBUG
	      May be set when invoking cpack in	order to trace debug  informa-
	      tion during CPackDeb run.

	      o	Mandatory : NO

	      o	Default	  : -

       CPACK_DEBIAN_PACKAGE_PREDEPENDS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS
	      Sets the Pre-Depends field of the	Debian package.	 Like Depends,
	      except that it also forces dpkg to complete installation of  the
	      packages	named  before  even  starting  the installation	of the
	      package which declares the pre-dependency.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_PREDEPENDS for component-based  instal-
		  lations.

	      See
	      http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

       CPACK_DEBIAN_PACKAGE_ENHANCES

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES
	      Sets  the	 Enhances  field  of  the  Debian package.  Similar to
	      Suggests but works in the	opposite direction:  declares  that  a
	      package can enhance the functionality of another package.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_ENHANCES	 for component-based installa-
		  tions.

	      See
	      http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

       CPACK_DEBIAN_PACKAGE_BREAKS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS
	      Sets the Breaks field of the  Debian  package.   When  a	binary
	      package  (P)  declares  that  it breaks other packages (B), dpkg
	      will not allow the package (P) which declares Breaks be unpacked
	      unless  the  packages  that  will	be broken (B) are deconfigured
	      first.  As long as the package (P) is configured,	the previously
	      deconfigured packages (B)	cannot be reconfigured again.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_BREAKS  for  component-based  installa-
		  tions.

	      See
	      https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks

       CPACK_DEBIAN_PACKAGE_CONFLICTS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS
	      Sets the Conflicts field of the Debian package.  When one	binary
	      package  declares	 a  conflict  with  another  using a Conflicts
	      field, dpkg will not allow them to be unpacked on	the system  at
	      the same time.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_CONFLICTS for component-based installa-
		  tions.

	      See
	      https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

	      NOTE:
		 This is a stronger restriction	than  Breaks,  which  prevents
		 the  broken  package from being configured while the breaking
		 package is in the "Unpacked" state but	allows	both  packages
		 to be unpacked	at the same time.

       CPACK_DEBIAN_PACKAGE_PROVIDES

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES
	      Sets  the	Provides field of the Debian package.  A virtual pack-
	      age is one which appears in the Provides control	field  of  an-
	      other package.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_PROVIDES	 for component-based installa-
		  tions.

	      See
	      https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

       CPACK_DEBIAN_PACKAGE_REPLACES

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES
	      Sets the Replaces	field of the Debian package.  Packages can de-
	      clare  in	their control file that	they should overwrite files in
	      certain other packages, or completely replace other packages.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_REPLACES	for component-based  installa-
		  tions.

	      See
	      http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

       CPACK_DEBIAN_PACKAGE_RECOMMENDS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS
	      Sets  the	 Recommends field of the Debian	package.  Allows pack-
	      ages to declare a	strong,	but not	absolute, dependency on	 other
	      packages.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_RECOMMENDS  for component-based instal-
		  lations.

	      See
	      http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

       CPACK_DEBIAN_PACKAGE_SUGGESTS

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS
	      Sets the Suggests	field of the Debian package.  Allows  packages
	      to declare a suggested package install grouping.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_SUGGESTS	 for component-based installa-
		  tions.

	      See
	      http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

       CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS

	      o	Mandatory : NO

	      o	Default	  : OFF

	      Allows to	generate shlibs	control	file  automatically.  Compati-
	      bility is	defined	by CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY
	      variable value.

	      NOTE:
		 Libraries are only considered if they have both library  name
		 and  version set. This	can be done by setting SOVERSION prop-
		 erty with set_target_properties() command.

       CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY
	      Compatibility policy for auto-generated shlibs control file.

	      o	Mandatory : NO

	      o	Default	  : "="

	      Defines compatibility policy for auto-generated  shlibs  control
	      file.  Possible values: "=", ">="

	      See
	      https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps

       CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA
	      This  variable  allow  advanced user to add custom script	to the
	      control.tar.gz.	Typical	 usage	is  for	 conffiles,  postinst,
	      postrm, prerm.

	      o	Mandatory : NO

	      o	Default	  : -

	      Usage:

		 set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
		     "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")

	      NOTE:
		 The original permissions of the files will be used in the fi-
		 nal	    package	   unless	  the	      variable
		 CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION	 is  set.   In
		 particular, the scripts should	 have  the  proper  executable
		 flag prior to the generation of the package.

       CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION
	      This  variable  indicates	 if the	Debian policy on control files
	      should be	strictly followed.

	      o	Mandatory : NO

	      o	Default	  : FALSE

	      Usage:

		 set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)

	      NOTE:
		 This overrides	the permissions	on the original	files, follow-
		 ing	  the	   rules      set     by     Debian	policy
		 https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

       CPACK_DEBIAN_PACKAGE_SOURCE

       CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE
	      Sets  the	 Source	 field of the binary Debian package.  When the
	      binary package name is not the same as the source	 package  name
	      (in  particular  when  several components/binaries are generated
	      from one source) the source from which the binary	has been  gen-
	      erated should be indicated with the field	Source.

	      o	Mandatory : NO

	      o	Default	  :

		o An empty string for non-component based installations

		o CPACK_DEBIAN_PACKAGE_SOURCE  for  component-based  installa-
		  tions.

	      See
	      https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

	      NOTE:
		 This value is not interpreted.	It is possible to pass an  op-
		 tional	 revision  number  of the referenced source package as
		 well.

   CPackDMG
       DragNDrop CPack generator (Mac OS X).

   Variables specific to CPack DragNDrop generator
       The following variables are specific to the DragNDrop installers	 built
       on Mac OS X:

       CPACK_DMG_VOLUME_NAME
	      The  volume  name	 of  the  generated  disk  image.  Defaults to
	      CPACK_PACKAGE_FILE_NAME.

       CPACK_DMG_FORMAT
	      The disk image format. Common values are UDRO (UDIF  read-only),
	      UDZO (UDIF zlib-compressed) or UDBZ (UDIF	bzip2-compressed). Re-
	      fer to hdiutil(1)	for more information on	other  available  for-
	      mats. Defaults to	UDZO.

       CPACK_DMG_DS_STORE
	      Path  to a custom	DS_Store file. This .DS_Store file e.g.	can be
	      used to specify the Finder window	position/geometry  and	layout
	      (such  as	 hidden	 toolbars,  placement of the icons etc.). This
	      file has to be generated	by  the	 Finder	 (either  manually  or
	      through  AppleScript)  using  a  normal  folder  from  which the
	      .DS_Store	file can then be extracted.

       CPACK_DMG_DS_STORE_SETUP_SCRIPT
	      Path to a	custom AppleScript file.  This AppleScript is used  to
	      generate	a .DS_Store file which specifies the Finder window po-
	      sition/geometry and layout (such as hidden  toolbars,  placement
	      of the icons etc.).  By specifying a custom AppleScript there is
	      no need to use CPACK_DMG_DS_STORE, as the	.DS_Store that is gen-
	      erated by	the AppleScript	will be	packaged.

       CPACK_DMG_BACKGROUND_IMAGE
	      Path  to	an image file to be used as the	background.  This file
	      will be copied to	.background/background.<ext>, where ext	is the
	      original	image  file  extension.	  The  background image	is in-
	      stalled into the image before CPACK_DMG_DS_STORE_SETUP_SCRIPT is
	      executed	or  CPACK_DMG_DS_STORE	is  installed.	 By default no
	      background image is set.

       CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK
	      Default behaviour	is to include a	symlink	 to  /Applications  in
	      the DMG.	Set this option	to ON to avoid adding the symlink.

       CPACK_DMG_SLA_DIR
	      Directory	 where	license	and menu files for different languages
	      are stored.  Setting this	causes	CPack  to  look	 for  a	 <lan-
	      guage>.menu.txt  and  <language>.license.txt file	for every lan-
	      guage defined in CPACK_DMG_SLA_LANGUAGES.	If both	this  variable
	      and  CPACK_RESOURCE_FILE_LICENSE	are  set, CPack	will only look
	      for the menu files and use the same license file	for  all  lan-
	      guages.

       CPACK_DMG_SLA_LANGUAGES
	      Languages	 for which a license agreement is provided when	mount-
	      ing the generated	DMG. A menu file consists of 9 lines of	 text.
	      The first	line is	is the name of the language itself, uppercase,
	      in English (e.g. German).	 The other lines are  translations  of
	      the following strings:

	      o	Agree

	      o	Disagree

	      o	Print

	      o	Save...

	      o	You agree to the terms of the License Agreement	when you click
		the "Agree" button.

	      o	Software License Agreement

	      o	This text cannot be saved. The disk may	be full	or locked,  or
		the file may be	locked.

	      o	Unable to print. Make sure you have selected a printer.

	      For  every  language  in this list, CPack	will try to find files
	      <language>.menu.txt and <language>.license.txt in	the  directory
	      specified	by the CPACK_DMG_SLA_DIR variable.

       CPACK_COMMAND_HDIUTIL
	      Path  to	the  hdiutil(1)	 command used to operate on disk image
	      files on Mac OS X. This variable can be used to override the au-
	      tomatically  detected  command  (or  specify its location	if the
	      auto-detection fails to find it.)

       CPACK_COMMAND_SETFILE
	      Path to the SetFile(1) command used to set  extended  attributes
	      on  files	and directories	on Mac OS X. This variable can be used
	      to override the automatically detected command (or  specify  its
	      location if the auto-detection fails to find it.)

       CPACK_COMMAND_REZ
	      Path  to	the Rez(1) command used	to compile resources on	Mac OS
	      X. This variable can be used to override the  automatically  de-
	      tected  command  (or  specify its	location if the	auto-detection
	      fails to find it.)

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

   Overview
       CPack IFW generator helps you  to  create  online  and  offline	binary
       cross-platform installers with a	graphical user interface.

       CPack IFW generator prepares project installation and generates config-
       uration and meta	information for	QtIFW tools.

       The QtIFW provides a set	of tools and utilities	to  create  installers
       for  the	 supported desktop Qt platforms: Linux,	Microsoft Windows, and
       Mac OS X.

       You should also install QtIFW to	use CPack IFW generator.  If you don't
       use  a  default	path for the installation, please set the used path in
       the variable QTIFWDIR.

   Variables
       You can use the following variables to change  behavior	of  CPack  IFW
       generator.

   Debug
       CPACK_IFW_VERBOSE
	      Set to ON	to enable addition debug output.  By default is	OFF.

   Package
       CPACK_IFW_PACKAGE_TITLE
	      Name of the installer as displayed on the	title bar.  By default
	      used CPACK_PACKAGE_DESCRIPTION_SUMMARY.

       CPACK_IFW_PACKAGE_PUBLISHER
	      Publisher	of the software	 (as  shown  in	 the  Windows  Control
	      Panel).  By default used CPACK_PACKAGE_VENDOR.

       CPACK_IFW_PRODUCT_URL
	      URL  to  a  page	that  contains product information on your web
	      site.

       CPACK_IFW_PACKAGE_ICON
	      Filename for a custom installer icon. The	actual file is '.icns'
	      (Mac OS X), '.ico' (Windows). No functionality on	Unix.

       CPACK_IFW_PACKAGE_WINDOW_ICON
	      Filename	for  a	custom	window	icon in	PNG format for the In-
	      staller application.

       CPACK_IFW_PACKAGE_LOGO
	      Filename for a logo is used as QWizard::LogoPixmap.

       CPACK_IFW_PACKAGE_WATERMARK
	      Filename for a watermark is used as QWizard::WatermarkPixmap.

       CPACK_IFW_PACKAGE_BANNER
	      Filename for a banner is used as QWizard::BannerPixmap.

       CPACK_IFW_PACKAGE_BACKGROUND
	      Filename for an image used  as  QWizard::BackgroundPixmap	 (only
	      used by MacStyle).

       CPACK_IFW_PACKAGE_WIZARD_STYLE
	      Wizard style to be used ("Modern", "Mac",	"Aero" or "Classic").

       CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH
	      Default  width  of  the wizard in	pixels.	Setting	a banner image
	      will override this.

       CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT
	      Default height of	the wizard in pixels. Setting a	watermark  im-
	      age will override	this.

       CPACK_IFW_PACKAGE_TITLE_COLOR
	      Color  of	 the  titles  and subtitles (takes an HTML color code,
	      such as "#88FF33").

       CPACK_IFW_PACKAGE_START_MENU_DIRECTORY
	      Name of the default program group	for the	product	in the Windows
	      Start menu.

	      By default used CPACK_IFW_PACKAGE_NAME.

       CPACK_IFW_TARGET_DIRECTORY
	      Default  target  directory  for  installation.   By default used
	      "@ApplicationsDir@/CPACK_PACKAGE_INSTALL_DIRECTORY"

	      You can use predefined variables.

       CPACK_IFW_ADMIN_TARGET_DIRECTORY
	      Default target directory	for  installation  with	 administrator
	      rights.

	      You can use predefined variables.

       CPACK_IFW_PACKAGE_GROUP
	      The group, which will be used to configure the root package

       CPACK_IFW_PACKAGE_NAME
	      The root package name, which will	be used	if configuration group
	      is not specified

       CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME
	      Filename of the generated	maintenance tool.   The	 platform-spe-
	      cific executable file extension is appended.

	      By default used QtIFW defaults (maintenancetool).

       CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE
	      Filename	for  the  configuration	 of  the generated maintenance
	      tool.

	      By default used QtIFW defaults (maintenancetool.ini).

       CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS
	      Set to ON	if the installation path can contain non-ASCII charac-
	      ters.

	      Is ON for	QtIFW less 2.0 tools.

       CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH
	      Set to OFF if the	installation path cannot contain space charac-
	      ters.

	      Is ON for	QtIFW less 2.0 tools.

       CPACK_IFW_PACKAGE_CONTROL_SCRIPT
	      Filename for a custom installer control script.

       CPACK_IFW_PACKAGE_RESOURCES
	      List of additional resources ('.qrc' files) to  include  in  the
	      installer	binary.

	      You can use cpack_ifw_add_package_resources() command to resolve
	      relative paths.

       CPACK_IFW_REPOSITORIES_ALL
	      The list of remote repositories.

	      The default value	of this	variable is computed by	CPack and con-
	      tains	 all	  repositories	    added     with     command
	      cpack_ifw_add_repository()    or	  updated     with     command
	      cpack_ifw_update_repository().

       CPACK_IFW_DOWNLOAD_ALL
	      If  this is ON all components will be downloaded.	 By default is
	      OFF or used value	from CPACK_DOWNLOAD_ALL	if set

   Components
       CPACK_IFW_RESOLVE_DUPLICATE_NAMES
	      Resolve duplicate	names when installing components with groups.

       CPACK_IFW_PACKAGES_DIRECTORIES
	      Additional prepared packages dirs	that will be used  to  resolve
	      dependent	components.

   Tools
       CPACK_IFW_FRAMEWORK_VERSION
	      The version of used QtIFW	tools.

       CPACK_IFW_BINARYCREATOR_EXECUTABLE
	      The path to "binarycreator" command line client.

	      This variable is cached and can be configured user if need.

       CPACK_IFW_REPOGEN_EXECUTABLE
	      The path to "repogen" command line client.

	      This variable is cached and can be configured user if need.

   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>]
				     [DESCRIPTION <description>]
				     [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> ...])

	      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
		     if	 set,  then  the  package manager stays	disabled until
		     that component is updated.

	      VIRTUAL
		     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
		     if	set, then the component	must always be installed.   It
		     is	  a   equivalent  of  the  REQUARED  option  from  the
		     cpack_add_component() command.

	      REQUIRES_ADMIN_RIGHTS
		     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
		     set to rewrite original name configured by	cpack_add_com-
		     ponent() command.

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

	      UPDATE_TEXT
		     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
		     keep empty	to auto	generate.

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

	      PRIORITY | SORTING_PRIORITY
		     is	 priority  of the component in the tree.  The PRIORITY
		     option is deprecated and will be removed in a future ver-
		     sion  of  CMake.  Please  use SORTING_PRIORITY option in-
		     stead.

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

	      AUTO_DEPEND_ON
		     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
		     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
		     is	a list of <file_path> ('.ui' files) representing pages
		     to	load.

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

       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>]
				     [DESCRIPTION <description>]
				     [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> ...])

	      This command should be called after  cpack_add_component_group()
	      command.

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

	      FORCED_INSTALLATION
		     if	set, then the group must always	be installed.

	      REQUIRES_ADMIN_RIGHTS
		     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
		     set to rewrite original name configured by	cpack_add_com-
		     ponent_group() command.

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

	      UPDATE_TEXT
		     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
		     keep empty	to auto	generate.

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

	      PRIORITY | SORTING_PRIORITY
		     is	priority of the	component group	in the tree.  The PRI-
		     ORITY  option  is deprecated and will be removed in a fu-
		     ture version of CMake. Please use SORTING_PRIORITY	option
		     instead.

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

	      AUTO_DEPEND_ON
		     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
		     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
		     is	a list of <file_path> ('.ui' files) representing pages
		     to	load.

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

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

   Example usage
	  set(CPACK_PACKAGE_NAME "MyPackage")
	  set(CPACK_PACKAGE_DESCRIPTION_SUMMARY	"MyPackage Installation	Example")
	  set(CPACK_PACKAGE_VERSION "1.0.0") # Version of installer

	  include(CPack)
	  include(CPackIFW)

	  cpack_add_component(myapp
	      DISPLAY_NAME "MyApp"
	      DESCRIPTION "My Application")
	  cpack_ifw_configure_component(myapp
	      VERSION "1.2.3" #	Version	of component
	      SCRIPT "operations.qs")
	  cpack_add_component(mybigplugin
	      DISPLAY_NAME "MyBigPlugin"
	      DESCRIPTION "My Big Downloadable Plugin"
	      DOWNLOADED)
	  cpack_ifw_add_repository(myrepo
	      URL "http://example.com/ifw/repo/myapp"
	      DISPLAY_NAME "My Application Repository")

   Online installer
       By default CPack	IFW generator makes offline installer. This means that
       all components will be packaged into a binary file.

       To  make	 a component downloaded, you must set the DOWNLOADED option in
       cpack_add_component().

       Then you	would use the command cpack_configure_downloads().  If you set
       ALL option all components will be downloaded.

       You  also  can  use  command  cpack_ifw_add_repository()	 and  variable
       CPACK_IFW_DOWNLOAD_ALL for more specific	configuration.

       CPack IFW generator creates "repository"	dir in current binary dir. You
       would copy content of this dir to specified site	(url).

   See Also
       Qt Installer Framework Manual:

       o Index page: http://doc.qt.io/qtinstallerframework/index.html

       o Component						    Scripting:
	 http://doc.qt.io/qtinstallerframework/scripting.html

       o Predefined						    Variables:
	 http://doc.qt.io/qtinstallerframework/scripting.html#predefined-variables

       o Promoting						      Updates:
	 http://doc.qt.io/qtinstallerframework/ifw-updates.html

       Download	Qt Installer Framework for you platform	from Qt	site:
	      http://download.qt.io/official_releases/qt-installer-framework

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

   CPackNSIS
       CPack NSIS generator specific options

   Variables specific to CPack NSIS generator
       The following variables are specific to the graphical installers	 built
       on Windows using	the Nullsoft Installation System.

       CPACK_NSIS_INSTALL_ROOT
	      The  default installation	directory presented to the end user by
	      the NSIS installer is under this root dir.  The  full  directory
	      presented	   to	 the	end    user    is:    ${CPACK_NSIS_IN-
	      STALL_ROOT}/${CPACK_PACKAGE_INSTALL_DIRECTORY}

       CPACK_NSIS_MUI_ICON
	      An icon filename.	 The name of a *.ico file  used	 as  the  main
	      icon for the generated install program.

       CPACK_NSIS_MUI_UNIICON
	      An  icon	filename.   The	 name of a *.ico file used as the main
	      icon for the generated uninstall program.

       CPACK_NSIS_INSTALLER_MUI_ICON_CODE
	      undocumented.

       CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP
	      The filename of a	bitmap to use as the  NSIS  MUI_WELCOMEFINISH-
	      PAGE_BITMAP.

       CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP
	      The filename of a	bitmap to use as the NSIS MUI_UNWELCOMEFINISH-
	      PAGE_BITMAP.

       CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS
	      Extra NSIS commands that will be added to	the beginning  of  the
	      install  Section,	 before	 your install tree is available	on the
	      target system.

       CPACK_NSIS_EXTRA_INSTALL_COMMANDS
	      Extra NSIS commands that will be added to	the end	of the install
	      Section, after your install tree is available on the target sys-
	      tem.

       CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
	      Extra NSIS commands that will be added to	the uninstall Section,
	      before your install tree is removed from the target system.

       CPACK_NSIS_COMPRESSOR
	      The arguments that will be passed	to the NSIS SetCompressor com-
	      mand.

       CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL
	      Ask about	uninstalling previous versions first.  If this is  set
	      to "ON", then an installer will look for previous	installed ver-
	      sions and	if one is found, ask the user whether to uninstall  it
	      before proceeding	with the install.

       CPACK_NSIS_MODIFY_PATH
	      Modify  PATH toggle.  If this is set to "ON", then an extra page
	      will appear in the installer that	will allow the user to	choose
	      whether the program directory should be added to the system PATH
	      variable.

       CPACK_NSIS_DISPLAY_NAME
	      The display name string that appears in the  Windows  Add/Remove
	      Program control panel

       CPACK_NSIS_PACKAGE_NAME
	      The title	displayed at the top of	the installer.

       CPACK_NSIS_INSTALLED_ICON_NAME
	      A	path to	the executable that contains the installer icon.

       CPACK_NSIS_HELP_LINK
	      URL to a web site	providing assistance in	installing your	appli-
	      cation.

       CPACK_NSIS_URL_INFO_ABOUT
	      URL to a web site	providing more information about your applica-
	      tion.

       CPACK_NSIS_CONTACT
	      Contact information for questions	and comments about the instal-
	      lation process.

       CPACK_NSIS_<compName>_INSTALL_DIRECTORY
	      Custom install directory for the specified component  <compName>
	      instead of $INSTDIR.

       CPACK_NSIS_CREATE_ICONS_EXTRA
	      Additional NSIS commands for creating start menu shortcuts.

       CPACK_NSIS_DELETE_ICONS_EXTRA
	      Additional NSIS commands to uninstall start menu shortcuts.

       CPACK_NSIS_EXECUTABLES_DIRECTORY
	      Creating	NSIS  start  menu links	assumes	that they are in 'bin'
	      unless this variable is set.  For	example, you would set this to
	      'exec' if	your executables are in	an exec	directory.

       CPACK_NSIS_MUI_FINISHPAGE_RUN
	      Specify an executable to add an option to	run on the finish page
	      of the NSIS installer.

       CPACK_NSIS_MENU_LINKS
	      Specify links in [application] menu.  This should	contain	a list
	      of  pair	"link"	"link  name". The link may be an URL or	a path
	      relative to installation prefix.	Like:

		 set(CPACK_NSIS_MENU_LINKS
		     "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
		     "CMake Help" "https://cmake.org" "CMake Web Site")

   CPackPackageMaker
       PackageMaker CPack generator (Mac OS X).

   Variables specific to CPack PackageMaker generator
       The following variable is specific to installers	built on Mac OS	X  us-
       ing PackageMaker:

       CPACK_OSX_PACKAGE_VERSION
	      The  version of Mac OS X that the	resulting PackageMaker archive
	      should be	compatible with. Different versions of Mac OS  X  sup-
	      port  different features.	For example, CPack can only build com-
	      ponent-based installers for Mac OS X 10.4	or newer, and can only
	      build  installers	that download component	son-the-fly for	Mac OS
	      X	10.5 or	newer. If left blank, this value will be  set  to  the
	      minimum  version	of  Mac	 OS X that supports the	requested fea-
	      tures. Set this variable to some value (e.g., 10.4) only if  you
	      want  to guarantee that your installer will work on that version
	      of Mac OS	X, and don't mind missing extra	features available  in
	      the installer shipping with later	versions of Mac	OS X.

   CPackProductBuild
       productbuild CPack generator (Mac OS X).

   Variables specific to CPack productbuild generator
       The  following variable is specific to installers built on Mac OS X us-
       ing productbuild:

       CPACK_COMMAND_PRODUCTBUILD
	      Path to the productbuild(1) command used to generate  a  product
	      archive  for the OS X Installer or Mac App Store.	 This variable
	      can be used to override the automatically	detected  command  (or
	      specify its location if the auto-detection fails to find it.)

       CPACK_PRODUCTBUILD_IDENTITY_NAME
	      Adds a digital signature to the resulting	package.

       CPACK_PRODUCTBUILD_KEYCHAIN_PATH
	      Specify a	specific keychain to search for	the signing identity.

       CPACK_COMMAND_PKGBUILD
	      Path  to the pkgbuild(1) command used to generate	an OS X	compo-
	      nent package on OS X.  This variable can be used to override the
	      automatically  detected  command (or specify its location	if the
	      auto-detection fails to find it.)

       CPACK_PKGBUILD_IDENTITY_NAME
	      Adds a digital signature to the resulting	package.

       CPACK_PKGBUILD_KEYCHAIN_PATH
	      Specify a	specific keychain to search for	the signing identity.

   CPackRPM
       The built in (binary) CPack RPM generator (Unix only)

   Variables specific to CPack RPM generator
       CPackRPM	may be used to create RPM packages using CPack.	 CPackRPM is a
       CPack generator thus it uses the	CPACK_XXX variables used by CPack.

       CPackRPM	 has  specific	features which are controlled by the specifics
       CPACK_RPM_XXX variables.

       CPACK_RPM_<COMPONENT>_XXXX variables may	be used	in order to have  com-
       ponent  specific	 values.   Note	however	that <COMPONENT> refers	to the
       grouping	name written in	upper case. It may be either a component  name
       or  a  component	 GROUP name. Usually those variables correspond	to RPM
       spec file entities. One may find	 information  about  spec  files  here
       http://www.rpm.org/wiki/Docs

       NOTE:
	  _COMPONENT_  part of variables is preferred to be in upper case (for
	  e.g. if component is named foo then use CPACK_RPM_FOO_XXXX  variable
	  name format) as is with other	CPACK__COMPONENT__XXXX variables.  For
	  the purposes of back	compatibility  (CMake/CPack  version  3.5  and
	  lower)  support  for same cased component (e.g. fOo would be used as
	  CPACK_RPM_fOo_XXXX) is still	supported  for	variables  defined  in
	  older	 versions  of  CMake/CPack but is not guaranteed for variables
	  that will be added in	the future. For	the sake of back compatibility
	  same	cased  component  variables also override upper	cased versions
	  where	both are present.

       Here are	some CPackRPM wiki resources that are here for	historic  rea-
       sons and	are no longer maintained but may still prove useful:

	  o https://cmake.org/Wiki/CMake:CPackConfiguration

	  o https://cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29

       List of CPackRPM	specific variables:

       CPACK_RPM_COMPONENT_INSTALL
	      Enable component packaging for CPackRPM

	      o	Mandatory : NO

	      o	Default	  : OFF

	      If enabled (ON) multiple packages	are generated.	By  default  a
	      single package containing	files of all components	is generated.

       CPACK_RPM_PACKAGE_SUMMARY

       CPACK_RPM_<component>_PACKAGE_SUMMARY
	      The RPM package summary.

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_DESCRIPTION_SUMMARY

       CPACK_RPM_PACKAGE_NAME

       CPACK_RPM_<component>_PACKAGE_NAME
	      The RPM package name.

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_NAME

       CPACK_RPM_FILE_NAME

       CPACK_RPM_<component>_FILE_NAME
	      Package file name.

	      o	Mandatory : YES

	      o

		Default
		       <CPACK_PACKAGE_FILE_NAME>[-<component>].rpm with	spaces
		       replaced	by '-'

	      This may be set to RPM-DEFAULT to	allow rpmbuild tool to	gener-
	      ate package file name by itself.	Alternatively provided package
	      file name	must end with .rpm suffix.

	      NOTE:
		 By using user provided	spec file, rpm macro  extensions  such
		 as  for generating debuginfo packages or by simply using mul-
		 tiple components more than one	rpm file may be	generated, ei-
		 ther  from  a	single	spec  file or from multiple spec files
		 (each component execution produces it's own spec  file).   In
		 such cases duplicate file names may occur as a	result of this
		 variable setting or spec file	content	 structure.  Duplicate
		 files get overwritten and it is up to the packager to set the
		 variables in a	manner that will prevent such errors.

       CPACK_RPM_MAIN_COMPONENT
	      Main component that is packaged without component	suffix.

	      o	Mandatory : NO

	      o	Default	  : -

	      This variable can	be set to any component	or group name so  that
	      component	 or  group  rpm	package	is generated without component
	      suffix in	filename and package name.

       CPACK_RPM_PACKAGE_VERSION
	      The RPM package version.

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_VERSION

       CPACK_RPM_PACKAGE_ARCHITECTURE

       CPACK_RPM_<component>_PACKAGE_ARCHITECTURE
	      The RPM package architecture.

	      o	Mandatory : YES

	      o	Default	  : Native architecture	output by uname	-m

	      This may be set to noarch	if you know you	are building a	noarch
	      package.

       CPACK_RPM_PACKAGE_RELEASE
	      The RPM package release.

	      o	Mandatory : YES

	      o	Default	  : 1

	      This  is	the numbering of the RPM package itself, i.e. the ver-
	      sion of the packaging and	not the	version	of  the	 content  (see
	      CPACK_RPM_PACKAGE_VERSION).  One may change the default value if
	      the previous packaging was buggy and/or you want to put  here  a
	      fancy Linux distro specific numbering.

       NOTE:
	  This	is the string that goes	into the RPM Release: field. Some dis-
	  tros (e.g. Fedora, CentOS) require 1%{?dist} format and not  just  a
	  number.      %{?dist}	   part	   can	  be	added	 by    setting
	  CPACK_RPM_PACKAGE_RELEASE_DIST.

       CPACK_RPM_PACKAGE_RELEASE_DIST
	      The dist tag that	is added  RPM Release: field.

	      o	Mandatory : NO

	      o	Default	  : OFF

	      This is the reported %{dist} tag from the	 current  distribution
	      or  empty	 %{dist}  if RPM macro is not set. If this variable is
	      set then RPM Release: field value	is  set	 to  ${CPACK_RPM_PACK-
	      AGE_RELEASE}%{?dist}.

       CPACK_RPM_PACKAGE_LICENSE
	      The RPM package license policy.

	      o	Mandatory : YES

	      o	Default	  : "unknown"

       CPACK_RPM_PACKAGE_GROUP

       CPACK_RPM_<component>_PACKAGE_GROUP
	      The RPM package group.

	      o	Mandatory : YES

	      o	Default	  : "unknown"

       CPACK_RPM_PACKAGE_VENDOR
	      The RPM package vendor.

	      o	Mandatory : YES

	      o	Default	  : CPACK_PACKAGE_VENDOR if set	or "unknown"

       CPACK_RPM_PACKAGE_URL

       CPACK_RPM_<component>_PACKAGE_URL
	      The projects URL.

	      o	Mandatory : NO

	      o	Default	  : -

       CPACK_RPM_PACKAGE_DESCRIPTION

       CPACK_RPM_<component>_PACKAGE_DESCRIPTION
	      RPM package description.

	      o	Mandatory : YES

	      o	Default	 :  CPACK_COMPONENT_<compName>_DESCRIPTION  (component
		based installers only) if set,	CPACK_PACKAGE_DESCRIPTION_FILE
		if set or "no package description available"

       CPACK_RPM_COMPRESSION_TYPE
	      RPM compression type.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to override RPM compression type to be used to build
	      the RPM. For example some	Linux distribution now default to lzma
	      or  xz compression whereas older cannot use such RPM. Using this
	      one can enforce compression type to be used.

	      Possible values are:

	      o	lzma

	      o	xz

	      o	bzip2

	      o	gzip

       CPACK_RPM_PACKAGE_AUTOREQ

       CPACK_RPM_<component>_PACKAGE_AUTOREQ
	      RPM spec autoreq field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to enable (1,	yes)  or  disable  (0,	no)  automatic
	      shared libraries dependency detection. Dependencies are added to
	      requires list.

	      NOTE:
		 By default automatic dependency detection is enabled  by  rpm
		 generator.

       CPACK_RPM_PACKAGE_AUTOPROV

       CPACK_RPM_<component>_PACKAGE_AUTOPROV
	      RPM spec autoprov	field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  used  to	 enable	 (1, yes) or disable (0, no) automatic
	      listing of shared	libraries that are provided  by	 the  package.
	      Shared libraries are added to provides list.

	      NOTE:
		 By  default  automatic	 provides  detection is	enabled	by rpm
		 generator.

       CPACK_RPM_PACKAGE_AUTOREQPROV

       CPACK_RPM_<component>_PACKAGE_AUTOREQPROV
	      RPM spec autoreqprov field.

	      o	Mandatory : NO

	      o	Default	  : -

	      Variable enables/disables	autoreq	and autoprov at	the same time.
	      See CPACK_RPM_PACKAGE_AUTOREQ and	CPACK_RPM_PACKAGE_AUTOPROV for
	      more details.

	      NOTE:
		 By default automatic detection	feature	is enabled by rpm.

       CPACK_RPM_PACKAGE_REQUIRES

       CPACK_RPM_<component>_PACKAGE_REQUIRES
	      RPM spec requires	field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set RPM dependencies (requires).  Note  that  you
	      must  enclose  the  complete requires string between quotes, for
	      example:

		 set(CPACK_RPM_PACKAGE_REQUIRES	"python	>= 2.5.0, cmake	>= 2.8")

	      The required package list	of an RPM file could be	printed	with:

		 rpm -qp --requires file.rpm

       CPACK_RPM_PACKAGE_CONFLICTS

       CPACK_RPM_<component>_PACKAGE_CONFLICTS
	      RPM spec conflicts field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set negative RPM dependencies  (conflicts).  Note
	      that  you	 must  enclose	the  complete  requires	string between
	      quotes, for example:

		 set(CPACK_RPM_PACKAGE_CONFLICTS "libxml2")

	      The conflicting package list of an RPM  file  could  be  printed
	      with:

		 rpm -qp --conflicts file.rpm

       CPACK_RPM_PACKAGE_REQUIRES_PRE

       CPACK_RPM_<component>_PACKAGE_REQUIRES_PRE
	      RPM spec requires(pre) field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be used to set RPM preinstall dependencies (requires(pre)).
	      Note that	you must enclose the complete requires string  between
	      quotes, for example:

		 set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")

       CPACK_RPM_PACKAGE_REQUIRES_POST

       CPACK_RPM_<component>_PACKAGE_REQUIRES_POST
	      RPM spec requires(post) field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May   be	 used	to   set  RPM  postinstall  dependencies  (re-
	      quires(post)). Note that you must	enclose	the complete  requires
	      string between quotes, for example:

		 set(CPACK_RPM_PACKAGE_REQUIRES_POST "shadow-utils, initscripts")

       CPACK_RPM_PACKAGE_REQUIRES_POSTUN

       CPACK_RPM_<component>_PACKAGE_REQUIRES_POSTUN
	      RPM spec requires(postun)	field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set RPM postuninstall dependencies	(requires(pos-
	      tun)). Note that you must	enclose	the complete  requires	string
	      between quotes, for example:

		 set(CPACK_RPM_PACKAGE_REQUIRES_POSTUN "shadow-utils, initscripts")

       CPACK_RPM_PACKAGE_REQUIRES_PREUN

       CPACK_RPM_<component>_PACKAGE_REQUIRES_PREUN
	      RPM spec requires(preun) field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May   be	 used	to  set	 RPM  preuninstall  dependencies  (re-
	      quires(preun)). Note that	you must enclose the complete requires
	      string between quotes, for example:

		 set(CPACK_RPM_PACKAGE_REQUIRES_PREUN "shadow-utils, initscripts")

       CPACK_RPM_PACKAGE_SUGGESTS

       CPACK_RPM_<component>_PACKAGE_SUGGESTS
	      RPM spec suggest field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  used to set weak	RPM dependencies (suggests). Note that
	      you must enclose the complete requires string between quotes.

       CPACK_RPM_PACKAGE_PROVIDES

       CPACK_RPM_<component>_PACKAGE_PROVIDES
	      RPM spec provides	field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set RPM  dependencies  (provides).	 The  provided
	      package list of an RPM file could	be printed with:

		 rpm -qp --provides file.rpm

       CPACK_RPM_PACKAGE_OBSOLETES

       CPACK_RPM_<component>_PACKAGE_OBSOLETES
	      RPM spec obsoletes field.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set RPM packages that are obsoleted by this one.

       CPACK_RPM_PACKAGE_RELOCATABLE
	      build a relocatable RPM.

	      o	Mandatory : NO

	      o	Default	  : CPACK_PACKAGE_RELOCATABLE

	      If this variable is set to TRUE or ON CPackRPM will try to build
	      a	relocatable RPM	package. A relocatable RPM  may	 be  installed
	      using:

		 rpm --prefix or --relocate

	      in  order	 to  install it	at an alternate	place see rpm(8). Note
	      that currently this may fail if CPACK_SET_DESTDIR	is set to  ON.
	      If  CPACK_SET_DESTDIR is set then	you will get a warning message
	      but if there is file installed with absolute path	you'll get un-
	      expected behavior.

       CPACK_RPM_SPEC_INSTALL_POST
	      Deprecated - use CPACK_RPM_POST_INSTALL_SCRIPT_FILE instead.

	      o	Mandatory : NO

	      o	Default	  : -

	      o	Deprecated: YES

	      This  way	 of  specifying	post-install script is deprecated, use
	      CPACK_RPM_POST_INSTALL_SCRIPT_FILE.  May be used to set  an  RPM
	      post-install  command inside the spec file.  For example setting
	      it to /bin/true may be used to prevent rpmbuild to  strip	 bina-
	      ries.

       CPACK_RPM_SPEC_MORE_DEFINE
	      RPM extended spec	definitions lines.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to add any %define lines to the generated spec file.

       CPACK_RPM_PACKAGE_DEBUG
	      Toggle CPackRPM debug output.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be set when invoking	cpack in order to trace	debug informa-
	      tion during CPack	RPM run. For example you may launch CPack like
	      this:

		 cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

       CPACK_RPM_USER_BINARY_SPECFILE

       CPACK_RPM_<componentName>_USER_BINARY_SPECFILE
	      A	user provided spec file.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  set  by the user	in order to specify a USER binary spec
	      file to be used by CPackRPM instead of generating	the file.  The
	      specified	file will be processed by configure_file( @ONLY).

       CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
	      Spec file	template.

	      o	Mandatory : NO

	      o	Default	  : -

	      If  set CPack will generate a template for USER specified	binary
	      spec file	and stop with an error.	For example launch CPack  like
	      this:

		 cpack -D CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE=1 -G	RPM

	      The  user	 may  then use this file in order to hand-craft	is own
	      binary	spec	file	which	  may	  be	 used	  with
	      CPACK_RPM_USER_BINARY_SPECFILE.

       CPACK_RPM_PRE_INSTALL_SCRIPT_FILE

       CPACK_RPM_PRE_UNINSTALL_SCRIPT_FILE
	      Path to file containing pre (un)install script.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  used to embed a pre (un)installation script in the spec
	      file.  The referred script file (or both)	will be	read  and  di-
	      rectly	put    after   the   %pre   or	 %preun	  section   If
	      CPACK_RPM_COMPONENT_INSTALL is set to ON the (un)install	script
	      for  each	 component  can	 be  overridden	with CPACK_RPM_<COMPO-
	      NENT>_PRE_INSTALL_SCRIPT_FILE	  and	     CPACK_RPM_<COMPO-
	      NENT>_PRE_UNINSTALL_SCRIPT_FILE.	One may	verify which scriptlet
	      has been included	with:

		 rpm -qp --scripts  package.rpm

       CPACK_RPM_POST_INSTALL_SCRIPT_FILE

       CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
	      Path to file containing post (un)install script.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to embed a post (un)installation script in the  spec
	      file.   The  referred script file	(or both) will be read and di-
	      rectly  put  after   the	 %post	 or   %postun	section.    If
	      CPACK_RPM_COMPONENT_INSTALL  is set to ON	the (un)install	script
	      for each component  can  be  overridden  with  CPACK_RPM_<COMPO-
	      NENT>_POST_INSTALL_SCRIPT_FILE	   and	     CPACK_RPM_<COMPO-
	      NENT>_POST_UNINSTALL_SCRIPT_FILE.	 One may verify	which  script-
	      let has been included with:

		 rpm -qp --scripts  package.rpm

       CPACK_RPM_USER_FILELIST

       CPACK_RPM_<COMPONENT>_USER_FILELIST

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  used  to	explicitly specify %(<directive>) file line in
	      the spec file. Like %config(noreplace) or	 any  other  directive
	      that  be	found in the %files section. You can have multiple di-
	      rectives per  line,  as  in  %attr(600,root,root)	 %config(nore-
	      place).  Since CPackRPM is generating the	list of	files (and di-
	      rectories) the user specified  files  of	the  CPACK_RPM_<COMPO-
	      NENT>_USER_FILELIST  list	 will  be  removed  from the generated
	      list. If referring to directories	do not add a trailing slash.

       CPACK_RPM_CHANGELOG_FILE
	      RPM changelog file.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to embed a changelog in the spec file.  The referred
	      file will	be read	and directly put after the %changelog section.

       CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
	      list of path to be excluded.

	      o	Mandatory : NO

	      o	Default	   :  /etc  /etc/init.d	/usr /usr/share	/usr/share/doc
		/usr/bin /usr/lib /usr/lib64 /usr/include

	      May be used to exclude path  (directories	 or  files)  from  the
	      auto-generated list of paths discovered by CPack RPM. The	defaut
	      value contains a reasonable set of values	if the variable	is not
	      defined by the user. If the variable is defined by the user then
	      CPackRPM will NOT	any of the default path. If you	 want  to  add
	      some   path   to	 the   default	 list	then   you   can   use
	      CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.

       CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
	      additional list of path to be excluded.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to add more exclude path (directories	or files) from
	      the    initial	default	   list	  of   excluded	  paths.   See
	      CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.

       CPACK_RPM_RELOCATION_PATHS
	      Packages relocation paths	list.

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to specify more than one relocation path  per	 relo-
	      catable  RPM.  Variable contains a list of relocation paths that
	      if    relative	are    prefixed	   by	  the	  value	    of
	      CPACK_RPM__COMPONENT__PACKAGE_PREFIX   or	  by   the   value  of
	      CPACK_PACKAGING_INSTALL_PREFIX if	the component version  is  not
	      provided.	 Variable is not component based as its	content	can be
	      used to set a different path prefix for e.g. binary dir and doc-
	      umentation  dir  at  the	same time.  Only prefixes that are re-
	      quired by	a certain component are	added to that component	- com-
	      ponent  must  contain  at	least one file/directory/symbolic link
	      with CPACK_RPM_RELOCATION_PATHS prefix for a certain  relocation
	      path  to be added. Package will not contain any relocation paths
	      if there are no files/directories/symbolic links on any  of  the
	      provided	prefix locations.  Packages that either	do not contain
	      any relocation paths or contain files/directories/symbolic links
	      that  are	 outside  relocation paths print out an	AUTHOR_WARNING
	      that RPM will be partially relocatable.

       CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX
	      Per component relocation path install prefix.

	      o	Mandatory : NO

	      o	Default	  : CPACK_PACKAGING_INSTALL_PREFIX

	      May be used to set per component	CPACK_PACKAGING_INSTALL_PREFIX
	      for relocatable RPM packages.

       CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION

       CPACK_RPM_NO_<COMPONENT>_INSTALL_PREFIX_RELOCATION
	      Removal of default install prefix	from relocation	paths list.

	      o	Mandatory : NO

	      o

		Default
		       CPACK_PACKAGING_INSTALL_PREFIX	or   CPACK_RPM_<COMPO-
		       NENT>_PACKAGE_PREFIX are	treated	as one	of  relocation
		       paths

	      May   be	 used  to  remove  CPACK_PACKAGING_INSTALL_PREFIX  and
	      CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX from	relocatable RPM	prefix
	      paths.

       CPACK_RPM_ADDITIONAL_MAN_DIRS

	      o	Mandatory : NO

	      o	Default	  : -

	      May be used to set additional man	dirs that could	potentially be
	      compressed by brp-compress RPM macro. Variable content must be a
	      list of regular expressions that point to	directories containing
	      man files	or to man files	directly. Note that in order  to  com-
	      press  man pages a path must also	be present in brp-compress RPM
	      script and that brp-compress script must be added	to RPM config-
	      uration by the operating system.

	      Regular  expressions  that  are added by default were taken from
	      brp-compress RPM macro:

	      o	/usr/man/man.*

	      o	/usr/man/.*/man.*

	      o	/usr/info.*

	      o	/usr/share/man/man.*

	      o	/usr/share/man/.*/man.*

	      o	/usr/share/info.*

	      o	/usr/kerberos/man.*

	      o	/usr/local/man/man.*

	      o	/usr/lib/perl5/man/man.*

	      o	/usr/share/doc/.*/man/man.*

	      o	/usr/lib/.*/man/man.*

       CPACK_RPM_DEFAULT_USER

       CPACK_RPM_<compName>_DEFAULT_USER
	      default user ownership of	RPM content

	      o	Mandatory : NO

	      o	Default	  : root

	      Value should be user name	and not	 UID.	Note  that  <compName>
	      must be in upper-case.

       CPACK_RPM_DEFAULT_GROUP

       CPACK_RPM_<compName>_DEFAULT_GROUP
	      default group ownership of RPM content

	      o	Mandatory : NO

	      o	Default	  : root

	      Value  should  be	 group name and	not GID.  Note that <compName>
	      must be in upper-case.

       CPACK_RPM_DEFAULT_FILE_PERMISSIONS

       CPACK_RPM_<compName>_DEFAULT_FILE_PERMISSIONS
	      default permissions used for packaged files

	      o	Mandatory : NO

	      o	Default	  : - (system default)

	      Accepted values are lists	with  PERMISSIONS.  Valid  permissions
	      are:

	      o	OWNER_READ

	      o	OWNER_WRITE

	      o	OWNER_EXECUTE

	      o	GROUP_READ

	      o	GROUP_WRITE

	      o	GROUP_EXECUTE

	      o	WORLD_READ

	      o	WORLD_WRITE

	      o	WORLD_EXECUTE

	      Note that	<compName> must	be in upper-case.

       CPACK_RPM_DEFAULT_DIR_PERMISSIONS

       CPACK_RPM_<compName>_DEFAULT_DIR_PERMISSIONS
	      default permissions used for packaged directories

	      o	Mandatory : NO

	      o	Default	  : - (system default)

	      Accepted	values	are  lists with	PERMISSIONS. Valid permissions
	      are the same as  for  CPACK_RPM_DEFAULT_FILE_PERMISSIONS.	  Note
	      that <compName> must be in upper-case.

   Packaging of	Symbolic Links
       CPackRPM	supports packaging of symbolic links:

	  execute_process(COMMAND ${CMAKE_COMMAND}
	    -E create_symlink <relative_path_location> <symlink_name>)
	  install(FILES	${CMAKE_CURRENT_BINARY_DIR}/<symlink_name>
	    DESTINATION	<symlink_location> COMPONENT libraries)

       Symbolic	 links will be optimized (paths	will be	shortened if possible)
       before being added to the package or if multiple	relocation  paths  are
       detected, a post	install	symlink	relocation script will be generated.

       Symbolic	links may point	to locations that are not packaged by the same
       package (either a different component or	even not packaged at all)  but
       those  locations	 will be treated as if they were a part	of the package
       while determining if symlink should be either created or	present	 in  a
       post install script - depending on relocation paths.

       Symbolic	links that point to locations outside packaging	path produce a
       warning and are treated as non relocatable permanent symbolic links.

       Currently there are a few limitations though:

       o For  component	 based	packaging  component  interdependency  is  not
	 checked  when	processing  symbolic links. Symbolic links pointing to
	 content of a different	component are  treated	the  same  way	as  if
	 pointing to location that will	not be packaged.

       o Symbolic  links pointing to a location	through	one or more intermedi-
	 ate symbolic links will not be	handled	differently - if the  interme-
	 diate	symbolic  link(s) is also on a relocatable path, relocating it
	 during	package	installation may cause initial symbolic	link to	 point
	 to an invalid location.

   Packaging of	debug information
       Debuginfo  packages  contain  debug  symbols  and sources for debugging
       packaged	binaries.

       Debuginfo RPM packaging has it's	own set	of variables:

       CPACK_RPM_DEBUGINFO_PACKAGE

       CPACK_RPM_<component>_DEBUGINFO_PACKAGE
	      Enable generation	of debuginfo RPM package(s).

	      o	Mandatory : NO

	      o	Default	  : OFF

       NOTE:
	  Binaries must	contain	debug symbols before packaging so  use	either
	  Debug	or RelWithDebInfo for CMAKE_BUILD_TYPE variable	value.

       NOTE:
	  Packages  generated  from packages without binary files, with	binary
	  files	but without execute permissions	or without debug symbols  will
	  be empty.

       CPACK_BUILD_SOURCE_DIRS
	      Provides	locations  of  root  directories  of source files from
	      which binaries were built.

	      o	Mandatory : YES	if CPACK_RPM_DEBUGINFO_PACKAGE is set

	      o	Default	  : -

       NOTE:
	  For CMake project CPACK_BUILD_SOURCE_DIRS is set by default to point
	  to CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR paths.

       NOTE:
	  Sources  with	path prefixes that do not fall under any location pro-
	  vided	with CPACK_BUILD_SOURCE_DIRS will not be present in  debuginfo
	  package.

       CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX

       CPACK_RPM_<component>_BUILD_SOURCE_DIRS_PREFIX
	      Prefix  of  location where sources will be placed	during package
	      installation.

	      o	Mandatory : YES	if CPACK_RPM_DEBUGINFO_PACKAGE is set

	      o

		Default
		       "/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>" and for com-
		       ponent	   packaging	  "/usr/src/debug/<CPACK_PACK-
		       AGE_FILE_NAME>-<component>"

       NOTE:
	  Each source path prefix is additionaly suffixed by src_<index> where
	  index	 is  index of the path used from CPACK_BUILD_SOURCE_DIRS vari-
	  able.	This produces <CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX>/src_<index>
	  replacement  path.   Limitation  is  that replaced path part must be
	  shorter or of	equal length than the length of	 its  replacement.  If
	  that is not the case either CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX vari-
	  able has to be set to	a shorter path or source directories  must  be
	  placed on a longer path.

       CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS
	      Directories  containing sources that should be excluded from de-
	      buginfo packages.

	      o	Mandatory : NO

	      o	Default	  : "/usr /usr/src /usr/src/debug"

	      Listed paths are owned by	other RPM packages and	should	there-
	      fore not be deleted on debuginfo package uninstallation.

       CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS_ADDITION
	      Paths	   that	       should	    be	     appended	    to
	      CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS for exclusion.

	      o	Mandatory : NO

	      o	Default	  : -

       CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE
	      Create a single debuginfo	package	even if	 components  packaging
	      is set.

	      o	Mandatory : NO

	      o	Default	  : OFF

	      When  this  variable  is	enabled	it produces a single debuginfo
	      package even if component	packaging is enabled.

	      When using this feature in combination with components packaging
	      and  there  is  more  than  one component	this variable requires
	      CPACK_RPM_MAIN_COMPONENT to be set.

       NOTE:
	  If none of the CPACK_RPM__component__DEBUGINFO_PACKAGE variables  is
	  set then CPACK_RPM_DEBUGINFO_PACKAGE is automatically	set to ON when
	  CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE is	set.

   Packaging of	sources	(SRPM)
       SRPM packaging is enabled by setting CPACK_RPM_PACKAGE_SOURCES variable
       while usually using CPACK_INSTALLED_DIRECTORIES variable	to provide di-
       rectory containing CMakeLists.txt and source files.

       For CMake projects SRPM package would be	product	by executing:

       cpack -G	RPM --config ./CPackSourceConfig.cmake

       NOTE:
	  Produced SRPM	package	is expected to be  built  with	cmake(1)  exe-
	  cutable  and packaged	with cpack(1) executable so CMakeLists.txt has
	  to be	located	in root	source directory and must be able to  generate
	  binary  rpm packages by executing cpack -G command. The two executa-
	  bles as well as rpmbuild must	also be	present	when generating	binary
	  rpm packages from the	produced SRPM package.

       Once  the  SRPM	package	is generated it	can be used to generate	binary
       packages	by creating a directory	structure for rpm generation and  exe-
       cuting rpmbuild tool:

       mkdir  -p build_dir/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} rpmbuild
       --define	"_topdir <path_to_build_dir>" --rebuild	<SRPM_file_name>

       Generated packages will be located in build_dir/RPMS directory  or  its
       sub directories.

       NOTE:
	  SRPM	package	internally uses	CPack/RPM generator to generate	binary
	  packages so CMakeScripts.txt can decide during the  SRPM  to	binary
	  rpm  generation step what content the	package(s) should have as well
	  as how they should be	packaged (monolithic or	components). CMake can
	  decide  this	for  e.g.  by reading environment variables set	by the
	  package manager before starting the process of generating binary rpm
	  packages. This way a single SRPM package can be used to produce dif-
	  ferent binary	rpm packages on	different platforms depending  on  the
	  platform's packaging rules.

       Source RPM packaging has	it's own set of	variables:

       CPACK_RPM_PACKAGE_SOURCES
	      Should  the  content be packaged as a source rpm (default	is bi-
	      nary rpm).

	      o	Mandatory : NO

	      o	Default	  : OFF

       NOTE:
	  For cmake projects CPACK_RPM_PACKAGE_SOURCES variable	is set to  OFF
	  in  CPackConfig.cmake	 and  ON  in CPackSourceConfig.cmake generated
	  files.

       CPACK_RPM_SOURCE_PKG_BUILD_PARAMS
	      Additional command-line parameters  provided  to	cmake(1)  exe-
	      cutable.

	      o	Mandatory : NO

	      o	Default	  : -

       CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX
	      Packaging	install	prefix that would be provided in CPACK_PACKAG-
	      ING_INSTALL_PREFIX variable for producing	binary RPM packages.

	      o	Mandatory : YES

	      o	Default	  : "/"

       CPACK_RPM_BUILDREQUIRES
	      List of source rpm build dependencies.

	      o	Mandatory : NO

	      o	Default	  : -

	      May  be  used  to	 set  source  RPM  build  dependencies	(Buil-
	      dRequires).  Note	 that  you must	enclose	the complete build re-
	      quirements string	between	quotes,	for example:

		 set(CPACK_RPM_BUILDREQUIRES "python >=	2.5.0, cmake >=	2.8")

   CPack
       Build binary and	source package installers.

   Variables common to all CPack generators
       The CPack module	generates binary and source installers in a variety of
       formats	using  the  cpack program.  Inclusion of the CPack module adds
       two new targets to the resulting	makefiles, package and package_source,
       which build the binary and source installers, respectively.  The	gener-
       ated binary installers contain everything installed via CMake's INSTALL
       command	(and  the  deprecated INSTALL_FILES, INSTALL_PROGRAMS, and IN-
       STALL_TARGETS commands).

       For certain kinds of binary installers  (including  the	graphical  in-
       stallers	 on Mac	OS X and Windows), CPack generates installers that al-
       low users to select individual application components to	install.   See
       CPackComponent module for that.

       The  CPACK_GENERATOR  variable has different meanings in	different con-
       texts.  In your CMakeLists.txt file, CPACK_GENERATOR is a list of  gen-
       erators:	when run with no other arguments, CPack	will iterate over that
       list  and   produce   one   package   for   each	  generator.	In   a
       CPACK_PROJECT_CONFIG_FILE, though, 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.

       The CMake source	tree itself contains a CPACK_PROJECT_CONFIG_FILE.  See
       the top level file CMakeCPackOptions.cmake.in for an example.

       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 listed	in that	file's CPACK_GENERATOR
	 list variable (unless told to use just	a specific one via -G  on  the
	 command line...)

       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.

       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, de-
	      faults to	the project name.

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

       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 CPack config file	 or  from  the
	      cpack  command  line option "-B".	If set the command line	option
	      override the value found in the config file.

       CPACK_PACKAGE_VERSION_MAJOR
	      Package major Version

       CPACK_PACKAGE_VERSION_MINOR
	      Package minor Version

       CPACK_PACKAGE_VERSION_PATCH
	      Package patch Version

       CPACK_PACKAGE_DESCRIPTION_FILE
	      A	text file used to describe the project.	Used, for example, the
	      introduction  screen  of	a CPack-generated Windows installer to
	      describe the project.

       CPACK_PACKAGE_DESCRIPTION_SUMMARY
	      Short description	of the project (only a few words).

       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 element 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
	      An algorithm that	will be	used to	generate additional file  with
	      checksum of the package. 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  included
	      at cpack time, once per generator	after CPack has	set CPACK_GEN-
	      ERATOR to	the actual generator being used. It allows per-genera-
	      tor 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 installed file but
	      is  used	by some	CPack generators like NSIS. If you want	to in-
	      stall a license file (may	be the same as this  one)  along  with
	      your  project  you must add an appropriate CMake INSTALL 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 uses	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
	      1/TRUE.

       CPACK_GENERATOR
	      List  of	CPack  generators to use. If not specified, CPack will
	      create a set of options CPACK_BINARY_<GENNAME> (e.g.,  CPACK_BI-
	      NARY_NSIS) allowing the user to enable/disable individual	gener-
	      ators. This variable may be used on the command line as well  as
	      in:

		 cpack -D CPACK_GENERATOR="ZIP;TGZ" /path/to/build/tree

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

	      o	Mandatory : NO

	      o	Default	  : FALSE

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

       The following variables are for advanced	uses of	CPack:

       CPACK_CMAKE_GENERATOR
	      What  CMake  generator  should  be  used if the project is 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}.

       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.

       CPACK_INSTALLED_DIRECTORIES
	      Extra directories	to install.

       CPACK_PACKAGE_INSTALL_REGISTRY_KEY
	      Registry key used	when installing	this  project.	This  is  only
	      used  by	installer  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 launching the
	      package target.

	      Provide options to choose	generators we might check here if  the
	      required	tools for the generates	exist and set the defaults ac-
	      cording to the results

   CPackWIX
       CPack WiX generator specific options

   Variables specific to CPack WiX generator
       The following variables are specific to the installers built on Windows
       using WiX.

       CPACK_WIX_UPGRADE_GUID
	      Upgrade GUID (Product/@UpgradeCode)

	      Will be automatically generated unless explicitly	provided.

	      It  should  be  explicitly  set to a constant generated globally
	      unique identifier	(GUID) to allow	your installers	to replace ex-
	      isting installations that	use the	same GUID.

	      You  may for example explicitly set this variable	in your	CMake-
	      Lists.txt	to the value that has been generated per default.  You
	      should not use GUIDs that	you did	not generate yourself or which
	      may belong to other projects.

	      A	GUID shall have	the following fixed length syntax:

		 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

	      (each X represents an uppercase hexadecimal digit)

       CPACK_WIX_PRODUCT_GUID
	      Product GUID (Product/@Id)

	      Will be automatically generated unless explicitly	provided.

	      If explicitly provided this will set the Product Id of your  in-
	      staller.

	      The  installer will abort	if it detects a	pre-existing installa-
	      tion that	uses the same GUID.

	      The GUID	shall  use  the	 syntax	 described  for	 CPACK_WIX_UP-
	      GRADE_GUID.

       CPACK_WIX_LICENSE_RTF
	      RTF License File

	      If  CPACK_RESOURCE_FILE_LICENSE has an .rtf extension it is used
	      as-is.

	      If CPACK_RESOURCE_FILE_LICENSE has an .txt extension it  is  im-
	      plicitly	converted  to  RTF by the WiX Generator.  The expected
	      encoding of the .txt file	is UTF-8.

	      With CPACK_WIX_LICENSE_RTF you can  override  the	 license  file
	      used by the WiX Generator	in case	CPACK_RESOURCE_FILE_LICENSE is
	      in an unsupported	format or the .txt -> .rtf conversion does not
	      work as expected.

       CPACK_WIX_PRODUCT_ICON
	      The Icon shown next to the program name in Add/Remove programs.

	      If set, this icon	is used	in place of the	default	icon.

       CPACK_WIX_UI_REF
	      This  variable allows you	to override the	Id of the <UIRef> ele-
	      ment in the WiX template.

	      The default is WixUI_InstallDir in case no CPack components have
	      been defined and WixUI_FeatureTree otherwise.

       CPACK_WIX_UI_BANNER
	      The  bitmap  will	appear at the top of all installer pages other
	      than the welcome and completion dialogs.

	      If set, this image will replace the default banner image.

	      This image must be 493 by	58 pixels.

       CPACK_WIX_UI_DIALOG
	      Background bitmap	used on	the welcome and	completion dialogs.

	      If this variable is set, the installer will replace the  default
	      dialog image.

	      This image must be 493 by	312 pixels.

       CPACK_WIX_PROGRAM_MENU_FOLDER
	      Start menu folder	name for launcher.

	      If  this	variable  is  not  set,	 it  will  be initialized with
	      CPACK_PACKAGE_NAME

       CPACK_WIX_CULTURES
	      Language(s) of the installer

	      Languages	are compiled into the WixUI extension library.	To use
	      them,  simply  provide  the name of the culture.	If you specify
	      more than	one culture identifier in a comma or semicolon	delim-
	      ited  list,  the	first one that is found	will be	used.  You can
	      find     a     list     of     supported	    languages	   at:
	      http://wix.sourceforge.net/manual-wix3/WixUI_localization.htm

       CPACK_WIX_TEMPLATE
	      Template file for	WiX generation

	      If  this variable	is set,	the specified template will be used to
	      generate the WiX wxs file.  This should be used if further  cus-
	      tomization of the	output is required.

	      If  this	variable is not	set, the default MSI template included
	      with CMake will be used.

       CPACK_WIX_PATCH_FILE
	      Optional list of XML files with fragments	to  be	inserted  into
	      generated	WiX sources

	      This  optional  variable can be used to specify an XML file that
	      the WiX generator	will use to inject fragments into  its	gener-
	      ated source files.

	      Patch files understood by	the CPack WiX generator	roughly	follow
	      this RELAX NG compact schema:

		 start = CPackWiXPatch

		 CPackWiXPatch = element CPackWiXPatch { CPackWiXFragment* }

		 CPackWiXFragment = element CPackWiXFragment
		 {
		     attribute Id { string },
		     fragmentContent*
		 }

		 fragmentContent = element * - CPackWiXFragment
		 {
		     (attribute	* { text } | text | fragmentContent)*
		 }

	      Currently	fragments can be injected into most  Component,	 File,
	      Directory	and Feature elements.

	      The following additional special Ids can be used:

	      o	#PRODUCT for the <Product> element.

	      o	#PRODUCTFEATURE	for the	root <Feature> element.

	      The following example illustrates	how this works.

	      Given that the WiX generator creates the following XML element:

		 <Component Id="CM_CP_applications.bin.my_libapp.exe" Guid="*"/>

	      The  following  XML patch	file may be used to inject an Environ-
	      ment element into	it:

		 <CPackWiXPatch>
		   <CPackWiXFragment Id="CM_CP_applications.bin.my_libapp.exe">
		     <Environment Id="MyEnvironment" Action="set"
		       Name="MyVariableName" Value="MyVariableValue"/>
		   </CPackWiXFragment>
		 </CPackWiXPatch>

       CPACK_WIX_EXTRA_SOURCES
	      Extra WiX	source files

	      This variable provides an	optional  list	of  extra  WiX	source
	      files  (.wxs) that should	be compiled and	linked.	 The full path
	      to source	files is required.

       CPACK_WIX_EXTRA_OBJECTS
	      Extra WiX	object files or	libraries

	      This variable provides an	optional  list	of  extra  WiX	object
	      (.wixobj)	 and/or	WiX library (.wixlib) files.  The full path to
	      objects and libraries is required.

       CPACK_WIX_EXTENSIONS
	      This variable provides a list of additional extensions  for  the
	      WiX tools	light and candle.

       CPACK_WIX_<TOOL>_EXTENSIONS
	      This  is	the  tool  specific  version  of CPACK_WIX_EXTENSIONS.
	      <TOOL> can be either LIGHT or CANDLE.

       CPACK_WIX_<TOOL>_EXTRA_FLAGS
	      This list	variable allows	you to pass additional	flags  to  the
	      WiX tool <TOOL>.

	      Use  it at your own risk.	 Future	versions of CPack may generate
	      flags which may be in conflict with your own flags.

	      <TOOL> can be either LIGHT or CANDLE.

       CPACK_WIX_CMAKE_PACKAGE_REGISTRY
	      If this variable is set the generated installer will  create  an
	      entry  in	 the  windows  registry	 key  HKEY_LOCAL_MACHINE\Soft-
	      ware\Kitware\CMake\Packages\<package> The	value for <package> is
	      provided by this variable.

	      Assuming	you  also install a CMake configuration	file this will
	      allow other  CMake  projects  to	find  your  package  with  the
	      find_package() command.

       CPACK_WIX_PROPERTY_<PROPERTY>
	      This variable can	be used	to provide a value for the Windows In-
	      staller property <PROPERTY>

	      The following list contains some example properties that can  be
	      used  to	customize  information	under  "Programs and Features"
	      (also known as "Add or Remove Programs")

	      o	ARPCOMMENTS - Comments

	      o	ARPHELPLINK - Help and support information URL

	      o	ARPURLINFOABOUT	- General information URL

	      o	ARPURLUPDATEINFO - Update information URL

	      o	ARPHELPTELEPHONE - Help	and support telephone number

	      o	ARPSIZE	- Size (in kilobytes) of the application

       CPACK_WIX_ROOT_FEATURE_TITLE

       Sets the	name of	the root install feature in the	WIX installer. Same as
       CPACK_COMPONENT_<compName>_DISPLAY_NAME for components.

       CPACK_WIX_ROOT_FEATURE_DESCRIPTION

       Sets  the description of	the root install feature in the	WIX installer.
       Same as CPACK_COMPONENT_<compName>_DESCRIPTION for components.

       CPACK_WIX_SKIP_PROGRAM_FOLDER

       If this variable	is set to true,	the default install  location  of  the
       generated  package  will	 be  CPACK_PACKAGE_INSTALL_DIRECTORY directly.
       The install location will not be	located	relatively below  ProgramFiles
       or ProgramFiles64.

	  NOTE:
	      Installers created with this feature do not take differences be-
	      tween the	system on which	the installer is created and the  sys-
	      tem on which the installer might be used into account.

	      It is therefor possible that the installer e.g. might try	to in-
	      stall onto a drive that is unavailable or	unintended or  a  path
	      that  does not follow the	localization or	convention of the sys-
	      tem on which the installation is performed.

   CSharpUtilities
       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_PROJECT_NAME "MyProject")
	  set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC")
	  set(CTEST_DROP_METHOD	"http")
	  set(CTEST_DROP_SITE "my.cdash.org")
	  set(CTEST_DROP_LOCATION "/submit.php?project=MyProject")
	  set(CTEST_DROP_SITE_CDASH TRUE)

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

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

	      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.

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

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

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

   Documentation
       DocumentationVTK.cmake

       This file provides support for the VTK documentation framework.	It re-
       lies on several tools (Doxygen, Perl, etc).

   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
		   )

	      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.

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

       Multiple	 content links of the same name	with different 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.  In order to match	associated files in subdirectories, specify  a
       RECURSE:	option,	e.g. DATA{MyDataDir/,RECURSE:,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

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

   Custom Fetch	Scripts
       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
       Create custom targets to	build projects in external trees

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

	      General options are:

	      DEPENDS <projects>...
		     Targets on	which the project depends

	      PREFIX <dir>
		     Root dir for entire project

	      LIST_SEPARATOR <sep>
		     Sep to be replaced	by ; in	cmd lines

	      TMP_DIR <dir>
		     Directory to store	temporary files

	      STAMP_DIR	<dir>
		     Directory to store	step timestamps

	      EXCLUDE_FROM_ALL 1
		     The "all" target does not depend on this

	      Download step options are:

	      DOWNLOAD_NAME <fname>
		     File name to store	(if not	end of URL)

	      DOWNLOAD_DIR <dir>
		     Directory to store	downloaded files

	      DOWNLOAD_COMMAND <cmd>...
		     Command to	download source	tree

	      DOWNLOAD_NO_PROGRESS 1
		     Disable download progress reports

	      CVS_REPOSITORY <cvsroot>
		     CVSROOT of	CVS repository

	      CVS_MODULE <mod>
		     Module to checkout	from CVS repo

	      CVS_TAG <tag>
		     Tag to checkout from CVS repo

	      SVN_REPOSITORY <url>
		     URL of Subversion repo

	      SVN_REVISION -r<rev>
		     Revision to checkout from Subversion repo

	      SVN_USERNAME <username>
		     Username for Subversion checkout and update

	      SVN_PASSWORD <password>
		     Password for Subversion checkout and update

	      SVN_TRUST_CERT 1
		     Trust the Subversion server site certificate

	      GIT_REPOSITORY <url>
		     URL of git	repo

	      GIT_TAG <tag>
		     Git branch	name, commit id	or tag

	      GIT_REMOTE_NAME <name>
		     The optional name of the remote, default to origin

	      GIT_SUBMODULES <module>...
		     Git submodules that shall be updated, all if empty

	      GIT_SHALLOW 1
		     Tell Git to clone with --depth 1.	Use  when  GIT_TAG  is
		     not specified or when it names a branch in	order to down-
		     load only the tip of the branch without the rest  of  its
		     history.

	      GIT_PROGRESS 1
		     Tell  Git	to clone with --progress.  For large projects,
		     the clone step does not output anything  which  can  make
		     the build appear to have stalled.	This option forces Git
		     to	output progress	information during the clone  step  so
		     that forward progress is indicated.

	      GIT_CONFIG <option>...
		     Tell Git to clone with --config <option>.	Use additional
		     configuration  parameters	when   cloning	 the   project
		     (key=value	as expected by git config).

	      HG_REPOSITORY <url>
		     URL of mercurial repo

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

	      URL /.../src.tgz [/.../src.tgz]...
		     Full path or URL(s) of source.  Multiple URLs are allowed
		     as	mirrors.

	      URL_HASH ALGO=value
		     Hash of file at URL

	      URL_MD5 md5
		     Equivalent	to URL_HASH MD5=md5

	      HTTP_USERNAME <username>
		     Username for download operation

	      HTTP_PASSWORD <username>
		     Password for download operation

	      HTTP_HEADER <header>
		     HTTP header for download operation. Suboption can be  re-
		     peated several times.

	      TLS_VERIFY <bool>
		     Should certificate	for https be checked

	      TLS_CAINFO <file>
		     Path to a certificate authority file

	      TIMEOUT <seconds>
		     Time allowed for file download operations

	      DOWNLOAD_NO_EXTRACT 1
		     Just  download  the  file and do not extract it; the full
		     path to  the  downloaded  file  is	 available  as	<DOWN-
		     LOADED_FILE>.

	      Update/Patch step	options	are:

	      UPDATE_COMMAND <cmd>...
		     Source work-tree update command

	      UPDATE_DISCONNECTED 1
		     Never update automatically	from the remote	repository

	      PATCH_COMMAND <cmd>...
		     Command to	patch downloaded source

	      Configure	step options are:

	      SOURCE_DIR <dir>
		     Source dir	to be used for build

	      SOURCE_SUBDIR <dir>
		     Path to source CMakeLists.txt relative to SOURCE_DIR

	      CONFIGURE_COMMAND	<cmd>...
		     Build tree	configuration command

	      CMAKE_COMMAND /.../cmake
		     Specify alternative cmake executable

	      CMAKE_GENERATOR <gen>
		     Specify generator for native build

	      CMAKE_GENERATOR_PLATFORM <platform>
		     Generator-specific	platform name

	      CMAKE_GENERATOR_TOOLSET <toolset>
		     Generator-specific	toolset	name

	      CMAKE_ARGS <arg>...
		     Arguments	to  CMake  command  line.  These arguments are
		     passed to CMake command line, and can  contain  arguments
		     other  than  cache	 values, see also CMake	Options. Argu-
		     ments in the form -Dvar:string=on are  always  passed  to
		     the  command line,	and therefore cannot be	changed	by the
		     user.  Arguments may use generator	expressions.

	      CMAKE_CACHE_ARGS <arg>...
		     Initial cache arguments,  of  the	form  -Dvar:string=on.
		     These  arguments  are written in a	pre-load a script that
		     populates CMake cache, see	also cmake -C. This allows one
		     to	 overcome command line length limits.  These arguments
		     are set() using the FORCE argument, and therefore	cannot
		     be	 changed by the	user.  Arguments may use generator ex-
		     pressions.

	      CMAKE_CACHE_DEFAULT_ARGS <arg>...
		     Initial   default	 cache	 arguments,   of   the	  form
		     -Dvar:string=on.	 These	arguments  are	written	 in  a
		     pre-load a	script that populates CMake  cache,  see  also
		     cmake -C. This allows one to overcome command line	length
		     limits.  These arguments can be  used  as	default	 value
		     that  will	 be  set  if no	previous value is found	in the
		     cache, and	that the user can change later.	 Arguments may
		     use generator expressions.

	      Build step options are:

	      BINARY_DIR <dir>
		     Specify build dir location

	      BUILD_COMMAND <cmd>...
		     Command to	drive the native build

	      BUILD_IN_SOURCE 1
		     Use source	dir for	build dir

	      BUILD_ALWAYS 1
		     No	stamp file, build step always runs

	      BUILD_BYPRODUCTS <file>...
		     Files that	will be	generated by the build command but may
		     or	may not	have their modification	time updated by	subse-
		     quent builds.

	      Install step options are:

	      INSTALL_DIR <dir>
		     Installation  prefix  to  be  placed in the <INSTALL_DIR>
		     placeholder.  This	does not actually configure the	exter-
		     nal project to install to the given prefix.  That must be
		     done by passing appropriate  arguments  to	 the  external
		     project configuration step, e.g. using <INSTALL_DIR>.

	      INSTALL_COMMAND <cmd>...
		     Command to	drive installation of the external project af-
		     ter it has	been built.  This only happens	at  the	 build
		     time  of  the calling project.  In	order to install files
		     from the external	project	 alongside  the	 locally-built
		     files,  a	separate local install() call must be added to
		     pick the files up from one	of the external	project	trees.

	      Test step	options	are:

	      TEST_BEFORE_INSTALL 1
		     Add test step executed before install step

	      TEST_AFTER_INSTALL 1
		     Add test step executed after install step

	      TEST_EXCLUDE_FROM_MAIN 1
		     Main target does not depend on the	test step

	      TEST_COMMAND <cmd>...
		     Command to	drive test

	      Output logging options are:

	      LOG_DOWNLOAD 1
		     Wrap download in script to	log output

	      LOG_UPDATE 1
		     Wrap update in script to log output

	      LOG_CONFIGURE 1
		     Wrap configure in script to log output

	      LOG_BUILD	1
		     Wrap build	in script to log output

	      LOG_TEST 1
		     Wrap test in script to log	output

	      LOG_INSTALL 1
		     Wrap install in script to log output

	      Steps can	be given direct	access to the  terminal	 if  possible.
	      With  the	 Ninja generator, this places the steps	in the console
	      pool.  Options are:

	      USES_TERMINAL_DOWNLOAD 1
		     Give download terminal access.

	      USES_TERMINAL_UPDATE 1
		     Give update terminal access.

	      USES_TERMINAL_CONFIGURE 1
		     Give configure terminal access.

	      USES_TERMINAL_BUILD 1
		     Give build	terminal access.

	      USES_TERMINAL_TEST 1
		     Give test terminal	access.

	      USES_TERMINAL_INSTALL 1
		     Give install terminal access.

	      Other options are:

	      STEP_TARGETS <step-target>...
		     Generate custom targets for these steps

	      INDEPENDENT_STEP_TARGETS <step-target>...
		     Generate custom targets for these steps that do  not  de-
		     pend  on  other external projects even if a dependency is
		     set

	      The *_DIR	options	specify	directories for	the project, with  de-
	      fault  directories computed as follows.  If the PREFIX option is
	      given to ExternalProject_Add() or	the EP_PREFIX directory	 prop-
	      erty is set, then	an external project is built and installed un-
	      der 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>

	      Otherwise, if the	EP_BASE	directory property is set then	compo-
	      nents  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>

	      If no PREFIX, EP_PREFIX, or EP_BASE is specified	then  the  de-
	      fault is to set PREFIX to	<name>-prefix.	Relative paths are in-
	      terpreted	with respect to	the build directory  corresponding  to
	      the source directory in which ExternalProject_Add	is invoked.

	      If  SOURCE_SUBDIR	 is set	and no CONFIGURE_COMMAND is specified,
	      the configure command will run CMake  using  the	CMakeLists.txt
	      located  in  the relative	path specified by SOURCE_SUBDIR, rela-
	      tive  to	the  SOURCE_DIR.   If  no  SOURCE_SUBDIR   is	given,
	      SOURCE_DIR is used.

	      If  SOURCE_DIR  is  explicitly  set to an	existing directory the
	      project will be built from it.  Otherwise	a download  step  must
	      be specified using one of	the DOWNLOAD_COMMAND, CVS_*, SVN_*, or
	      URL options.  The	URL option may refer locally to	a directory or
	      source   tarball,	  or   refer   to   a	remote	tarball	 (e.g.
	      http://.../src.tgz).

	      If UPDATE_DISCONNECTED is	set, the update	step is	 not  executed
	      automatically when building the main target. The update step can
	      still be added as	a step target and  called  manually.  This  is
	      useful  if  you  want to allow one to build the project when you
	      are disconnected from the	network	(you might still need the net-
	      work  for	the download step).  This is disabled by default.  The
	      directory	property EP_UPDATE_DISCONNECTED	can be used to	change
	      the  default  value for all the external projects	in the current
	      directory	and its	subdirectories.

       ExternalProject_Add_Step
	      The ExternalProject_Add_Step function adds a custom step	to  an
	      external project:

		 ExternalProject_Add_Step(<name> <step>	[<option>...])

	      Options are:

	      COMMAND <cmd>...
		     Command line invoked by this step

	      COMMENT <text>...
		     Text printed when step executes

	      DEPENDEES	<step>...
		     Steps on which this step depends

	      DEPENDERS	<step>...
		     Steps that	depend on this step

	      DEPENDS <file>...
		     Files on which this step depends

	      BYPRODUCTS <file>...
		     Files  that will be generated by this step	but may	or may
		     not have their modification time  updated	by  subsequent
		     builds.

	      ALWAYS 1
		     No	stamp file, step always	runs

	      EXCLUDE_FROM_MAIN	1
		     Main target does not depend on this step

	      WORKING_DIRECTORY	<dir>
		     Working directory for command

	      LOG 1  Wrap step in script to log	output

	      USES_TERMINAL 1
		     Give the 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	tokens
	      <SOURCE_DIR>, <SOURCE_SUBDIR>,  <BINARY_DIR>, <INSTALL_DIR>, and
	      <TMP_DIR>	with corresponding property values.

       Any builtin step	that specifies a <step>_COMMAND	cmd... or custom  step
       that  specifies	a  COMMAND cmd... may specify additional command lines
       using the form COMMAND cmd....  At build	time the commands will be exe-
       cuted in	order and aborted if any one fails.  For example:

	  ... BUILD_COMMAND make COMMAND echo done ...

       specifies  to  run  make	 and  then  echo  done	during the build step.
       Whether the current working directory is	preserved between commands  is
       not defined.  Behavior of shell operators like && is not	defined.

       Arguments  to  <step>_COMMAND  or COMMAND options may use generator ex-
       pressions.

       ExternalProject_Get_Property
	      The  ExternalProject_Get_Property	 function  retrieves  external
	      project target properties:

		 ExternalProject_Get_Property(<name> [prop1 [prop2 [...]]])

	      It  stores property values in variables of the same name.	 Prop-
	      erty names correspond to the keyword argument names of External-
	      Project_Add.

       ExternalProject_Add_StepTargets
	      The  ExternalProject_Add_StepTargets  function  generates	custom
	      targets for the steps listed:

		 ExternalProject_Add_StepTargets(<name>	[NO_DEPENDS] [step1 [step2 [...]]])

       If NO_DEPENDS is	set, the target	will not depend	on the dependencies of
       the complete project. This is usually safe to use for the download, up-
       date, and patch steps that do not require that all the dependencies are
       updated	and  built.   Using  NO_DEPENDS	for other of the default steps
       might break parallel builds, so	you  should  avoid,  it.   For	custom
       steps,  you should consider whether or not the custom commands requires
       that the	dependencies are configured, built and installed.

       If STEP_TARGETS or INDEPENDENT_STEP_TARGETS is  set  then  ExternalPro-
       ject_Add_StepTargets  is	 automatically	called	at the end of matching
       calls  to  ExternalProject_Add_Step.   Pass  STEP_TARGETS  or  INDEPEN-
       DENT_STEP_TARGETS  explicitly  to individual ExternalProject_Add	calls,
       or implicitly to	all ExternalProject_Add	calls by setting the directory
       properties  EP_STEP_TARGETS and EP_INDEPENDENT_STEP_TARGETS.  The INDE-
       PENDENT version of the argument and of the property will	call External-
       Project_Add_StepTargets with the	NO_DEPENDS argument.

       If  STEP_TARGETS	 and INDEPENDENT_STEP_TARGETS are not set, clients may
       still manually call ExternalProject_Add_StepTargets after  calling  Ex-
       ternalProject_Add or ExternalProject_Add_Step.

       This functionality is provided to make it easy to drive the steps inde-
       pendently 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 portion,	followed by tests.  If
       you invoke a custom target that depends on a step halfway  through  the
       step dependency chain, then all the previous steps will also run	to en-
       sure everything is up to	date.

       For example, to drive configure,	build and test steps independently for
       each ExternalProject_Add	call in	your project, write the	following line
       prior to	any ExternalProject_Add	calls in your CMakeLists.txt file:

	  set_property(DIRECTORY PROPERTY EP_STEP_TARGETS configure build test)

       ExternalProject_Add_StepDependencies
	      The ExternalProject_Add_StepDependencies function	add  some  de-
	      pendencies for some external project step:

		 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() when adding a
	      dependency for some of the step targets generated	 by  External-
	      Project.

   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.

   Functions
       feature_summary

		 feature_summary( [FILENAME <file>]
				  [APPEND]
				  [VAR <variable_name>]
				  [INCLUDE_QUIET_PACKAGES]
				  [FATAL_ON_MISSING_REQUIRED_PACKAGES]
				  [DESCRIPTION "<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>

	      With the exception of the	ALL value, these values	 can  be  com-
	      bined 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	INCLUDE_QUIET_PACKAGES is given, packages  which  have
	      been  searched with find_package(... QUIET) will also be listed.
	      By default they are skipped.  If FATAL_ON_MISSING_REQUIRED_PACK-
	      AGES  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.

	      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.

	      If  the QUIET_ON_EMPTY option is used, if	only one type of pack-
	      age was requested, and no	packages belonging  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 severly 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.

	      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:")

   FindALSA
       Find alsa

       Find the	alsa libraries (asound)

	  This module defines the following variables:
	     ALSA_FOUND	      -	True if	ALSA_INCLUDE_DIR & ALSA_LIBRARY	are found
	     ALSA_LIBRARIES   -	Set when ALSA_LIBRARY is found
	     ALSA_INCLUDE_DIRS - Set when ALSA_INCLUDE_DIR is found

	  ALSA_INCLUDE_DIR - where to find asoundlib.h,	etc.
	  ALSA_LIBRARY	   - the asound	library
	  ALSA_VERSION_STRING -	the version of alsa found (since CMake 2.8.8)

   FindArmadillo
       Find Armadillo

       Find the	Armadillo C++ library

       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

   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.

       The options are:

       COMPILE_FLAGS <flags>
	      Specify flags to be added	to the bison command line.

       DEFINES_FILE <file>
	      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.  If
	      <file> is	given, it specifies path the report file is copied to.
	      [<file>] is left for backward compatibility of this module.  Use
	      VERBOSE REPORT_FILE <file>.

       REPORT_FILE <file>
	      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 BLAS library

       This module finds an installed fortran library that implements the BLAS
       linear-algebra interface	(see http://www.netlib.org/blas/).   The  list
       of  libraries  searched	for  is	 taken	from  the autoconf macro file,
       acx_blas.m4			 (distributed			    at
       http://ac-archive.sourceforge.net/ac-archive/acx_blas.html).

       This module sets	the following variables:

	  BLAS_FOUND - set to true if a	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
	  BLAS95_LIBRARIES - uncached list of libraries	(using full path name)
	    to link against to use BLAS95 interface
	  BLAS95_FOUND - set to	true if	a library implementing the BLAS	f95 interface
	    is found
	  BLA_STATIC  if set on	this determines	what kind of linkage we	do (static)
	  BLA_VENDOR  if set checks only the specified vendor, if not set checks
	     all the possibilities
	  BLA_F95     if set on	tries to find the f95 interfaces for BLAS/LAPACK

       List of vendors (BLA_VENDOR) valid in this module:

       o Goto

       o OpenBLAS

       o ATLAS PhiPACK

       o CXML

       o DXML

       o SunPerf

       o SCSL

       o SGIMATH

       o IBMESSL

       o Intel10_32 (intel mkl v10 32 bit)

       o Intel10_64lp (intel mkl v10 64	bit, lp	thread model, lp64 model)

       o Intel10_64lp_seq (intel mkl v10 64 bit, sequential code, lp64 model)

       o Intel (older versions of mkl 32 and 64	bit)

       o ACML

       o ACML_MP

       o ACML_GPU

       o Apple

       o NAS

       o Generic

       NOTE:
	  C/CXX	should be enabled to use Intel mkl

   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.

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

       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.   For  the	former
       case results are	reported in 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_<C>_FOUND	 - True	if component <C> was found (<C>	is upper-case)
	  Boost_<C>_LIBRARY	 - Libraries to	link for component <C> (may include
				   target_link_libraries debug/optimized keywords)
	  Boost_VERSION		 - BOOST_VERSION value from boost/version.hpp
	  Boost_LIB_VERSION	 - Version string appended to library filenames
	  Boost_MAJOR_VERSION	 - Boost major version number (X in X.y.z)
	  Boost_MINOR_VERSION	 - Boost minor version number (Y in x.Y.z)
	  Boost_SUBMINOR_VERSION - Boost subminor version number (Z in x.y.Z)
	  Boost_LIB_DIAGNOSTIC_DEFINITIONS (Windows)
				 - Pass	to add_definitions() to	have diagnostic
				   information about Boost's automatic linking
				   displayed during compilation

       This module reads hints about search locations from variables:

	  BOOST_ROOT		 - Preferred installation prefix
	   (or BOOSTROOT)
	  BOOST_INCLUDEDIR	 - Preferred include directory e.g. <prefix>/include
	  BOOST_LIBRARYDIR	 - Preferred library directory e.g. <prefix>/lib
	  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)

       and saves search	results	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_<C>_LIBRARY_DEBUG   - Component	<C> library debug variant
	  Boost_<C>_LIBRARY_RELEASE - Component	<C> library release variant

       The following IMPORTED targets are also defined:

	  Boost::boost			- Target for header-only dependencies
					  (Boost include directory)
	  Boost::<C>			- Target for specific component	dependency
					  (shared or static library); <C> is lower-
					  case
	  Boost::diagnostic_definitions	- interface target to enable diagnostic
					  information about Boost's automatic linking
					  during compilation (adds BOOST_LIB_DIAGNOSTIC)
	  Boost::disable_autolinking	- interface target to disable automatic
					  linking with MSVC (adds BOOST_ALL_NO_LIB)
	  Boost::dynamic_linking	- interface target to enable dynamic linking
					  linking with MSVC (adds BOOST_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	Thread::Thread
       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.

       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_<C>_LIBRARY_DEBUG  and	 Boost_<C>_LI-
       BRARY_RELEASE.	When one changes settings used by previous searches in
       the same	build tree (excluding environment variables) this module  dis-
       cards  previous	search	results	 affected  by the changes and searches
       again.

       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_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).	 Default is OFF.
	  Boost_USE_STLPORT_DEPRECATED_NATIVE_IOSTREAMS
				   - Set to ON to use libraries	compiled with
				     STLPort deprecated	"native	iostreams"
				     ('n' tag).	 Default is OFF.
	  Boost_COMPILER	   - Set to the	compiler-specific library suffix
				     (e.g. "-gcc43").  Default is auto-computed
				     for the C++ compiler in use.  A list may be
				     used if multiple compatible suffixes should
				     be	tested for, in decreasing order	of
				     preference.
	  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 "myboost", 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_DETAILED_FAILURE_MSG
				   - Set to ON to add detailed information to the
				     failure message even when the REQUIRED option
				     is	not given to the find_package call.
	  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.42.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_LIBRARY_DIR_DEBUG.

       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.

       Example to find Boost headers only:

	  find_package(Boost 1.36.0)
	  if(Boost_FOUND)
	    include_directories(${Boost_INCLUDE_DIRS})
	    add_executable(foo foo.cc)
	  endif()

       Example to 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)

       Example to find Boost headers and some static libraries:

	  set(Boost_USE_STATIC_LIBS	   ON) # only find static libs
	  set(Boost_USE_MULTITHREADED	   ON)
	  set(Boost_USE_STATIC_RUNTIME	  OFF)
	  find_package(Boost 1.36.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 it provides a package
       configuration file for use with find_package's Config mode.  This  mod-
       ule  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 re-
       turns with no further action.  See documentation	 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
       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_DIR - the BZip2	include	directory
	  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 (since CMake 2.8.8)

   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

   FindCUDA
       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  mac  and should be reasonably up to date with CUDA C re-
       leases.

       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.

       The following variables affect the behavior of the macros in the	script
       (in  alphebetical  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_COM-
       PILE_FATBIN, CUDA_COMPILE_CUBIN or CUDA_WRAP_SRCS:

	  CUDA_64_BIT_DEVICE_CODE (Default matches host	bit size)
	  -- Set to ON to compile for 64 bit device code, OFF for 32 bit device	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 possible 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_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_BINARY_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,	$(VCInstallDir)/bin for	VS)
	  -- 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
	     $(VCInstallDir)/bin is a special value that expands out to	the path when
	     the command is run	from within VS.

	  CUDA_NVCC_FLAGS
	  CUDA_NVCC_FLAGS_<CONFIG>
	  -- Additional	NVCC command line arguments.  NOTE: multiple arguments must be
	     semi-colon	delimited (e.g.	--compiler-options;-Wall)

	  CUDA_PROPAGATE_HOST_FLAGS (Default ON)
	  -- Set to ON to propagate CMAKE_{C,CXX}_FLAGS	and their configuration
	     dependent counterparts (e.g. CMAKE_C_FLAGS_DEBUG) automatically 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 affect 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	runtime	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
	  -- 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)
	  -- 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.

       The script creates the following	macros (in alphebetical	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 file0 file1 ...
			       [WIN32] [MACOSX_BUNDLE] [EXCLUDE_FROM_ALL] [OPTIONS ...]	)
	  -- Creates an	executable "cuda_target" which is made up of the files
	     specified.	 All of	the non	CUDA C files are compiled using	the standard
	     build rules specified by CMAKE and	the cuda files are compiled to object
	     files using nvcc and the host compiler.  In addition CUDA_INCLUDE_DIRS is
	     added automatically to include_directories().  Some standard 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	file0 file1 ...
			    [STATIC | SHARED | MODULE] [EXCLUDE_FROM_ALL] [OPTIONS ...]	)
	  -- Same as CUDA_ADD_EXECUTABLE except	that a library is created.

	  CUDA_BUILD_CLEAN_TARGET()
	  -- Creates a convience target	that deletes all the dependency	files
	     generated.	 You should make clean after running this target to ensure the
	     dependency	files get regenerated.

	  CUDA_COMPILE(	generated_files	file0 file1 ...	[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 file0 file1	... [OPTIONS ...] )
	  -- Returns a list of PTX files generated from	the input source files.

	  CUDA_COMPILE_FATBIN( generated_files file0 file1 ... [OPTIONS	...] )
	  -- Returns a list of FATBIN files generated from the input source files.

	  CUDA_COMPILE_CUBIN( generated_files file0 file1 ... [OPTIONS ...] )
	  -- 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
	     compilation.  This	file name is typically passed into
	     CUDA_LINK_SEPARABLE_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
	     automatically 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_EXECUTABLE 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 automatically is the bitness flag as
	     specified by CUDA_64_BIT_DEVICE_CODE.  Note that this is a	function
	     instead of	a macro.

	  CUDA_SELECT_NVCC_ARCH_FLAGS(out_variable [target_CUDA_architectures])
	  -- Selects GPU arch flags for	nvcc based on target_CUDA_architectures
	     target_CUDA_architectures : Auto |	Common | All | LIST(ARCH_AND_PTX ...)
	      -	"Auto" detects local machine GPU compute arch at runtime.
	      -	"Common" and "All" cover common	and entire subsets of architectures
	     ARCH_AND_PTX : NAME | NUM.NUM | NUM.NUM(NUM.NUM) |	NUM.NUM+PTX
	     NAME: Fermi Kepler	Maxwell	Kepler+Tegra Kepler+Tesla Maxwell+Tegra	Pascal
	     NUM: Any number. Only those pairs are currently accepted by NVCC though:
		   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 file0 file1 ...
			   [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 (file0 file1 ... fileN) 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
	     specifying	the name of the	configuration followed by the options.	General
	     options must precede configuration	specific options.  Not all
	     configurations need to be specified, only the ones	provided will be used.

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

	       1. nvcc can return negative numbers as return values which confuses
	       Visual Studio into thinking that	the command succeeded.	The script now
	       checks the error	codes and produces errors when there was a problem.

	       2. nvcc has been	known to not delete incomplete results when it
	       encounters 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.

	       3. 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 library.
	     BUILD_SHARED_LIBS is ignored in CUDA_WRAP_SRCS, but it is respected 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 compilation	is
	     detected.

	     Flags passed into add_definitions with -D or /D are passed	along to nvcc.

       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	-- CUDA_VERSION_MAJOR.CUDA_VERSION_MINOR
	  CUDA_HAS_FP16		-- 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 (alternative 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 -- Device runtime library.
				    Required for separable 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	-- 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 version 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+.
	  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.

   FindCups
       Try to find the Cups printing system

       Once done this will define

	  CUPS_FOUND - system has Cups
	  CUPS_INCLUDE_DIR - the Cups include directory
	  CUPS_LIBRARIES - Libraries needed to use Cups
	  CUPS_VERSION_STRING -	version	of Cups	found (since CMake 2.8.8)
	  Set CUPS_REQUIRE_IPP_DELETE_ATTRIBUTE	to TRUE	if you need a version which
	  features this	function (i.e. at least	1.1.19)

   FindCURL
       Find curl

       Find the	native CURL headers and	libraries.

	  CURL_INCLUDE_DIRS   -	where to find curl/curl.h, etc.
	  CURL_LIBRARIES      -	List of	libraries when using curl.
	  CURL_FOUND	      -	True if	curl found.
	  CURL_VERSION_STRING -	the version of curl found (since CMake 2.8.8)

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

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

       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
       this module looks for Cygwin

   FindDart
       Find DART

       This  module  looks for the dart	testing	software and sets DART_ROOT to
       point to	where it found it.

   FindDCMTK
       Find DCMTK libraries and	applications

       The module defines the following	variables:

	  DCMTK_INCLUDE_DIRS  -	Directories to include to use DCMTK
	  DCMTK_LIBRARIES     -	Files to link against to use DCMTK
	  DCMTK_FOUND	      -	If false, don't	try to use DCMTK
	  DCMTK_DIR	      -	(optional) Source directory for	DCMTK

   Compatibility
       This module is able to find a version of	DCMTK that does	 or  does  not
       export a	DCMTKConfig.cmake file.	It applies a two step process:

       o Step  1:  Attempt to find DCMTK version providing a DCMTKConfig.cmake
	 file.

       o Step 2:  If step 1 failed, rely on  FindDCMTK.cmake  to  set  DCMTK_*
	 variables details below.

       Recent  DCMTK  provides a DCMTKConfig.cmake package configuration file.
       To exclusively use the package  configuration  file  (recommended  when
       possible),  pass	 the  NO_MODULE	option to find_package(). For example,
       find_package(DCMTK NO_MODULE).  This requires official  DCMTK  snapshot
       3.6.1_20140617 or newer.

       Until  all  clients update to the more recent DCMTK, build systems will
       need to support different versions of DCMTK.

       On any given system, the	following combinations of DCMTK	versions could
       be considered:

	     +-------+-----------------+-----------------+-------------+
	     |	     | SYSTEM DCMTK    | LOCAL DCMTK	 | Supported ? |
	     +-------+-----------------+-----------------+-------------+
	     |Case A | NA	       | [ ] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case B | NA	       | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case C | [ ] DCMTKConfig | NA		 | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case D | [X] DCMTKConfig | NA		 | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case E | [ ] DCMTKConfig | [ ] DCMTKConfig | YES (*)     |
	     +-------+-----------------+-----------------+-------------+
	     |Case F | [X] DCMTKConfig | [ ] DCMTKConfig | NO	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case G | [ ] DCMTKConfig | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	     |Case H | [X] DCMTKConfig | [X] DCMTKConfig | YES	       |
	     +-------+-----------------+-----------------+-------------+
	  (*) See Troubleshooting section.

       Legend:
	  NA ...............: Means that no System or Local DCMTK is available

	  [  ] DCMTKConfig ..: Means that the version of DCMTK does NOT	export
	  a DCMTKConfig.cmake file.

	  [X] DCMTKConfig ..: Means that the version of	DCMTK exports a	DCMTK-
	  Config.cmake file.

   Troubleshooting
       What to do if my	project	finds a	different version of DCMTK?

       Remove  DCMTK  entry from the CMake cache per find_package() documenta-
       tion.

   FindDevIL
       This    module	 locates    the	    developer's	    image     library.
       http://openil.sourceforge.net/

       This module sets:

	  IL_LIBRARIES -   the name of the IL library. These include the full path to
			   the core DevIL library. This	one has	to be linked into the
			   application.
	  ILU_LIBRARIES	-  the name of the ILU library.	Again, the full	path. This
			   library is for filters and effects, not actual loading. It
			   doesn't have	to be linked if	the functionality it provides
			   is not used.
	  ILUT_LIBRARIES - the name of the ILUT	library. Full path. This part of the
			   library interfaces with OpenGL. It is not strictly needed
			   in applications.
	  IL_INCLUDE_DIR - where to find the il.h, ilu.h and ilut.h files.
	  DevIL_FOUND	 - this	is set to TRUE if all the above	variables were set.
			   This	will be	set to false if	ILU or ILUT are	not found,
			   even	if they	are not	needed.	In most	systems, if one
			   library is found all	the others are as well.	That's the
			   way the DevIL developers release it.

   FindDoxygen
       This module looks for Doxygen and the path to Graphviz's	dot

       Doxygen	  is	a   documentation   generation	 tool.	  Please   see
       http://www.doxygen.org

       This module accepts the following optional variables:

	  DOXYGEN_SKIP_DOT	 = If true this	module will skip trying	to find	Dot
				   (an optional	component often	used by	Doxygen)

       This modules defines the	following variables:

	  DOXYGEN_EXECUTABLE	 = The path to the doxygen command.
	  DOXYGEN_FOUND		 = Was Doxygen found or	not?
	  DOXYGEN_VERSION	 = The version reported	by doxygen --version

	  DOXYGEN_DOT_EXECUTABLE = The path to the dot program used by doxygen.
	  DOXYGEN_DOT_FOUND	 = Was Dot found or not?

       For compatibility with older  versions  of  CMake,  the	now-deprecated
       variable	 DOXYGEN_DOT_PATH is set to the	path to	the directory contain-
       ing dot as reported in DOXYGEN_DOT_EXECUTABLE.  The path	may have  for-
       ward  slashes  even on Windows and is not suitable for direct substitu-
       tion into  a  Doxyfile.in  template.   If  you  need  this  value,  use
       get_filename_component()	 to compute it from DOXYGEN_DOT_EXECUTABLE di-
       rectly, and perhaps the file(TO_NATIVE_PATH)  command  to  prepare  the
       path for	a Doxygen configuration	file.

   FindEXPAT
       Find expat

       Find the	native EXPAT headers and libraries.

	  EXPAT_INCLUDE_DIRS - where to	find expat.h, etc.
	  EXPAT_LIBRARIES    - List of libraries when using expat.
	  EXPAT_FOUND	     - True if expat found.

   FindFLEX
       Find  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.  If COMPILE_FLAGS option is specified,  the  next
       parameter  is  added to the flex	command	line. If flex is configured to
       output a	header file, the DEFINES_FILE option may be  used  to  specify
       its  name. Name is an alias used	to get details of this custom command.
       Indeed 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 oftenly 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}
	   )
	  ====================================================================

   FindFLTK2
       Find the	native FLTK2 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

   FindFLTK
       Find the	native FLTK includes and library

       By default FindFLTK.cmake 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 following	three options:

	  FLTK_SKIP_OPENGL, set	to true	to disable searching for opengl	and
			    the	FLTK GL	library
	  FLTK_SKIP_FORMS, set to true to disable searching for	fltk_forms
	  FLTK_SKIP_IMAGES, set	to true	to disable searching for fltk_images

	  FLTK_SKIP_FLUID, set to true if the fluid binary need	not be present
			   at build time

       The following variables will be defined:

	  FLTK_FOUND, True if all components not skipped were found
	  FLTK_INCLUDE_DIR, where to find include files
	  FLTK_LIBRARIES, list of fltk libraries you should link against
	  FLTK_FLUID_EXECUTABLE, where to find the Fluid tool
	  FLTK_WRAP_UI,	This enables the FLTK_WRAP_UI command

       The following cache variables are assigned but should not be used.  See
       the FLTK_LIBRARIES variable instead.

	  FLTK_BASE_LIBRARY   =	the full path to fltk.lib
	  FLTK_GL_LIBRARY     =	the full path to fltk_gl.lib
	  FLTK_FORMS_LIBRARY  =	the full path to fltk_forms.lib
	  FLTK_IMAGES_LIBRARY =	the full path to fltk_images.lib

   FindFreetype
       Locate FreeType library

       This module defines

	  FREETYPE_LIBRARIES, the library to link against
	  FREETYPE_FOUND, if false, do not try to link to FREETYPE
	  FREETYPE_INCLUDE_DIRS, where to find headers.
	  FREETYPE_VERSION_STRING, the version of freetype found (since	CMake 2.8.8)
	  This is the concatenation of the paths:
	  FREETYPE_INCLUDE_DIR_ft2build
	  FREETYPE_INCLUDE_DIR_freetype2

       $FREETYPE_DIR is	an environment variable	that would correspond to the

   FindGCCXML
       Find the	GCC-XML	front-end executable.

       This module will	define the following variables:

	  GCCXML - the GCC-XML front-end executable.

   FindGDAL
       Locate gdal

       This module accepts the following environment variables:

	  GDAL_DIR or GDAL_ROOT	- Specify the location of GDAL

       This module defines the following CMake variables:

	  GDAL_FOUND - True if libgdal is found
	  GDAL_LIBRARY - A variable pointing to	the GDAL library
	  GDAL_INCLUDE_DIR - Where to find the headers

   FindGettext
       Find GNU	gettext	tools

       This module looks for the GNU gettext tools.  This module  defines  the
       following values:

	  GETTEXT_MSGMERGE_EXECUTABLE: the full	path to	the msgmerge tool.
	  GETTEXT_MSGFMT_EXECUTABLE: the full path to the msgfmt tool.
	  GETTEXT_FOUND: True if gettext has been found.
	  GETTEXT_VERSION_STRING: the version of gettext found (since CMake 2.8.8)

       Additionally it provides	the following macros:

       GETTEXT_CREATE_TRANSLATIONS ( outputFile	[ALL] file1 ...	 fileN )

	  This will create a target "translations" which will convert the
	  given	input po files into the	binary output mo file. If the
	  ALL option is	used, the translations will also be created when
	  building the default target.

       GETTEXT_PROCESS_POT_FILE(  <potfile>  [ALL] [INSTALL_DESTINATION	<dest-
       dir>] LANGUAGES <lang1> <lang2> ...  )

	  Process the given pot	file to	mo files.
	  If INSTALL_DESTINATION is given then automatically install rules will
	  be created, the language subdirectory	will be	taken into account
	  (by default use share/locale/).
	  If ALL is specified, the pot file is processed when building the all traget.
	  It creates a custom target "potfile".

       GETTEXT_PROCESS_PO_FILES(  <lang>  [ALL]	 [INSTALL_DESTINATION	<dir>]
       PO_FILES	<po1> <po2> ...	 )

	  Process the given po files to	mo files for the given language.
	  If INSTALL_DESTINATION is given then automatically install rules will
	  be created, the language subdirectory	will be	taken into account
	  (by default use share/locale/).
	  If ALL is specified, the po files are	processed when building	the all	traget.
	  It creates a custom target "pofiles".

       NOTE:
	  If you wish to use the Gettext library (libintl), use	FindIntl.

   FindGIF
       This finds the GIF library (giflib)

       The module defines the following	variables:

       GIF_FOUND
	      True if giflib was found

       GIF_LIBRARIES
	      Libraries	to link	to in order to use giflib

       GIF_INCLUDE_DIR
	      where to find the	headers

       GIF_VERSION
	      3, 4 or a	full version string (eg	5.1.4) for versions >= 4.1.6

       The minimum required version of giflib can be specified using the stan-
       dard syntax, e.g.  find_package(GIF 4)

       $GIF_DIR	is an environment variable that	would correspond to the

   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.

       Example usage:

	  find_package(Git)
	  if(Git_FOUND)
	    message("Git found:	${GIT_EXECUTABLE}")
	  endif()

   FindGLEW
       Find the	OpenGL Extension Wrangler Library (GLEW)

   IMPORTED Targets
       This module defines the IMPORTED	target GLEW::GLEW, if  GLEW  has  been
       found.

   Result Variables
       This module defines the following variables:

	  GLEW_INCLUDE_DIRS - include directories for GLEW
	  GLEW_LIBRARIES - libraries to	link against GLEW
	  GLEW_FOUND - true if GLEW has	been found and can be used

   FindGLUT
       try to find glut	library	and include files.

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

   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
       Try to find the GNU Transport Layer Security library (gnutls)

       Once done this will define

	  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

   FindGSL
       Find the	native 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.   For  Unix-like  systems,
       this  script will use $GSL_ROOT_DIR/bin/gsl-config (if found) to	aid in
       the discovery 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.

   Imported targets
       This module defines the following IMPORTED targets:

       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::Main)

	  add_test(AllTestsInFoo foo)

   Deeper integration with CTest
       If  you	would  like each Google	test to	show up	in CTest as a test you
       may use the following macro:

	  GTEST_ADD_TESTS(executable extra_args	files...)

       executable
	      the path to the test executable

       extra_args
	      a	list of	extra arguments	to be passed to	executable enclosed in
	      quotes (or "" for	none)

       files...
	      a	 list  of  source files	to search for tests and	test fixtures.
	      Or AUTO to find them from	executable target

       However,	note that this macro will slow down your tests by  running  an
       executable for each test	and test fixture.

       Example usage:

	  set(FooTestArgs --foo	1 --bar	2)
	  add_executable(FooTest FooUnitTest.cc)
	  GTEST_ADD_TESTS(FooTest "${FooTestArgs}" AUTO)

   FindGTK2
       FindGTK2.cmake

       This module can find the	GTK2 widget libraries and several of its other
       optional	components like	gtkmm, glade, and glademm.

       NOTE: If	you intend to use version checking, CMake 2.6.2	or later is

	  required.

       Specify one or more of the following components as you call  this  find
       module.	See example below.

	  gtk
	  gtkmm
	  glade
	  glademm

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

       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)

	  if(GTK2_FOUND)
	     include_directories(${GTK2_INCLUDE_DIRS})
	     add_executable(mygui mygui.cc)
	     target_link_libraries(mygui ${GTK2_LIBRARIES})
	  endif()

   FindGTK
       try to find GTK (and 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

   FindHDF5
       Find  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	only valid components are C,  CXX,  Fortran,  HL,  and
       Fortran_HL.   If	 the COMPONENTS	argument is not	given, the module will
       attempt to find only the	C bindings.

       On UNIX systems,	this module will read the variable HDF5_USE_STATIC_LI-
       BRARIES	to  determine  whether or not to prefer	a static link to a dy-
       namic 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_package.

       To provide the module with a hint about where to	find your HDF5 instal-
       lation,	you can	set the	environment variable HDF5_ROOT.	 The Find mod-
       ule will	then look in this path when searching  for  HDF5  executables,
       paths, and libraries.

       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.

       This module will	define the following variables:

	  HDF5_FOUND - true if HDF5 was	found on the system
	  HDF5_VERSION - HDF5 version in format	Major.Minor.Release
	  HDF5_INCLUDE_DIRS - Location of the hdf5 includes
	  HDF5_INCLUDE_DIR - Location of the hdf5 includes (deprecated)
	  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 will be
       defined.	 If the	HL component is	enabled, then  an  HDF5_${LANG}_HL_LI-
       BRARIES will also be defined.  With all components enabled, the follow-
       ing variables will be defined:

	  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 - Whether or	not HDF5 was found with	parallel IO support
	  HDF5_C_COMPILER_EXECUTABLE - the path	to the HDF5 C wrapper compiler
	  HDF5_CXX_COMPILER_EXECUTABLE - the path to the HDF5 C++ wrapper compiler
	  HDF5_Fortran_COMPILER_EXECUTABLE - the 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 - the path to the HDF5 dataset comparison tool

       The following variable can be set to guide  the	search	for  HDF5  li-
       braries and includes:

       HDF5_ROOT
	      Specify the path to the HDF5 installation	to use.

       HDF5_NO_FIND_PACKAGE_CONFIG_FILE
	      Set to a true value 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

       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 Hspell

       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
       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, IceGrid, IcePatch, IceSSL,
       IceStorm, IceUtil, IceXML, or Slice.

       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.

       Ice slice programs are reported in:

	  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_SLICE2PHP_EXECUTABLE - path to slice2php executable
	  Ice_SLICE2PY_EXECUTABLE - path to slice2py executable
	  Ice_SLICE2RB_EXECUTABLE - path to slice2rb executable

       Ice programs are	reported in:

	  Ice_GLACIER2ROUTER_EXECUTABLE	- path to glacier2router executable
	  Ice_ICEBOX_EXECUTABLE	- path to icebox executable
	  Ice_ICEBOXADMIN_EXECUTABLE - path to iceboxadmin executable
	  Ice_ICEBOXD_EXECUTABLE - path	to iceboxd executable
	  Ice_ICEBOXNET_EXECUTABLE - path to iceboxnet executable
	  Ice_ICEGRIDADMIN_EXECUTABLE -	path to	icegridadmin 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_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.

       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.

   FindIcotool
       Find icotool

       This module looks for icotool.  This module defines the following  val-
       ues:

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

       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.

       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
	  ICU_<C>_LIBRARIES - libraries	for component

       Note that <C> is	the uppercased name of the component.

       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>
	  ICU_INCLUDE_DIR - the	directory containing the ICU headers
	  ICU_<C>_LIBRARY - the	library	for component <C>

       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 the	ImageMagick binary suite.

       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
       Find the	Gettext	libintl	headers	and libraries.

       This  module reports information	about the Gettext libintl installation
       in several variables.  General variables:

	  Intl_FOUND - true if the libintl headers and libraries were found
	  Intl_INCLUDE_DIRS - the directory containing the libintl headers
	  Intl_LIBRARIES - libintl libraries to	be linked

       The following cache variables may also be set:

	  Intl_INCLUDE_DIR - the directory containing the libintl headers
	  Intl_LIBRARY - the libintl library (if any)

       NOTE:
	  On some platforms, such as Linux with	GNU libc,  the	gettext	 func-
	  tions	 are  present in the C standard	library	and libintl is not re-
	  quired.  Intl_LIBRARIES will be empty	in this	case.

       NOTE:
	  If you wish to use the Gettext tools (msgmerge, msgfmt,  etc.),  use
	  FindGettext.

   FindITK
       This module no longer exists.

       This  module existed in versions	of CMake prior to 3.1, but became only
       a thin wrapper around find_package(ITK NO_MODULE) to  provide  compati-
       bility  for  projects  using long-outdated conventions.	Now find_pack-
       age(ITK)	will search for	ITKConfig.cmake	directly.

   FindJasper
       Try to find the Jasper JPEG2000 library

       Once done this will define

	  JASPER_FOUND - system	has Jasper
	  JASPER_INCLUDE_DIR - the Jasper include directory
	  JASPER_LIBRARIES - the libraries needed to use Jasper
	  JASPER_VERSION_STRING	- the version of Jasper	found (since CMake 2.8.8)

   FindJava
       Find Java

       This module finds if Java is installed and determines where the include
       files  and  libraries  are.   The  caller may set variable JAVA_HOME to
       specify a Java installation prefix explicitly.

       See also	the FindJNI module to find Java	development tools.

       Specify one or more of the following components as you call  this  find
       module. See example below.

	  Runtime     =	User just want to execute some Java byte-compiled
	  Development =	Development tools (java, javac,	javah and javadoc), includes Runtime component
	  IdlJ	      =	idl compiler for Java
	  JarSigner   =	signer tool for	jar

       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)

       The  minimum  required version of Java can be specified using the stan-
       dard CMake syntax, e.g.	find_package(Java 1.5)

       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.5.0_17 and Java_VERSION = 1.5.0.17

       another example is the Java OEM,	with: Java_VERSION_STRING =  1.6.0-oem
       and Java_VERSION	= 1.6.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 COMPONENTS Runtime)
	  find_package(Java COMPONENTS Development)

   FindJNI
       Find JNI	java libraries.

       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.

       This module sets	the following result variables:

	  JNI_INCLUDE_DIRS	= the include dirs to use
	  JNI_LIBRARIES		= the libraries	to use
	  JNI_FOUND		= TRUE if JNI headers and libraries were found.
	  JAVA_AWT_LIBRARY	= the path to the jawt library
	  JAVA_JVM_LIBRARY	= the path to the jvm library
	  JAVA_INCLUDE_PATH	= the include path to jni.h
	  JAVA_INCLUDE_PATH2	= the include path to jni_md.h
	  JAVA_AWT_INCLUDE_PATH	= the include path to jawt.h

   FindJPEG
       Find JPEG

       Find the	native JPEG includes and library This module defines

	  JPEG_INCLUDE_DIR, where to find jpeglib.h, etc.
	  JPEG_LIBRARIES, the libraries	needed to use JPEG.
	  JPEG_FOUND, If false,	do not try to use JPEG.

       also defined, but not for general use are

	  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 LAPACK library

       This module finds an installed fortran library that implements the  LA-
       PACK linear-algebra interface (see http://www.netlib.org/lapack/).

       The  approach  follows  that taken for the autoconf macro file, acx_la-
       pack.m4			       (distributed			    at
       http://ac-archive.sourceforge.net/ac-archive/acx_lapack.html).

       This module sets	the following variables:

	  LAPACK_FOUND - set to	true if	a 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 - set to true if a library implementing the LAPACK f95
	    interface is found
	  BLA_STATIC  if set on	this determines	what kind of linkage we	do (static)
	  BLA_VENDOR  if set checks only the specified vendor, if not set checks
	     all the possibilities
	  BLA_F95     if set on	tries to find the f95 interfaces for BLAS/LAPACK

       List of vendors (BLA_VENDOR) valid in this module:

       o Intel(mkl)

       o OpenBLAS

       o ACML

       o Apple

       o NAS

       o Generic

   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.

       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

       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

   FindLibLZMA
       Find LibLZMA

       Find LibLZMA headers and	library

	  LIBLZMA_FOUND		    - True if liblzma is 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
       Try to find the LibXml2 xml processing library

       Once done this will define

	  LIBXML2_FOUND	- System has LibXml2
	  LIBXML2_INCLUDE_DIR -	The LibXml2 include directory
	  LIBXML2_LIBRARIES - The libraries needed to use LibXml2
	  LIBXML2_DEFINITIONS -	Compiler switches required for using LibXml2
	  LIBXML2_XMLLINT_EXECUTABLE - The XML checking	tool xmllint coming with LibXml2
	  LIBXML2_VERSION_STRING - the version of LibXml2 found	(since CMake 2.8.8)

   FindLibXslt
       Try to find the LibXslt library

       Once done this will define

	  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_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
       This module finds the 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

   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/

   FindLua
       Locate Lua library This module defines

	  LUA_FOUND	     - if false, do not	try to link to Lua
	  LUA_LIBRARIES	     - both lua	and lualib
	  LUA_INCLUDE_DIR    - where to	find lua.h
	  LUA_VERSION_STRING - the version of Lua found
	  LUA_VERSION_MAJOR  - the major version of Lua
	  LUA_VERSION_MINOR  - the minor 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/

   FindMatlab
       Finds Matlab installations and provides Matlab tools and	 libraries  to
       cmake.

       This  package  first intention is to find the libraries associated with
       Matlab in order to be able to build Matlab extensions (mex  files).  It
       can also	be used:

       o run specific commands in Matlab

       o declare Matlab	unit test

       o retrieve  various  information	 from Matlab (mex extensions, versions
	 and release queries, ...)

       The module supports the following components:

       o MX_LIBRARY, ENG_LIBRARY and MAT_LIBRARY: respectively the MX, ENG and
	 MAT libraries of Matlab

       o MAIN_PROGRAM the Matlab binary	program.

       o MEX_COMPILER the MEX compiler.

       o SIMULINK the Simulink environment.

       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() allow a mapping from the  re-
	  lease	name to	the version.

       The variable Matlab_ROOT_DIR may	be specified in	order to give the path
       of the desired Matlab version. Otherwise,  the  behaviour  is  platform
       specific:

       o Windows: The installed	versions of Matlab are retrieved from the Win-
	 dows registry

       o OS X: The installed versions of Matlab	are given by the MATLAB	 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.

       Additional information is provided when MATLAB_FIND_DEBUG is set.  When
       a  Matlab  binary  is found automatically and the MATLAB_VERSION	is not
       given, the version is queried from Matlab directly.  On Windows,	it can
       make a window running Matlab appear.

       The mapping of the release names	and the	version	of Matlab is performed
       by    defining	  pairs	    (name,     version).      The     variable
       MATLAB_ADDITIONAL_VERSIONS  may	be  provided  before  the  call	to the
       find_package() in order to handle additional versions.

       A  Matlab  scripts  can	be  added  to  the  set	 of  tests  using  the
       matlab_add_unit_test(). By default, the Matlab unit test	framework will
       be used (>= 2013a) to run this script, but regular .m  files  returning
       an exit code can	be used	as well	(0 indicating a	success).

   Module Input	Variables
       Users or	projects may set the following variables to configure the mod-
       ule behaviour:

       Matlab_ROOT_DIR
	      the root of the Matlab installation.

       MATLAB_FIND_DEBUG
	      outputs debug information

       MATLAB_ADDITIONAL_VERSIONS
	      additional versions of Matlab for	the automatic retrieval	of the
	      installed	versions.

   Variables defined by	the module
   Result variables
       Matlab_FOUND
	      TRUE  if	the Matlab installation	is found, FALSE	otherwise. All
	      variable below are defined if Matlab is found.

       Matlab_ROOT_DIR
	      the final	root of	the  Matlab  installation  determined  by  the
	      FindMatlab module.

       Matlab_MAIN_PROGRAM
	      the  Matlab  binary  program.  Available	only  if the component
	      MAIN_PROGRAM is given in the find_package() directive.

       Matlab_INCLUDE_DIRS
	      the path of the Matlab libraries headers

       Matlab_MEX_LIBRARY
	      library for mex, always available.

       Matlab_MX_LIBRARY
	      mx library of Matlab (arrays). Available only if	the  component
	      MX_LIBRARY has been requested.

       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_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 asked

   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 paths, according to a previously
	      given list. Only the existing/accessible paths are kept. This is
	      mainly  useful  for  the searching all possible Matlab installa-
	      tion.

       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, given the full directory	of the
	      Matlab program.

   Known issues
       Symbol clash in a MEX target
	      By default, every	symbols	inside a MEX  file  defined  with  the
	      command  matlab_add_mex()	have hidden visibility,	except for the
	      entry point. This	is the default behaviour of the	MEX  compiler,
	      which  lowers the	risk of	symbol collision between the libraries
	      shipped with Matlab, and the libraries to	which the MEX file  is
	      linking to. This is also the default on Windows platforms.

	      However,	this  is not sufficient	in certain case, where for in-
	      stance your MEX file is linking against libraries	that  are  al-
	      ready  loaded  by	Matlab,	even if	those libraries	have different
	      SONAMES.	A possible solution is to hide the symbols of the  li-
	      braries  to  which  the  MEX  target  is linking to. This	can be
	      achieved in GNU GCC compilers with the linker  option  -Wl,--ex-
	      clude-libs,ALL.

       Tests using GPU resources
	      in  case	your MEX file is using the GPU and in order to be able
	      to run unit tests	on this	MEX file, the GPU resources should  be
	      properly released	by Matlab. A possible solution is to make Mat-
	      lab aware	of the use of the GPU resources	in the session,	 which
	      can be performed by a command such as D =	gpuDevice() at the be-
	      ginning of the test script (or via a fixture).

   Reference
       Matlab_ROOT_DIR
	      The root folder of the Matlab installation. If  set  before  the
	      call  to find_package(), the module will look for	the components
	      in that path. If not set,	then an	 automatic  search  of	Matlab
	      will be performed. If set, it should point to a valid version of
	      Matlab.

       MATLAB_FIND_DEBUG
	      If set, the lookup of Matlab and the intermediate	 configuration
	      steps are	outputted to the console.

       MATLAB_ADDITIONAL_VERSIONS
	      If  set,	specifies  additional  versions	 of Matlab that	may be
	      looked for.  The variable	should be a list of strings, organised
	      by pairs of release name and versions, such as follows:

		 set(MATLAB_ADDITIONAL_VERSIONS
		     "release_name1=corresponding_version1"
		     "release_name2=corresponding_version2"
		     ...
		     )

	      Example:

		 set(MATLAB_ADDITIONAL_VERSIONS
		     "R2013b=8.2"
		     "R2013a=8.1"
		     "R2012b=8.0")

	      The  order of entries in this list matters when several versions
	      of Matlab	are installed. The priority is set  according  to  the
	      ordering in this list.

       matlab_get_version_from_release_name
	      Returns  the  version  of	 Matlab	 (17.58)  from	a release name
	      (R2017k)

       matlab_get_release_name_from_version
	      Returns the release name (R2017k)	from  the  version  of	Matlab
	      (17.58)

       matlab_extract_all_installed_versions_from_registry
	      This function parses the registry	and founds the Matlab versions
	      that are installed. The found  versions  are  returned  in  mat-
	      lab_versions.  Set win64 to TRUE if the 64 bit version of	Matlab
	      should be	looked for The returned	list contains all versions un-
	      der  HKLM\\SOFTWARE\\Mathworks\\MATLAB  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.  The
	      returned matlab_roots is organized in pairs (version_number,mat-
	      lab_root_path).

		 matlab_get_all_valid_matlab_roots_from_registry(
		     matlab_versions
		     matlab_roots)

	      matlab_versions
		     the versions of each of the Matlab	installations

	      matlab_roots
		     the location of each of the Matlab	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 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.

		 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.  The	unit test uses
	      the Matlab unittest framework (default, available	starting  Mat-
	      lab 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_MATLAB_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_MATLAB_COMMAND
		     Matlab script command to run as the test.	If this	is not
		     set,   then   the	 following   is	  run:	runtests('mat-
		     lab_file_name'), exit(max([ans(1,:).Failed])) where  mat-
		     lab_file_name is the UNITTEST_FILE	without	the extension.

	      UNITTEST_PRECOMMAND
		     Matlab  script command to be ran before the file contain-
		     ing the test (eg.	GPU  device  initialisation  based  on
		     CMake variables).

	      TIMEOUT
		     the  test	timeout	in seconds. Defaults to	180 seconds as
		     the Matlab	unit test may hang.

	      ADDITIONAL_PATH
		     a list of paths to	add to the Matlab path prior  to  run-
		     ning the unit test.

	      MATLAB_ADDITIONAL_STARTUP_OPTIONS
		     a	list  of additional option in order to run Matlab from
		     the command line.	-nosplash  -nodesktop  -nodisplay  are
		     always added.

	      TEST_ARGS
		     Additional	 options  provided  to	the  add_test command.
		     These options are added to	the default options (eg. "CON-
		     FIGURATIONS Release")

	      NO_UNITTEST_FRAMEWORK
		     when  set,	 indicates  that  the  test should not use the
		     unittest framework	of Matlab (available for  versions  >=
		     R2013a).

	      WORKING_DIRECTORY
		     This will be the working directory	for the	test. If spec-
		     ified it will also	be the output directory	used  for  the
		     log  file of the test run.	 If not	specifed 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 ...]
		     [...]
		 )

	      NAME   name of the target.

	      SRC    list of source files.

	      LINK_TO
		     a list of additional link dependencies.  The target links
		     to	libmex by default. If Matlab_MX_LIBRARY	is defined, it
		     also links	to libmx.

	      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.

	      MODULE  or SHARED	may be given to	specify	the type of library to
	      be
		     created. EXECUTABLE may be	given to create	an  executable
		     instead of	a library. If no type is given explicitly, the
		     type is SHARED.

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

   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.

   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.

   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.	All of
       them have somewhat different include paths, libraries to	link  against,
       etc., and this module tries to smooth out those differences.

   Variables
       This  module  will  set	the  following	variables per language in your
       project,	where <lang> is	one of C, CXX, or Fortran:

	  MPI_<lang>_FOUND	     TRUE if FindMPI found MPI flags for <lang>
	  MPI_<lang>_COMPILER	     MPI Compiler wrapper for <lang>
	  MPI_<lang>_COMPILE_FLAGS   Compilation flags for MPI programs
	  MPI_<lang>_INCLUDE_PATH    Include path(s) for MPI header
	  MPI_<lang>_LINK_FLAGS	     Linking flags for MPI programs
	  MPI_<lang>_LIBRARIES	     All libraries to link MPI programs	against

       Additionally, FindMPI sets the following	variables for running MPI pro-
       grams from the command line:

	  MPIEXEC		     Executable	for running MPI	programs
	  MPIEXEC_NUMPROC_FLAG	     Flag to pass to MPIEXEC before giving
				     it	the number of processors to run	on
	  MPIEXEC_PREFLAGS	     Flags to pass to MPIEXEC directly
				     before the	executable to run.
	  MPIEXEC_POSTFLAGS	     Flags to pass to MPIEXEC after other flags

   Usage
       To  use this module, simply call	FindMPI	from a CMakeLists.txt file, or
       run find_package(MPI), then run CMake.	If  you	 are  happy  with  the
       auto-detected  configuration  for  your language, then you're done.  If
       not, you	have two options:

	  1. Set MPI_<lang>_COMPILER to	the MPI	wrapper	(mpicc,	etc.) of your
	     choice and	reconfigure.  FindMPI will attempt to determine	all the
	     necessary variables using THAT compiler's compile and link	flags.
	  2. If	this fails, or if your MPI implementation does not come	with
	     a compiler	wrapper, then set both MPI_<lang>_LIBRARIES and
	     MPI_<lang>_INCLUDE_PATH.  You may also set	any other variables
	     listed above, but these two are required.	This will circumvent
	     autodetection entirely.

       When configuration is successful, MPI_<lang>_COMPILER will  be  set  to
       the compiler wrapper for	<lang>,	if it was found.  MPI_<lang>_FOUND and
       other variables above will be set if any	MPI implementation  was	 found
       for <lang>, regardless of whether a compiler was	found.

       When  using  MPIEXEC  to	execute	MPI applications, you should typically
       use all of the MPIEXEC flags as follows:

	  ${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} PROCS
	    ${MPIEXEC_PREFLAGS}	EXECUTABLE ${MPIEXEC_POSTFLAGS}	ARGS

       where PROCS is the number of processors on which	to  execute  the  pro-
       gram, EXECUTABLE	is the MPI program, and	ARGS are the arguments to pass
       to the MPI program.

   Backward Compatibility
       For backward compatibility with older versions of FindMPI, these	 vari-
       ables are set, but deprecated:

	  MPI_FOUND	      MPI_COMPILER	  MPI_LIBRARY
	  MPI_COMPILE_FLAGS   MPI_INCLUDE_PATH	  MPI_EXTRA_LIBRARY
	  MPI_LINK_FLAGS      MPI_LIBRARIES

       In new projects,	please use the MPI_<lang>_XXX equivalents.

   FindOpenAL
       Locate  OpenAL  This  module  defines  OPENAL_LIBRARY  OPENAL_FOUND, if
       false, do not try to link to OpenAL OPENAL_INCLUDE_DIR, where  to  find
       the headers

       $OPENALDIR is an	environment variable that would	correspond to the

       Created by Eric Wing.  This was influenced by the FindSDL.cmake module.

   FindOpenCL
       Try to find OpenCL

   IMPORTED Targets
       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 GLU.

   IMPORTED Targets
       This module defines the IMPORTED	targets:

       OpenGL::GL
	      Defined if the system has	OpenGL.

       OpenGL::GLU
	      Defined if the system has	GLU.

   Result Variables
       This module sets	the following variables:

       OPENGL_FOUND
	      True, if the system has OpenGL.

       OPENGL_XMESA_FOUND
	      True, if the system has XMESA.

       OPENGL_GLU_FOUND
	      True, if the system has GLU.

       OPENGL_INCLUDE_DIR
	      Path to the OpenGL include directory.

       OPENGL_LIBRARIES
	      Paths to the OpenGL and GLU libraries.

       If you want to use just GL you can use these values:

       OPENGL_gl_LIBRARY
	      Path to the OpenGL library.

       OPENGL_glu_LIBRARY
	      Path to the GLU library.

   OSX Specific
       On OSX default to using the framework version of	 OpenGL.  People  will
       have to change the cache	values of OPENGL_glu_LIBRARY and OPENGL_gl_LI-
       BRARY to	use OpenGL with	X11 on OSX.

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

       The following variables are set:

       OpenMP_C_FLAGS
	      Flags to add to the C compiler for OpenMP	support.

       OpenMP_CXX_FLAGS
	      Flags to add to the CXX compiler for OpenMP support.

       OpenMP_Fortran_FLAGS
	      Flags to add to the Fortran compiler for OpenMP support.

       OPENMP_FOUND
	      True if openmp is	detected.

       The following internal variables	are set, if detected:

       OpenMP_C_SPEC_DATE
	      Specification date of OpenMP version of C	compiler.

       OpenMP_CXX_SPEC_DATE
	      Specification date of OpenMP version of CXX compiler.

       OpenMP_Fortran_SPEC_DATE
	      Specification date of OpenMP version of Fortran compiler.

       The specification dates are formatted as	integers of  the  form	CCYYMM
       where  these  represent	the  decimal  digits of	the century, year, and
       month.

   FindOpenSceneGraph
       Find OpenSceneGraph

       This module searches for	the OpenSceneGraph core	"osg" library as  well
       as  OpenThreads,	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.cmake,  Findosg_functions.cmake,	  Findosg.cmake,   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.

   Imported Targets
       This module defines the following IMPORTED targets:

       OpenSSL::SSL
	      The OpenSSL ssl library, if found.

       OpenSSL::Crypto
	      The OpenSSL crypto library, if found.

   Result Variables
       This module will	set the	following variables in your project:

       OPENSSL_FOUND
	      System has the OpenSSL library.

       OPENSSL_INCLUDE_DIR
	      The OpenSSL include directory.

       OPENSSL_CRYPTO_LIBRARY
	      The OpenSSL crypto library.

       OPENSSL_SSL_LIBRARY
	      The OpenSSL SSL library.

       OPENSSL_LIBRARIES
	      All OpenSSL libraries.

       OPENSSL_VERSION
	      This is set to $major.$minor.$revision$patch (e.g. 0.9.8s).

   Hints
       Set OPENSSL_ROOT_DIR to the root	directory of an	OpenSSL	 installation.
       Set  OPENSSL_USE_STATIC_LIBS to TRUE to look for	static libraries.  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.

   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

       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.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 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
       (use this)

       OSGDB_LIBRARY - The osgDB library OSGDB_LIBRARY_DEBUG - The osgDB debug
       library

       $OSGDIR is an environment variable that would correspond	to the

       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.

   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

       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

       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

       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

       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

       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

       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

       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

       Created	by  Eric Wing.	Modified to work with osgQt by Robert Osfield,
       January 2012.

   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

       Created by Eric Wing.

   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

       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

       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

       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

       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

       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

       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

       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

       FindosgWidget.cmake tweaked from	Findosg*  suite	 as  created  by  Eric
       Wing.

   FindPackageHandleStandardArgs
       This module provides a function intended	to be used in Find Modules im-
       plementing find_package(<PackageName>) calls.  It handles the REQUIRED,
       QUIET  and version-related arguments 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.

       find_package_handle_standard_args
	      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_COMPONENTS]
		   [CONFIG_MODE]
		   [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>
		     Obsolete.	Specifies either <PackageName>_FOUND or	<PACK-
		     AGENAME>_FOUND  as	the result variable.  This exists only
		     for compatibility with older versions of CMake and	is now
		     ignored.	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.

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

	      FAIL_MESSAGE <custom-failure-message>
		     Specify a custom failure message instead of using the de-
		     fault generated message.  Not recommended.

       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.

       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.

   FindPackageMessage
       FIND_PACKAGE_MESSAGE(<name> "message for	user" "find result details")

       This  macro  is intended	to be used in FindXXX.cmake modules files.  It
       will print a message once for each unique find result.  This is	useful
       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()

   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
	  PERL_SITELIB	     = path to the sitelib install directory
	  PERL_VENDORARCH    = path to the vendor arch install directory
	  PERL_VENDORLIB     = path to the vendor lib install directory
	  PERL_ARCHLIB	     = path to the arch	lib install directory
	  PERL_PRIVLIB	     = path to the priv	lib install directory
	  PERL_EXTRA_C_FLAGS = Compilation flags used to build perl

   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)

   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

       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  add	 the  pkg_check_modules()  and
       pkg_search_module() commands.

       In   order   to	 find	the   pkg-config   executable,	 it  uses  the
       PKG_CONFIG_EXECUTABLE variable or the PKG_CONFIG	 environment  variable
       first.

       pkg_get_variable
	      Retrieves	the value of a variable	from a package:

		 pkg_get_variable(<RESULT> <MODULE> <VARIABLE>)

	      For example:

		 pkg_get_variable(GI_GIRDIR gobject-introspection-1.0 girdir)

       pkg_check_modules
	      Checks for all the given modules.

		 pkg_check_modules(<PREFIX> [REQUIRED] [QUIET]
				   [NO_CMAKE_PATH] [NO_CMAKE_ENVIRONMENT_PATH]
				   [IMPORTED_TARGET]
				   <MODULE> [<MODULE>]*)

	      When the REQUIRED	argument was set, macros will fail with	an er-
	      ror when module(s) could not be found.

	      When the QUIET argument is  set,	no  status  messages  will  be
	      printed.

	      By  default,  if CMAKE_MINIMUM_REQUIRED_VERSION is 3.1 or	later,
	      or if PKG_CONFIG_USE_CMAKE_PREFIX_PATH is	 set,  the  CMAKE_PRE-
	      FIX_PATH,	 CMAKE_FRAMEWORK_PATH,	and CMAKE_APPBUNDLE_PATH cache
	      and environment variables	will be	 added	to  pkg-config	search
	      path.  The NO_CMAKE_PATH and NO_CMAKE_ENVIRONMENT_PATH arguments
	      disable this behavior for	the cache variables and	 the  environ-
	      ment variables, respectively.  The IMPORTED_TARGET argument will
	      create an	imported target	named PkgConfig::<PREFIX>> that	can be
	      passed directly as an argument to	target_link_libraries().

	      It sets the following variables:

		 PKG_CONFIG_FOUND	   ... if pkg-config executable	was found
		 PKG_CONFIG_EXECUTABLE	   ... pathname	of the pkg-config program
		 PKG_CONFIG_VERSION_STRING ... the version of the pkg-config program found
					       (since CMake 2.8.8)

	      For  the following variables two sets of values exist; first one
	      is the common one	and has	the given PREFIX.  The second set con-
	      tains  flags which are given out when pkg-config was called with
	      the --static option.

		 <XPREFIX>_FOUND	  ... set to 1 if module(s) exist
		 <XPREFIX>_LIBRARIES	  ... only the libraries (w/o the '-l')
		 <XPREFIX>_LIBRARY_DIRS	  ... the paths	of the libraries (w/o the '-L')
		 <XPREFIX>_LDFLAGS	  ... all required linker flags
		 <XPREFIX>_LDFLAGS_OTHER  ... all other	linker flags
		 <XPREFIX>_INCLUDE_DIRS	  ... the '-I' preprocessor flags (w/o the '-I')
		 <XPREFIX>_CFLAGS	  ... all required cflags
		 <XPREFIX>_CFLAGS_OTHER	  ... the other	compiler flags

		 <XPREFIX> = <PREFIX>	     for common	case
		 <XPREFIX> = <PREFIX>_STATIC for static	linking

	      There are	some special variables whose  prefix  depends  on  the
	      count of given modules.  When there is only one module, <PREFIX>
	      stays unchanged.	When there are multiple	 modules,  the	prefix
	      will be changed to <PREFIX>_<MODNAME>:

		 <XPREFIX>_VERSION    ... version of the module
		 <XPREFIX>_PREFIX     ... prefix-directory of the module
		 <XPREFIX>_INCLUDEDIR ... include-dir of the module
		 <XPREFIX>_LIBDIR     ... lib-dir of the module

		 <XPREFIX> = <PREFIX>  when |MODULES| == 1, else
		 <XPREFIX> = <PREFIX>_<MODNAME>

	      A	<MODULE> parameter can have the	following formats:

		 {MODNAME}	      ... matches any version
		 {MODNAME}>={VERSION} ... at least version <VERSION> is	required
		 {MODNAME}={VERSION}  ... exactly version <VERSION> is required
		 {MODNAME}<={VERSION} ... modules must not be newer than <VERSION>

	      Examples

		 pkg_check_modules (GLIB2   glib-2.0)

		 pkg_check_modules (GLIB2   glib-2.0>=2.10)

	      Requires	at  least  version  2.10  of  glib2  and  defines e.g.
	      GLIB2_VERSION=2.10.3

		 pkg_check_modules (FOO	    glib-2.0>=2.10 gtk+-2.0)

	      Requires	 both	glib2	and    gtk2,	and    defines	  e.g.
	      FOO_glib-2.0_VERSION=2.10.3 and FOO_gtk+-2.0_VERSION=2.8.20

		 pkg_check_modules (XRENDER REQUIRED xrender)

	      Defines for example:

		 XRENDER_LIBRARIES=Xrender;X11``
		 XRENDER_STATIC_LIBRARIES=Xrender;X11;pthread;Xau;Xdmcp

       pkg_search_module
	      Same  as	pkg_check_modules(),  but  instead it checks for given
	      modules and uses the first working one.

		 pkg_search_module(<PREFIX> [REQUIRED] [QUIET]
				   [NO_CMAKE_PATH] [NO_CMAKE_ENVIRONMENT_PATH]
				   [IMPORTED_TARGET]
				   <MODULE> [<MODULE>]*)

	      Examples

		 pkg_search_module (BAR	    libxml-2.0 libxml2 libxml>=2)

       PKG_CONFIG_EXECUTABLE
	      Path to the pkg-config executable.

       PKG_CONFIG_USE_CMAKE_PREFIX_PATH
	      Whether pkg_check_modules() and pkg_search_module()  should  add
	      the   paths   in	CMAKE_PREFIX_PATH,  CMAKE_FRAMEWORK_PATH,  and
	      CMAKE_APPBUNDLE_PATH cache and environment variables to pkg-con-
	      fig 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
       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.

       This module defines

	  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 (since CMake 2.8.8)

   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

       Created by Eric Wing.

   FindProtobuf
       Locate and configure the	Google Protocol	Buffers	library.

       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
	      Show debug messages.

       Defines the following variables:

       Protobuf_FOUND
	      Found  the Google	Protocol Buffers library (libprotobuf &	header
	      files)

       Protobuf_VERSION
	      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

       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_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> [<ARGN>...])

	      SRCS   Variable to define	with autogenerated source files

	      HDRS   Variable to define	with autogenerated header files

	      ARGN   .proto files

       protobuf_generate_python
	      Add custom commands to process .proto files to Python:

		 protobuf_generate_python (<PY>	[<ARGN>...])

	      PY     Variable to define	with autogenerated Python files

	      ARGN   .proto filess

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

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

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

   FindQt
       Searches	for all	installed versions of Qt.

       This  should  only  be used if your project can work with multiple ver-
       sions 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.

       This module can only detect and switch between Qt versions 3 and	4.  It
       cannot handle Qt5 or any	later versions.

	  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.

   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

       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, 1.9,	2.0 and	2.1 are	supported.

       The  minimum  required version of Ruby can be specified using the stan-
       dard syntax, e.g.  find_package(Ruby 1.8)

       It also determines what the name	of the library is.  This code sets the
       following variables:

       RUBY_EXECUTABLE
	      full path	to the ruby binary

       RUBY_INCLUDE_DIRS
	      include dirs to be used when using the ruby library

       RUBY_LIBRARY
	      full path	to the ruby library

       RUBY_VERSION
	      the version of ruby which	was found, e.g.	"1.8.7"

       RUBY_FOUND
	      set to true if ruby ws found successfully

       Also:

       RUBY_INCLUDE_PATH
	      same  as RUBY_INCLUDE_DIRS, only provided	for compatibility rea-
	      sons, don't use it

   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

       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

       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

       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
       Locate SDL library

       This module defines

	  SDL_LIBRARY, the name	of the library to link against
	  SDL_FOUND, if	false, do not try to link to SDL
	  SDL_INCLUDE_DIR, where to find SDL.h
	  SDL_VERSION_STRING, human-readable string containing the version of 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_LIBRARY	variable.

       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

       Modified	by Eric	Wing.  Added code to assist with automated building by
       using environmental variables and providing a  more  controlled/consis-
       tent search behavior.  Added new	modifications to recognize OS X	frame-
       works and additional Unix paths (FreeBSD,  etc).	  Also	corrected  the
       header  search  path to follow "proper" SDL guidelines.	Added a	search
       for SDLmain which is needed by some  platforms.	 Added	a  search  for
       threads	which  is  needed  by  some  platforms.	  Added	needed compile
       switches	for MinGW.

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

       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.	Currently  Squish  versions  3
       and 4 are supported.

	  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_v4_add_test() for adding a squish test
       to cmake	using Squish 4.x:

	  squish_v4_add_test(cmakeTestName
	    AUT	targetName SUITE suiteName TEST	squishTestName
	    [SETTINGSGROUP group] [PRE_COMMAND command]	[POST_COMMAND command] )

       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
	      if  specified, the given settings	group will be used for execut-
	      ing  the	test.	If  not	 specified,  the  groupname  will   be
	      "CTest_<username>"

       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 4.0)
	  if (SQUISH_FOUND)
	     squish_v4_add_test(myTestName
	       AUT myApp
	       SUITE ${CMAKE_SOURCE_DIR}/tests/mySuite
	       TEST someSquishTest
	       SETTINGSGROUP myGroup
	       )
	  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)
	  if (SQUISH_FOUND)
	    squish_v3_add_test(myTestName myApplication	testCase envVars testWrapper)
	  endif	()

       macro SQUISH_ADD_TEST(testName  applicationUnderTest  testCase  envVars
       testWrapper)

	  This is deprecated. Use SQUISH_V3_ADD_TEST() if you are using	Squish 3.x instead.

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

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

       This module finds an installed SWIG.  It	sets the following variables:

	  SWIG_FOUND - set to true if SWIG is found
	  SWIG_DIR - the directory where swig is installed
	  SWIG_EXECUTABLE - the	path to	the swig executable
	  SWIG_VERSION	 - the version number of the swig executable

       The  minimum  required version of SWIG can be specified using the stan-
       dard syntax, e.g.  find_package(SWIG 1.1)

       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

   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/developpers, 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

       In cygwin, look for the cygwin version first.  Don't look for it	 later
       to avoid	finding	the cygwin version on a	Win32 build.

   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/developpers, 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.

       The following variables are set

	  CMAKE_THREAD_LIBS_INIT     - the thread library
	  CMAKE_USE_SPROC_INIT	     - are we using sproc?
	  CMAKE_USE_WIN32_THREADS_INIT - using WIN32 threads?
	  CMAKE_USE_PTHREADS_INIT    - are we using pthreads
	  CMAKE_HP_PTHREADS_INIT     - are we using hp pthreads

       The following import target is created

	  Threads::Threads

       For systems with	multiple thread	libraries, caller can set

	  CMAKE_THREAD_PREFER_PTHREAD

       If  the	use of the -pthread compiler and linker	flag is	preferred then
       the caller can set

	  THREADS_PREFER_PTHREAD_FLAG

       Please note that	the compiler flag can only be used with	 the  imported
       target.	Use  of	 both  the  imported  target as	well as	this switch is
       highly recommended for new code.

   FindTIFF
       Find the	TIFF library (libtiff).

   Imported targets
       This module defines the following IMPORTED targets:

       TIFF::TIFF
	      The TIFF library,	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
	      the path to the TIFF library

   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
       Try to find Vulkan

   IMPORTED Targets
       This module defines IMPORTED target Vulkan::Vulkan, if Vulkan has  been
       found.

   Result Variables
       This module defines the following variables:

	  Vulkan_FOUND		- True if Vulkan was found
	  Vulkan_INCLUDE_DIRS	- include directories for Vulkan
	  Vulkan_LIBRARIES	- link against this library to use Vulkan

       The module will also define two cache variables:

	  Vulkan_INCLUDE_DIR	- the Vulkan include directory
	  Vulkan_LIBRARY	- the path to the Vulkan library

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

       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.

       Sample usage:

	  # Note that for MinGW	users the order	of libs	is important!
	  find_package(wxWidgets COMPONENTS net	gl core	base)
	  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 net gl core base)
	  include(${wxWidgets_USE_FILE})
	  # and	for each of your dependent executable/library targets:
	  target_link_libraries(<YourTarget> ${wxWidgets_LIBRARIES})

   FindwxWindows
       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.  Please note this file is DEPRECATED and re-
       placed by FindwxWidgets.cmake.  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)

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

   FindXalanC
       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

   FindXercesC
       Find the	Apache Xerces-C++ validating XML parser	headers	and libraries.

   Imported targets
       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

   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:

	  X11_ICE_INCLUDE_PATH,		 X11_ICE_LIB,	     X11_ICE_FOUND
	  X11_SM_INCLUDE_PATH,		 X11_SM_LIB,	     X11_SM_FOUND
	  X11_X11_INCLUDE_PATH,		 X11_X11_LIB
	  X11_Xaccessrules_INCLUDE_PATH,		     X11_Xaccess_FOUND
	  X11_Xaccessstr_INCLUDE_PATH,			     X11_Xaccess_FOUND
	  X11_Xau_INCLUDE_PATH,		 X11_Xau_LIB,	     X11_Xau_FOUND
	  X11_Xcomposite_INCLUDE_PATH,	 X11_Xcomposite_LIB, X11_Xcomposite_FOUND
	  X11_Xcursor_INCLUDE_PATH,	 X11_Xcursor_LIB,    X11_Xcursor_FOUND
	  X11_Xdamage_INCLUDE_PATH,	 X11_Xdamage_LIB,    X11_Xdamage_FOUND
	  X11_Xdmcp_INCLUDE_PATH,	 X11_Xdmcp_LIB,	     X11_Xdmcp_FOUND
	  X11_Xext_LIB,	      X11_Xext_FOUND
	  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_xf86misc_INCLUDE_PATH,	 X11_Xxf86misc_LIB,  X11_xf86misc_FOUND
	  X11_xf86vmode_INCLUDE_PATH,	 X11_Xxf86vm_LIB     X11_xf86vmode_FOUND
	  X11_Xfixes_INCLUDE_PATH,	 X11_Xfixes_LIB,     X11_Xfixes_FOUND
	  X11_Xft_INCLUDE_PATH,		 X11_Xft_LIB,	     X11_Xft_FOUND
	  X11_Xi_INCLUDE_PATH,		 X11_Xi_LIB,	     X11_Xi_FOUND
	  X11_Xinerama_INCLUDE_PATH,	 X11_Xinerama_LIB,   X11_Xinerama_FOUND
	  X11_Xinput_INCLUDE_PATH,	 X11_Xinput_LIB,     X11_Xinput_FOUND
	  X11_Xkb_INCLUDE_PATH,				     X11_Xkb_FOUND
	  X11_Xkblib_INCLUDE_PATH,			     X11_Xkb_FOUND
	  X11_Xkbfile_INCLUDE_PATH,	 X11_Xkbfile_LIB,    X11_Xkbfile_FOUND
	  X11_Xmu_INCLUDE_PATH,		 X11_Xmu_LIB,	     X11_Xmu_FOUND
	  X11_Xpm_INCLUDE_PATH,		 X11_Xpm_LIB,	     X11_Xpm_FOUND
	  X11_XTest_INCLUDE_PATH,	 X11_XTest_LIB,	     X11_XTest_FOUND
	  X11_Xrandr_INCLUDE_PATH,	 X11_Xrandr_LIB,     X11_Xrandr_FOUND
	  X11_Xrender_INCLUDE_PATH,	 X11_Xrender_LIB,    X11_Xrender_FOUND
	  X11_Xscreensaver_INCLUDE_PATH, X11_Xscreensaver_LIB, X11_Xscreensaver_FOUND
	  X11_Xt_INCLUDE_PATH,		 X11_Xt_LIB,	     X11_Xt_FOUND
	  X11_Xutil_INCLUDE_PATH,			     X11_Xutil_FOUND
	  X11_Xv_INCLUDE_PATH,		 X11_Xv_LIB,	     X11_Xv_FOUND
	  X11_XSync_INCLUDE_PATH,	 (in X11_Xext_LIB),  X11_XSync_FOUND

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

   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.

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

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

	  ADD_COMPILER_EXPORT_FLAGS( [<output_variable>] )

       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.

       This  function  is  deprecated.	Set the	target properties CXX_VISIBIL-
       ITY_PRESET and VISIBILITY_INLINES_HIDDEN	instead.

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

       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

       Requires	 CMake	2.6 or greater because it uses function, break,	return
       and PARENT_SCOPE.

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

	  LIST_PREREQUISITES(<target> [<recurse> [<exclude_system> [<verbose>]]])

       Print a message listing the prerequisites of <target>.

       <target>	is the name of a shared	library	or executable  target  or  the
       full  path to a shared library or executable file.  If <recurse>	is set
       to 1 all	prerequisites will be found recursively, if set	to 0 only  di-
       rect  prerequisites  are	listed.	 <exclude_system> must be 0 or 1 indi-
       cating whether to include  or  exclude  "system"	 prerequisites.	  With
       <verbose>  set  to  0 only the full path	names of the prerequisites are
       printed,	set to 1 extra informatin will be displayed.

	  LIST_PREREQUISITES_BY_GLOB(<glob_arg>	<glob_exp>)

       Print the prerequisites of shared library and executable	files matching
       a  globbing pattern.  <glob_arg>	is GLOB	or GLOB_RECURSE	and <glob_exp>
       is a globbing expression	used with "file(GLOB"  or  "file(GLOB_RECURSE"
       to  retrieve  a	list  of  matching  files.  If a matching file is exe-
       cutable,	its prerequisites are listed.

       Any additional (optional) arguments provided are	passed	along  as  the
       optional	arguments to the list_prerequisites calls.

	  GP_APPEND_UNIQUE(<list_var> <value>)

       Append <value> to the list variable <list_var> only if the value	is not
       already in the list.

	  IS_FILE_EXECUTABLE(<file> <result_var>)

       Return 1	in <result_var>	if <file> is a binary executable, 0 otherwise.

	  GP_ITEM_DEFAULT_EMBEDDED_PATH(<item> <default_embedded_path_var>)

       Return the path that others should refer	to the item by when  the  item
       is embedded inside a bundle.

       Override	 on  a	per-project  basis  by	providing  a  project-specific
       gp_item_default_embedded_path_override function.

	  GP_RESOLVE_ITEM(<context> <item> <exepath> <dirs> <resolved_item_var>
			  [<rpaths>])

       Resolve an item into an existing	full path file.

       Override	on a per-project basis by providing a project-specific	gp_re-
       solve_item_override function.

	  GP_RESOLVED_FILE_TYPE(<original_file>	<file> <exepath> <dirs>	<type_var>
				[<rpaths>])

       Return  the type	of <file> with respect to <original_file>.  String de-
       scribing	type of	prerequisite is	returned in variable named <type_var>.

       Use <exepath> and <dirs>	if necessary to	 resolve  non-absolute	<file>
       values -- but only for non-embedded items.

       Possible	types are:

	  system
	  local
	  embedded
	  other

       Override	 on a per-project basis	by providing a project-specific	gp_re-
       solved_file_type_override function.

	  GP_FILE_TYPE(<original_file> <file> <type_var>)

       Return the type of <file> with respect to <original_file>.  String  de-
       scribing	type of	prerequisite is	returned in variable named <type_var>.

       Possible	types are:

	  system
	  local
	  embedded
	  other

   GNUInstallDirs
       Define GNU standard installation	directories

       Provides	install	directory variables as defined by the GNU Coding Stan-
       dards.

   Result Variables
       Inclusion of this module	defines	the following variables:

       CMAKE_INSTALL_<dir>
	  Destination for files	of a given type.  This value may be passed  to
	  the  DESTINATION options of install()	commands for the corresponding
	  file type.

       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)

       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
       The following values of CMAKE_INSTALL_PREFIX are	special:

       /
	  For <dir> other than the SYSCONFDIR and LOCALSTATEDIR, the value  of
	  CMAKE_INSTALL_<dir>  is  prefixed with usr/ if it is not user-speci-
	  fied as an absolute path.  For example, the INCLUDEDIR value include
	  becomes  usr/include.	 This is required by the GNU Coding 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  or	 LOCALSTATEDIR,	 the CMAKE_IN-
	  STALL_FULL_<dir> is computed by prepending just / to	the  value  of
	  CMAKE_INSTALL_<dir> if it is not user-specified as an	absolute path.
	  For example, the SYSCONFDIR value etc	becomes	 /etc.	 This  is  re-
	  quired by the	GNU Coding Standards.

       /opt/...
	  For  <dir>  equal  to	 SYSCONFDIR  or	 LOCALSTATEDIR,	 the CMAKE_IN-
	  STALL_FULL_<dir> is computed by appending the	prefix to the value of
	  CMAKE_INSTALL_<dir> if it is not user-specified as an	absolute 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)

	      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.

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

       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
	      Specify  the install(PROGRAMS) command COMPONENT option.	If not
	      specified, no such option	will be	used.

   MacroAddFileDependencies
       MACRO_ADD_FILE_DEPENDENCIES(<_file> depend_files...)

       Using the macro MACRO_ADD_FILE_DEPENDENCIES()  is  discouraged.	 There
       are usually better ways to specify the correct dependencies.

       MACRO_ADD_FILE_DEPENDENCIES(<_file>  depend_files...)  is just a	conve-
       nience wrapper around the OBJECT_DEPENDS	source file property.  You can
       just  use set_property(SOURCE <file> APPEND PROPERTY OBJECT_DEPENDS de-
       pend_files) instead.

   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, IRIX, Linux,	Mac OS X, QNX, Sun and Windows.

       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  basename_LIBRARY,  basename_LIBRARIES,  basename_LI-
       BRARY_DEBUG,  and  basename_LIBRARY_RELEASE  depending on what has been
       found and set.  If  only	 basename_LIBRARY_RELEASE  is  defined,	 base-
       name_LIBRARY will be set	to the release value, and basename_LIBRARY_DE-
       BUG will	be set	to  basename_LIBRARY_DEBUG-NOTFOUND.   If  only	 base-
       name_LIBRARY_DEBUG  is defined, then basename_LIBRARY will take the de-
       bug value, and basename_LIBRARY_RELEASE will  be	 set  to  basename_LI-
       BRARY_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
       Define macro to determine endian	type

       Check if	the system is big endian or little endian

	  TEST_BIG_ENDIAN(VARIABLE)
	  VARIABLE - variable to store the result to

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

   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

   UseJavaClassFilelist
       This script create a list of compiled Java class	files to be added to a
       jar  file.   This avoids	including cmake	files which get	created	in the
       binary directory.

   UseJava
       Use Module for Java

       This file provides functions  for  Java.	  It  is  assumed  that	 Find-
       Java.cmake has already been loaded.  See	FindJava.cmake for information
       on how to load Java into	your CMake project.

	  add_jar(target_name
		  [SOURCES] source1 [source2 ...] [resource1 ...]
		  [INCLUDE_JARS	jar1 [jar2 ...]]
		  [ENTRY_POINT entry]
		  [VERSION version]
		  [OUTPUT_NAME name]
		  [OUTPUT_DIR dir]
		  )

       This command creates a <target_name>.jar.  It compiles the given	source
       files  (source) and adds	the given resource files (resource) 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 cre-
       ated.  The list of include jars are added to the	classpath when compil-
       ing  the	 java sources and also to the dependencies of the target.  IN-
       CLUDE_JARS also accepts other target names  created  by	add_jar.   For
       backwards  compatibility,  jar  files listed as sources are ignored (as
       they have been since the	first version of this module).

       The default OUTPUT_DIR can also be  changed  by	setting	 the  variable
       CMAKE_JAVA_TARGET_OUTPUT_DIR.

       Additional instructions:

	  To add compile flags to the target you can set these flags with
	  the following	variable:

	  set(CMAKE_JAVA_COMPILE_FLAGS -nowarn)

	  To add a path	or a jar file to the class path	you can	do this
	  with the CMAKE_JAVA_INCLUDE_PATH variable.

	  set(CMAKE_JAVA_INCLUDE_PATH /usr/share/java/shibboleet.jar)

	  To use a different output name for the target	you can	set it with:

	  add_jar(foobar foobar.java OUTPUT_NAME shibboleet.jar)

	  To use a different output directory than CMAKE_CURRENT_BINARY_DIR
	  you can set it with:

	  add_jar(foobar foobar.java OUTPUT_DIR	${PROJECT_BINARY_DIR}/bin)

	  To define an entry point in your jar you can set it with the ENTRY_POINT
	  named	argument:

	  add_jar(example ENTRY_POINT com/examples/MyProject/Main)

	  To define a custom manifest for the jar, you can set it with the manifest
	  named	argument:

	  add_jar(example MANIFEST /path/to/manifest)

	  To add a VERSION to the target output	name you can set it using
	  the VERSION named argument to	add_jar. This will create a jar	file with the
	  name shibboleet-1.0.0.jar and	will create a symlink shibboleet.jar
	  pointing to the jar with the version information.

	  add_jar(shibboleet shibbotleet.java VERSION 1.2.0)

	  If the target	is a JNI library, utilize the following	commands to
	  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})

	  If a single target needs to produce more than	one jar	from its
	  java source code, to prevent the accumulation	of duplicate class
	  files	in subsequent jars, set/reset CMAKE_JAR_CLASSES_PREFIX prior
	  to calling the add_jar() function:

	  set(CMAKE_JAR_CLASSES_PREFIX com/redhat/foo)
	  add_jar(foo foo.java)

	  set(CMAKE_JAR_CLASSES_PREFIX com/redhat/bar)
	  add_jar(bar bar.java)

       Target Properties:

	  The add_jar()	function sets some target properties. You can get these
	  properties with the
	     get_property(TARGET <target_name> PROPERTY	<propery_name>)
	  command.

	  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.

	  find_jar(<VAR>
		   name	| NAMES	name1 [name2 ...]
		   [PATHS path1	[path2 ... ENV var]]
		   [VERSIONS version1 [version2]]
		   [DOC	"cache documentation string"]
		   )

       This command is used to find a full path	to the named jar.  A cache en-
       try named by <VAR> is created to	stor the result	of this	 command.   If
       the  full  path	to a jar is found the result is	stored in the variable
       and the search will not repeated	unless the variable  is	 cleared.   If
       nothing	is  found,  the	 result	will be	<VAR>-NOTFOUND,	and the	search
       will be attempted again next time find_jar is  invoked  with  the  same
       variable.   The name of the full	path to	a file that is searched	for is
       specified by the	names listed after NAMES argument.  Additional	search
       locations  can  be  specified after the PATHS argument.	If you require
       special a version of a jar file you can specify it  with	 the  VERSIONS
       argument.   The	argument  after	DOC will be used for the documentation
       string in the cache.

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

       This command installs the TARGET_NAME files to the  given  DESTINATION.
       It should be called in the same scope as	add_jar() or it	will fail.

       Target Properties:

	  The install_jar() function sets the INSTALL_DESTINATION target property
	  on jars so installed.	This property holds the	DESTINATION as described
	  above, and is	used by	install_jar_exports(). You can get this	property
	  with the
	     get_property(TARGET <target_name> PROPERTY	INSTALL_DESTINATION)
	  command.

	  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	DESTI-
       NATION.	It should be called in the same	scope as add_jar() or it  will
       fail.

	  install_jar_exports(TARGETS jar1 [jar2 ...]
			      FILE export_filename
			      DESTINATION destination [COMPONENT component])

       This  command  installs	a  target  export file export_filename for the
       named jar targets to the	given DESTINATION. Its function	is similar  to
       that of install(EXPORTS).

	  export_jars(TARGETS jar1 [jar2 ...]
		      FILE export_filename)

       This  command writes a target export file export_filename for the named
       jar targets. Its	function is similar to that of export().

	  create_javadoc(<VAR>
			 PACKAGES pkg1 [pkg2 ...]
			 [SOURCEPATH <sourcepath>]
			 [CLASSPATH <classpath>]
			 [INSTALLPATH <install path>]
			 [DOCTITLE "the	documentation title"]
			 [WINDOWTITLE "the title of the	document"]
			 [AUTHOR TRUE|FALSE]
			 [USE TRUE|FALSE]
			 [VERSION TRUE|FALSE]
			 )

       Create java documentation based on files	or packages.  For more details
       please read the javadoc manpage.

       There  are two main signatures for create_javadoc.  The first signature
       works with package names	on a path with source files:

	  Example:
	  create_javadoc(my_example_doc
	    PACKAGES com.exmaple.foo com.example.bar
	    SOURCEPATH "${CMAKE_CURRENT_SOURCE_DIR}"
	    CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
	    WINDOWTITLE	"My example"
	    DOCTITLE "<h1>My example</h1>"
	    AUTHOR TRUE
	    USE	TRUE
	    VERSION TRUE
	  )

       The second signature for	create_javadoc works on	a given	list of	files.

	  create_javadoc(<VAR>
			 FILES file1 [file2 ...]
			 [CLASSPATH <classpath>]
			 [INSTALLPATH <install path>]
			 [DOCTITLE "the	documentation title"]
			 [WINDOWTITLE "the title of the	document"]
			 [AUTHOR TRUE|FALSE]
			 [USE TRUE|FALSE]
			 [VERSION TRUE|FALSE]
			)

       Example:

	  create_javadoc(my_example_doc
	    FILES ${example_SRCS}
	    CLASSPATH ${CMAKE_JAVA_INCLUDE_PATH}
	    WINDOWTITLE	"My example"
	    DOCTITLE "<h1>My example</h1>"
	    AUTHOR TRUE
	    USE	TRUE
	    VERSION TRUE
	  )

       Both signatures share most of the options.  These options are the  same
       as  what	 you can find in the javadoc manpage.  Please look at the man-
       page for	CLASSPATH, DOCTITLE, WINDOWTITLE, AUTHOR, USE and VERSION.

       The documentation will be by default installed to

	  ${CMAKE_INSTALL_PREFIX}/share/javadoc/<VAR>

       if you don't set	the INSTALLPATH.

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

       Create C	header files from java classes.	These files provide  the  con-
       nective glue that allow your Java and C code to interact.

       There  are  two	main signatures	for create_javah.  The first signature
       returns generated files through variable	specified  by  GENERATED_FILES
       option:

	  Example:
	  Create_javah(GENERATED_FILES files_headers
	    CLASSES org.cmake.HelloWorld
	    CLASSPATH hello.jar
	  )

       The  second  signature for create_javah creates a target	which encapsu-
       lates header files generation.

	  Example:
	  Create_javah(TARGET target_headers
	    CLASSES org.cmake.HelloWorld
	    CLASSPATH hello.jar
	  )

       Both signatures share same options.

	  CLASSES <class>...
		 Specifies Java	classes	used to	generate headers.

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

	  DEPENDS <depend>...
		 Targets on which the javah target depends

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

	  OUTPUT_DIR <path>
		 Sets the directory where the header files will	be  generated.
		 Same behavior as option '-d' of javah tool. If	not specified,
		 ${CMAKE_CURRENT_BINARY_DIR} is	used as	output directory.

   UseJavaSymlinks
       Helper script for UseJava.cmake

   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

   UseSWIG
       Defines the following macros for	use with SWIG:

	  SWIG_ADD_LIBRARY(<name>
			   [TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>]
			   LANGUAGE <language>
			   SOURCES <file>...
			   )
	    - Define swig module with given name and specified language
	  SWIG_LINK_LIBRARIES(name [ libraries ])
	    - Link libraries to	swig module

       Source  files  properties on module files can be	set before the invoca-
       tion of the SWIG_ADD_LIBRARY macro to specify special behavior of SWIG.

       The source file property	CPLUSPLUS calls	SWIG in	c++ mode, e.g.:

	  set_property(SOURCE mymod.i PROPERTY CPLUSPLUS ON)
	  swig_add_library(mymod LANGUAGE python SOURCES mymod.i)

       The source file property	SWIG_FLAGS adds	custom flags to	the SWIG  exe-
       cutable.

       The  source-file	property SWIG_MODULE_NAME have to be provided to spec-
       ify the actual import name of the module	in the target language	if  it
       cannot  be scanned automatically	from source or different from the mod-
       ule file	basename.:

	  set_property(SOURCE mymod.i PROPERTY SWIG_MODULE_NAME	mymod_realname)

       To get the name of the swig module  target  library,  use:  ${SWIG_MOD-
       ULE_${name}_REAL_NAME}.

       Also some variables can be set to specify special behavior of SWIG.

       CMAKE_SWIG_FLAGS	can be used to add special flags to all	swig calls.

       CMAKE_SWIG_OUTDIR  allows  one  to  specify where to write the language
       specific	files (swig -outdir option).

       SWIG_OUTFILE_DIR	allows one to specify where to write the  output  file
       (swig -o	option).  If not specified, CMAKE_SWIG_OUTDIR is used.

       The name-specific variable SWIG_MODULE_<name>_EXTRA_DEPS	may be used to
       specify extra dependencies for the generated modules.

       If the source file generated by swig need some  special	flag  you  can
       use:

	  set_source_files_properties( ${swig_generated_file_fullname}
				       PROPERTIES COMPILE_FLAGS	"-bla")

   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>

   Use_wxWindows
       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
	  WRITE_BASIC_CONFIG_VERSION_FILE( filename
	    [VERSION major.minor.patch]
	    COMPATIBILITY (AnyNewerVersion|SameMajorVersion)
	    )

       Deprecated, see WRITE_BASIC_PACKAGE_VERSION_FILE(), it is identical.

   WriteCompilerDetectionHeader
       This module provides the	function write_compiler_detection_header().

       The  WRITE_COMPILER_DETECTION_HEADER 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> [...]
		    [VERSION <version>]
		    [PROLOG <prolog>]
		    [EPILOG <epilog>]
		    [ALLOW_UNKNOWN_COMPILERS]
		    [ALLOW_UNKNOWN_COMPILER_VERSIONS]
	  )

       The  write_compiler_detection_header function 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.8.2 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.  The {c,cxx}_std_* meta-features are ignored if  re-
       quested.

       See  the	 cmake-compile-features(7)  manual  for	information on compile
       features.

       ALLOW_UNKNOWN_COMPILERS and ALLOW_UNKNOWN_COMPILER_VERSIONS  cause  the
       module  to  generate  conditions	that treat unknown compilers as	simply
       lacking all features.  Without these options the	default	behavior is to
       generate	a #error for unknown compilers.

   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.

       The following features generate corresponding symbol defines:

	       +------------------+--------------------+-------------+
	       |Feature		  | Define	       | Symbol	     |
	       +------------------+--------------------+-------------+
	       |c_restrict	  | <PREFIX>_RESTRICT  | restrict    |
	       +------------------+--------------------+-------------+
	       |cxx_constexpr	  | <PREFIX>_CONSTEXPR | constexpr   |
	       +------------------+--------------------+-------------+
	       |cxx_deleted_func- | <PRE-	       | = delete    |
	       |tions		  | FIX>_DELETED_FUNC- |	     |
	       |		  | TION	       |	     |
	       +------------------+--------------------+-------------+
	       |cxx_extern_tem-	  | <PREFIX>_EX-       | extern	     |
	       |plates		  | TERN_TEMPLATE      |	     |
	       +------------------+--------------------+-------------+
	       |cxx_final	  | <PREFIX>_FINAL     | final	     |
	       +------------------+--------------------+-------------+
	       |cxx_noexcept	  | <PREFIX>_NOEXCEPT  | noexcept    |
	       +------------------+--------------------+-------------+
	       |cxx_noexcept	  | <PREFIX>_NOEX-     | noexcept(X) |
	       |		  | CEPT_EXPR(X)       |	     |
	       +------------------+--------------------+-------------+
	       |cxx_override	  | <PREFIX>_OVERRIDE  | override    |
	       +------------------+--------------------+-------------+

   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		|
	     +-------------------+---------------------+----------------+
	     |cxx_alignas	 | <PREFIX>_ALIGNAS    | alignas	|
	     +-------------------+---------------------+----------------+
	     |cxx_alignof	 | <PREFIX>_ALIGNOF    | alignof	|
	     +-------------------+---------------------+----------------+
	     |cxx_nullptr	 | <PREFIX>_NULLPTR    | nullptr	|
	     +-------------------+---------------------+----------------+
	     |cxx_static_assert	 | <PREFIX>_STATIC_AS- | static_assert	|
	     |			 | SERT		       |		|
	     +-------------------+---------------------+----------------+
	     |cxx_static_assert	 | <PREFIX>_STATIC_AS- | static_assert	|
	     |			 | SERT_MSG	       |		|
	     +-------------------+---------------------+----------------+
	     |cxx_attribute_dep- | <PREFIX>_DEPRECATED | [[deprecated]]	|
	     |recated		 |		       |		|
	     +-------------------+---------------------+----------------+
	     |cxx_attribute_dep- | <PREFIX>_DEPRE-     | [[deprecated]]	|
	     |recated		 | CATED_MSG	       |		|
	     +-------------------+---------------------+----------------+
	     |cxx_thread_local	 | <PREFIX>_THREAD_LO- | thread_local	|
	     |			 | 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=
	  )

COPYRIGHT
       2000-2017 Kitware, Inc. and Contributors

3.8.2				 Jul 02, 2017		      CMAKE-MODULES(7)

NAME | ALL 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+12.1-RELEASE+and+Ports>

home | help