ed item. For each prerequisite, change the way it is referenced to the value of the _EMBEDDED_ITEM keyed variable for that prerequi‐ site. (Most likely changing to an "@executable_path" style refer‐ ence.) 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 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) 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 install_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 bundle are contained within the bundle or are "system" libraries, presumed to exist everywhere. 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 external file causes this function to fail the verification. 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 fol‐ lows: 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 respect to the build directory corresponding to the source direc‐ tory 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 conditions 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 retains its old value. CMakeDetermineVSServicePack Includes a public function for assisting users in trying to deter‐ mine the Visual Studio service pack in use. Sets the passed in variable to one of the following values or an empty string if unknown. vc80 vc80sp1 vc90 vc90sp1 vc100 vc100sp1 Usage: =========================== if(MSVC) include(CMakeDetermineVSServicePack) DetermineVSServicePack( my_service_pack ) if( my_service_pack ) message(STATUS "Detected: ${my_service_pack}") endif() endif() =========================== CMakeExpandImportedTargets 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 respective configuration of the imported tar‐ gets if it exists. If no CONFIGURATION is given, it uses the first configuration from ${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}. This macro is used by all Check*.cmake files which use TRY_COMPILE() or TRY_RUN() and support CMAKE_REQUIRED_LIBRARIES , so that these checks support imported targets in CMAKE_REQUIRED_LIBRARIES: cmake_expand_imported_targets(expandedLibs LIBRARIES ${CMAKE_REQUIRED_LIBRARIES} CONFIGURATION "${CMAKE_TRY_COMPILE_CONFIGURATION}" ) CMakeFindFrameworks helper module to find OSX frameworks 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/Intel/Clang/MSVC, etc. LANGUAGE = language for which the result will be used, i.e. C/CXX/Fortan/ASM MODE = EXIST : only check for existance 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 This module defines macros intended for use by cross-compiling toolchain files when CMake is not able to automatically detect the compiler identification. 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 bypasses 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 bypasses 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 internal variable CMAKE_Fortran_COMPILER_ID to the given com‐ piler-id. It also bypasses the check for working compiler and basic compiler information 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) CMakePackageConfigHelpers CONFIGURE_PACKAGE_CONFIG_FILE(), WRITE_BASIC_PACKAGE_VER‐ SION_FILE() CONFIGURE_PACKAGE_CONFIG_FILE(<input> <output> INSTALL_DESTINATION <path> [PATH_VARS <var1> <var2> ... <varN>] [NO_SET_AND_CHECK_MACRO] [NO_CHECK_REQUIRED_COMPONENTS_MACRO]) CONFIGURE_PACKAGE_CONFIG_FILE() should be used instead of the plain CONFIGURE_FILE() command when creating the <Name>Con‐ fig.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 install 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 hardcode the absolute directory locations, and the 4th case works only if the logic to determine the installedPrefix is correct, and if CONFIG_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, independent 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_PACKAGE_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 can either be a relative or absolute path, both work. The variables <var1> to <varN> given as PATH_VARS are the vari‐ ables 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 location. They are calculated by CONFIGURE_PACK‐ AGE_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 absolute locations it works only if the absolute location is a subdirectory of CMAKE_INSTALL_PREFIX. 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 set‐ ting 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 compo‐ nents. This macro checks whether all requested, non-optional com‐ ponents have been found, and if this is not the case, sets the Foo_FOUND variable to FALSE, so that the package is considered to be not found. It does that by testing the Foo_<Component>_FOUND variables for all requested required components. When using the NO_CHECK_REQUIRED_COMPONENTS option, this macro is not generated into the FooConfig.cmake file. For an example see below the documentation for WRITE_BASIC_PACK‐ AGE_VERSION_FILE(). 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 <filename>. See the documentation of FIND_PACKAGE() for details on this. filename is the output filename, it should be in the build tree. major.minor.patch is the version number of the project to be installed 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 be‐ haviour 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 requested version matches exactly its own version number (not considering the tweak ver‐ sion). For example, version 1.2.3 of a package is only considered compatible to requested version 1.2.3. This mode is for packages without compatibility guarantees. If your project has more elabo‐ rated 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 resulting version file. Depending on the COMPATIBLITY, either the file BasicConfigVersion-SameMajorVersion.cmake.in or Basic‐ ConfigVersion-AnyNewerVersion.cmake.in is used. Please note that these two files are internal to CMake and you should not call con‐ figure_file() on them yourself, but they can be used as starting point to create more sophisticted custom ConfigVersion.cmake files. Example using both configure_package_config_file() and write_basic_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 ) With a 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 CMAKE_PARSE_ARGUMENTS(<prefix> <options> <one_value_keywords> <multi_value_keywords> args...) CMAKE_PARSE_ARGUMENTS() is intended to be used in macros or func‐ tions for parsing the arguments given to that macro or function. It processes the arguments and defines a set of variables which hold the values of the respective options. The <options> argument contains all options for the respective macro, i.e. keywords which can be used when calling the macro without any value following, like e.g. the OPTIONAL keyword of the install() command. The <one_value_keywords> argument contains all keywords for this macro which are followed by one value, like e.g. DESTINATION key‐ word of the install() command. The <multi_value_keywords> argument contains all keywords for this macro which can be followed by more than one value, like e.g. the TARGETS or FILES keywords of the install() command. When done, CMAKE_PARSE_ARGUMENTS() will have defined for each of the keywords listed in <options>, <one_value_keywords> and <multi_value_keywords> a variable composed of the given <prefix> followed by "_" and the name of the respective keyword. These variables will then hold the respective value from the argument list. For the <options> keywords this will be TRUE or FALSE. All remaining arguments are collected in a variable <pre‐ fix>_UNPARSED_ARGUMENTS, this can be checked afterwards to see whether your macro was called with unrecognized parameters. As an example here a my_install() macro, which takes similar argu‐ ments as the real install() command: function(MY_INSTALL) set(options OPTIONAL FAST) set(oneValueArgs DESTINATION RENAME) set(multiValueArgs TARGETS CONFIGURATIONS) cmake_parse_arguments(MY_INSTALL "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN} ) ... Assume my_install() has been called like this: my_install(TARGETS foo bar DESTINATION bin OPTIONAL blub) After the cmake_parse_arguments() call the macro will have set the following variables: MY_INSTALL_OPTIONAL = TRUE MY_INSTALL_FAST = FALSE (this option was not used when calling my_install() MY_INSTALL_DESTINATION = "bin" MY_INSTALL_RENAME = "" (was not used) MY_INSTALL_TARGETS = "foo;bar" MY_INSTALL_CONFIGURATIONS = "" (was not used) MY_INSTALL_UNPARSED_ARGUMENTS = "blub" (no value expected after "OPTIONAL" You can the continue and process these variables. Keywords terminate lists of values, e.g. if directly after a one_value_keyword another recognized keyword follows, this is interpreted as the beginning of the new option. E.g. my_install(TARGETS foo DESTINATION OPTIONAL) would result in MY_INSTALL_DESTINATION set to "OPTIONAL", but MY_INSTALL_DESTINA‐ TION would be empty and MY_INSTALL_OPTIONAL would be set to TRUE therefor. 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 two macros: CMAKE_PUSH_CHECK_STATE() and CMAKE_POP_CHECK_STATE() These two macros can be used to save and restore the state of the variables CMAKE_REQUIRED_FLAGS, CMAKE_REQUIRED_DEFINITIONS, CMAKE_REQUIRED_LIBRARIES and CMAKE_REQUIRED_INCLUDES 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 sup‐ ported. 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. Usage: cmake_push_check_state() set(CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} -DSOME_MORE_DEF) check_function_exists(...) cmake_pop_check_state() CMakeVerifyManifest CMakeVerifyManifest.cmake This script is used to verify that embeded 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 example, cmake -Dallow_versions=8.0.50608.0 -PCmakeVerifyManifest.cmake could be used to allow an embeded man‐ ifest of 8.0.50608.0 to be used in a project even if that version was not found in the .manifest file. CPack Build binary and source package installers. The CPack module generates binary and source installers in a vari‐ ety 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 generated binary installers contain everything installed via CMake's INSTALL command (and the deprecated INSTALL_FILES, INSTALL_PROGRAMS, and INSTALL_TARGETS commands). For certain kinds of binary installers (including the graphical installers on Mac OS X and Windows), CPack generates installers that allow users to select individual application components to install. See CPackComponent module for that. The CPACK_GENERATOR variable has different meanings in different contexts. In your CMakeLists.txt file, CPACK_GENERATOR is a *list of generators*: when run with no other arguments, CPack will iter‐ ate 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: - cpack runs - it includes CPackConfig.cmake - 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...) - foreach generator, it then - sets CPACK_GENERATOR to the one currently being iterated - includes the CPACK_PROJECT_CONFIG_FILE - produces the package for that generator This is the key: For each generator listed in CPACK_GENERATOR in CPackConfig.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, defaults 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 extension. 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 directory e.g., "CMake 2.5" below the installation prefix. All installed 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_PROJECT_CONFIG_FILE - CPack-time project CPack configuration file. This file included at cpack time, once per generator after CPack has set CPACK_GENERATOR to the actual generator being used. It allows per-generator setting of CPACK_* variables at cpack time. CPACK_RESOURCE_FILE_LICENSE - License to be embedded in the installer. It will typically be displayed to the user by the produced installer (often with an explicit "Accept" button, for graphical installers) prior to installation. This license file is NOT added to installed file but is used by some CPack generators like NSIS. If you want to install a license file (may be the same as this one) along with your project you must add an appropriate CMake INSTALL command in your CMakeLists.txt. CPACK_RESOURCE_FILE_README - ReadMe file to be embedded in the installer. It typically describes in some detail the purpose of the project during the installation. 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 component 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_BINARY_NSIS) allowing the user to enable/disable individual generators. 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 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). 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 select 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 Component, Directory. If omitted, CPack will build an installer that installers 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. CPACK_CREATE_DESKTOP_LINKS - List of desktop links to create. CPackBundle CPack Bundle generator (Mac OS X) specific options Installers built on Mac OS X using the Bundle generator use the aforementioned DragNDrop (CPACK_DMG_xxx) variables, plus the fol‐ lowing Bundle-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. CPackComponent Build binary and source package installers The CPackComponent module is the module which handles the compo‐ nent part of CPack. See CPack module for general information about CPack. For certain kinds of binary installers (including the graphical installers on Mac OS X and Windows), CPack generates installers that allow users to select individual application components to install. The contents of each of the components are identified by the COMPONENT argument of CMake's INSTALL command. These compo‐ nents can be annotated with user-friendly names and descriptions, inter-component dependencies, etc., and grouped in various ways to customize the resulting installer. See the cpack_add_* commands, described below, for more information about component-specific installations. Component-specific installation allows users to select specific sets of components to install during the install process. Instal‐ lation components are identified by the COMPONENT argument of CMake's INSTALL commands, 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 contains 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 component-aware CPack generators. Some generators like RPM or ARCHIVE family (TGZ, ZIP, ...) generates several packages files when asked for component packaging. They group the component differently depending on the value of this variable: - ONE_PER_GROUP (default): creates one package file per component group - ALL_COMPONENTS_IN_ONE : creates a single package with all (requested) component - IGNORE : creates one package per component, i.e. IGNORE component 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>_REQUIRED - True is this component is required. cpack_add_component - Describes a CPack installation component named by the COMPONENT argument 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 provided 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 graphical installers to give the user additional information about the component. Descriptions can span multiple lines using "\n" as the line separator. 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 installed 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 installation, 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 inconsitent 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 component 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 command. 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 components, 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 using "\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. Parent 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 "expanded", so that the user immediately sees all of the components within the group. Otherwise, the group will initially show up as a single entry. 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 components that represents a common use case for an application. For example, 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 identifies itself with one or more install types via the INSTALL_TYPES argument to cpack_add_component. DISPLAY_NAME is the displayed name of the install type, which will typically 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 installers that only download the requested components, saving bandwidth. Additionally, 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 remove parts of the application after the original installation. On Windows, 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 components will reside, e.g., http://www.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 directory should be uploaded to a location accessible by the URL given in the site argument. If omitted, CPack will use the directory CPackUploads inside the CMake binary directory to store the generated archives. 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.  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_REMOVE turns off this behavior. This option is ignored on Mac OS X. CPackCygwin Cygwin CPack generator (Cygwin). 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 incomplete. 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 incomplete. CPackDMG DragNDrop CPack generator (Mac OS X). 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). Refer to hdiutil(1) for more information on other available formats. 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 OSA-script) using a normal folder from which the .DS_Store file can then be extracted. CPACK_DMG_BACKGROUND_IMAGE - Path to a background image file. This file will be used as the background for the Finder Window when the disk image is opened. By default no background image is set. The background image is applied after applying the custom .DS_Store file. 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 automatically 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 detected command (or specify its location if the auto-detection fails to find it.) CPackDeb The builtin (binary) CPack Deb generator (Unix only) 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 : http://www.cmake.org/Wiki/CMake:CPackConfiguration. CPack‐ Deb 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.You'll find a detailed usage on the wiki: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 However as a handy reminder here comes the list of specific vari‐ ables: CPACK_DEBIAN_PACKAGE_NAME Mandatory : YES Default : CPACK_PACKAGE_NAME (lower case) The debian package summary CPACK_DEBIAN_PACKAGE_VERSION Mandatory : YES Default : CPACK_PACKAGE_VERSION The debian package version CPACK_DEBIAN_PACKAGE_ARCHITECTURE Mandatory : YES Default : Output of dpkg --print-architecture (or i386 if dpkg is not found) The debian package architecture CPACK_DEBIAN_PACKAGE_DEPENDS Mandatory : NO Default : - May be used to set deb dependencies. CPACK_DEBIAN_PACKAGE_MAINTAINER Mandatory : YES Default : CPACK_PACKAGE_CONTACT The debian package maintainer CPACK_DEBIAN_PACKAGE_DESCRIPTION Mandatory : YES Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY The debian package description CPACK_DEBIAN_PACKAGE_SECTION Mandatory : YES Default : 'devel' The debian package section CPACK_DEBIAN_PACKAGE_PRIORITY Mandatory : YES Default : 'optional' The debian package priority CPACK_DEBIAN_PACKAGE_HOMEPAGE Mandatory : NO Default : - The URL of the web site for this package, preferably (when applicable) the site from which the original source can be obtained and any additional upstream documentation or information may be found. The content of this field is a simple URL without any surrounding characters such as <>. CPACK_DEBIAN_PACKAGE_SHLIBDEPS Mandatory : NO Default : OFF May be set to ON in order to use dpkg-shlibdeps to generate better package dependency list. You may need set CMAKE_INSTALL_RPATH toi appropriate value if you use this feature, because if you don't dpkg-shlibdeps may fail to find your own shared libs. See http://www.cmake.org/Wiki/CMake_RPATH_handling. CPACK_DEBIAN_PACKAGE_DEBUG Mandatory : NO Default : - May be set when invoking cpack in order to trace debug information during CPackDeb run. CPACK_DEBIAN_PACKAGE_PREDEPENDS Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps This field is 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. CPACK_DEBIAN_PACKAGE_ENHANCES Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package. CPACK_DEBIAN_PACKAGE_BREAKS Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks be installed unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured. CPACK_DEBIAN_PACKAGE_CONFLICTS Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be installed on the system at the same time. CPACK_DEBIAN_PACKAGE_PROVIDES Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps A virtual package is one which appears in the Provides control field of another package. CPACK_DEBIAN_PACKAGE_REPLACES Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. CPACK_DEBIAN_PACKAGE_RECOMMENDS Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps Allows packages to declare a strong, but not absolute, dependency on other packages. CPACK_DEBIAN_PACKAGE_SUGGESTS Mandatory : NO Default : - see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps Allows packages to declare a suggested package install grouping. CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA Mandatory : NO Default : - This variable allow advanced user to add custom script to the control.tar.gz Typical usage is for conffiles, postinst, postrm, prerm. Usage: SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm") CPackNSIS CPack NSIS generator specific options 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_INSTALL_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_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 system. 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 command. 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 versions 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 application. CPACK_NSIS_URL_INFO_ABOUT - URL to a web site providing more information about your application. CPACK_NSIS_CONTACT - Contact information for questions and comments about the installation process. 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<EMAIL_ADDRESS>"CMake Help" "http://www.cmake.org" "CMake Web Site") CPackPackageMaker PackageMaker CPack generator (Mac OS X). The following variable is specific to installers build on Mac OS X using 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 support different features. For example, CPack can only build component-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 features. 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. CPackRPM The builtin (binary) CPack RPM generator (Unix only) CPackRPM may be used to create RPM package using CPack. CPackRPM is a CPack generator thus it uses the CPACK_XXX variables used by CPack : http://www.cmake.org/Wiki/CMake:CPackConfiguration However CPackRPM has specific features which are controlled by the specifics CPACK_RPM_XXX variables. CPackRPM is a component aware generator so when CPACK_RPM_COMPONENT_INSTALL is ON some more CPACK_RPM_<ComponentName>_XXXX variables may be used in order to have component specific values. Note however that <componentName> refers to the **grouping name**. This may be either a component name or a component GROUP name. Usually those vars correspond to RPM spec file entities, one may find information about spec files here http://www.rpm.org/wiki/Docs. You'll find a detailed usage of CPackRPM on the wiki: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29 However as a handy reminder here comes the list of specific vari‐ ables: CPACK_RPM_PACKAGE_SUMMARY - The RPM package summary. Mandatory : YES Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY CPACK_RPM_PACKAGE_NAME - The RPM package name. Mandatory : YES Default : CPACK_PACKAGE_NAME CPACK_RPM_PACKAGE_VERSION - The RPM package version. Mandatory : YES Default : CPACK_PACKAGE_VERSION CPACK_RPM_PACKAGE_ARCHITECTURE - The RPM package architecture. Mandatory : NO Default : - This may be set to "noarch" if you know you are building a noarch package. CPACK_RPM_PACKAGE_RELEASE - The RPM package release. Mandatory : YES Default : 1 This is the numbering of the RPM package itself, i.e. the version 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. CPACK_RPM_PACKAGE_LICENSE - The RPM package license policy. Mandatory : YES Default : "unknown" CPACK_RPM_PACKAGE_GROUP - The RPM package group. Mandatory : YES Default : "unknown" CPACK_RPM_PACKAGE_VENDOR - The RPM package vendor. Mandatory : YES Default : CPACK_PACKAGE_VENDOR if set or "unknown" CPACK_RPM_PACKAGE_URL - The projects URL. Mandatory : NO Default : - CPACK_RPM_PACKAGE_DESCRIPTION - RPM package description. Mandatory : YES Default : CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" CPACK_RPM_COMPRESSION_TYPE - RPM compression type. Mandatory : NO 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 value are: lzma, xz, bzip2 and gzip. CPACK_RPM_PACKAGE_REQUIRES - RPM spec requires field. Mandatory : NO 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_SUGGESTS - RPM spec suggest field. Mandatory : NO 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 - RPM spec provides field. Mandatory : NO 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 - RPM spec obsoletes field. Mandatory : NO Default : - May be used to set RPM packages that are obsoleted by this one. CPACK_RPM_PACKAGE_RELOCATABLE - build a relocatable RPM. Mandatory : NO 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 unexpected behavior. CPACK_RPM_SPEC_INSTALL_POST - [deprecated]. Mandatory : NO Default : - 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 binaries. CPACK_RPM_SPEC_MORE_DEFINE - RPM extended spec definitions lines. Mandatory : NO Default : - May be used to add any %define lines to the generated spec file. CPACK_RPM_PACKAGE_DEBUG - Toggle CPackRPM debug output. Mandatory : NO Default : - May be set when invoking cpack in order to trace debug information 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 - A user provided spec file. Mandatory : NO 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. Mandatory : NO 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 Mandatory : NO Default : - May be used to embed a pre (un)installation script in the spec file. The refered script file(s) will be read and directly 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_<COMPONENT>_PRE_INSTALL_SCRIPT_FILE and CPACK_RPM_<COMPONENT>_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 Mandatory : NO Default : - May be used to embed a post (un)installation script in the spec file. The refered script file(s) will be read and directly 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_<COMPONENT>_POST_INSTALL_SCRIPT_FILE and CPACK_RPM_<COMPONENT>_POST_UNINSTALL_SCRIPT_FILE One may verify which scriptlet has been included with rpm -qp --scripts package.rpm CPACK_RPM_USER_FILELIST CPACK_RPM_<COMPONENT>_USER_FILELIST Mandatory : NO 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. Since CPackRPM is generating the list of files (and directories) the user specified files of the CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed from the generated list. CPACK_RPM_CHANGELOG_FILE - RPM changelog file. Mandatory : NO Default : - May be used to embed a changelog in the spec file. The refered file will be read and directly put after the %changelog section. CTest Configure a project for testing with CTest/CDash Include this module in the top CMakeLists.txt file of a project to enable 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 CTestCon‐ fig.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 command-line tool's dashboard script mode (ctest -S). While building a project for submission to CDash, CTest scans the build output for errors and warnings and reports them with sur‐ rounding context from the build log. This generic approach works for all build tools, but does not give details about the command invocation that produced a given problem. One may get more detailed reports by adding set(CTEST_USE_LAUNCHERS 1) to the CTestConfig.cmake file. When this option is enabled, the CTest module tells CMake's Makefile generators to invoke every command in the generated build system through a CTest launcher program. (Currently the CTEST_USE_LAUNCHERS option is ignored on non-Makefile generators.) During a manual build each launcher transparently runs the command it wraps. During a CTest-driven build for submission to CDash each launcher reports detailed information when its command fails or warns. (Setting CTEST_USE_LAUNCHERS in CTestConfig.cmake is convenient, but also adds the launcher overhead even for manual builds. One may instead set it in a CTest dashboard script and add it to the CMake cache for the build tree.) CTestScriptMode This file is read by ctest in script mode (-S) 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 This internally calls the check_c_source_compiles macro. See help for CheckCSourceCompiles for a listing of variables that can mod‐ ify the build. 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 <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 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) 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 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. See help for CheckCXXSourceCompiles for a listing of variables that can modify the build. 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 <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 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) 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 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_SYMBOL_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 recognized (consider using CheckTypeSize or CheckC‐ SourceCompiles). 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 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 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 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>. This does not verify that any system header file declares the function, only that it can be found at link time (considure using CheckSymbolExists). 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 CheckIncludeFile macro which checks the include file exists. CHECK_INCLUDE_FILE(INCLUDE VARIABLE) INCLUDE - name of include file VARIABLE - variable to return result an optional third argument is the CFlags to add to the compile line or you can use CMAKE_REQUIRED_FLAGS 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 CheckIncludeFileCXX Check if the include file exists. CHECK_INCLUDE_FILE_CXX(INCLUDE VARIABLE) INCLUDE - name of include file VARIABLE - variable to return result An optional third argument is the CFlags to add to the compile line or you can use CMAKE_REQUIRED_FLAGS. 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 CheckIncludeFiles Check if the files can be included CHECK_INCLUDE_FILES(INCLUDE VARIABLE) INCLUDE - list of files to include VARIABLE - variable to return result 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 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 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 CheckPrototypeDefinition Check if the protoype we expect is correct. check_prototype_definition(FUNCTION PROTOTYPE RETURN HEADER VARI‐ ABLE) 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. 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 CheckStructHasMember Check if the given struct or class has the specified member vari‐ able CHECK_STRUCT_HAS_MEMBER (STRUCT MEMBER HEADER VARIABLE) 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 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 Example: CHECK_STRUCT_HAS_MEMBER("struct timeval" tv_sec sys/select.h HAVE_TIMEVAL_TV_SEC) 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. 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 recognized (consider using CheckTypeSize or CheckC‐ SourceCompiles). If the check needs to be done in C++, consider using CHECK_CXX_SYMBOL_EXISTS(), which does the same as CHECK_SYM‐ BOL_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 CheckTypeSize Check sizeof a type CHECK_TYPE_SIZE(TYPE VARIABLE [BUILTIN_TYPES_ONLY]) Check if the type exists and determine its size. On return, "HAVE_${VARIABLE}" holds the existence of the type, and "${VARI‐ ABLE}" holds one of the following: <size> = type has non-zero size <size> "0" = type has arch-dependent size (see below) "" = type does not exist Furthermore, the variable "${VARIABLE}_CODE" holds C preprocessor code to define the macro "${VARIABLE}" to the size of the type, or leave the macro undefined if the type does not exist. The variable "${VARIABLE}" may be "0" when CMAKE_OSX_ARCHITECTURES has multiple architectures for building OS X universal binaries. This indicates that the type size varies across architectures. In this case "${VARIABLE}_CODE" contains C preprocessor tests mapping from each architecture macro to the corresponding type size. The list of architecture 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. 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_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 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 Dart Configure a project for testing with CTest or old Dart Tcl Client This file is the backwards-compatibility version of the CTest mod‐ ule. It supports using the old Dart 1 Tcl client for driving dash‐ board submissions 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(BUILD_TESTING) The BUILD_TESTING option is created by the Dart module to deter‐ mine 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 executables. 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 relative to the <executable_path> (if supplied) or the CMAKE_INSTALL_PREFIX. 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 stand‐ alone 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 plugins 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 directories 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 COMPO‐ NENT. INSTALL_QT4_PLUGIN(plugin executable copy installed_plugin_path_var <plugins_dir> <component>) Install (or copy) an unresolved <plugin> to the default plugins directory (or <plugins_dir>) relative to <executable> and store the result in <installed_plugin_path_var>. See documentation of INSTALL_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 relies on several tools (Doxygen, Perl, etc). ExternalProject Create custom targets to build projects in external trees 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> # Name for custom target [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 #--Download step-------------- [DOWNLOAD_DIR dir] # Directory to store downloaded files [DOWNLOAD_COMMAND cmd...] # Command to download source tree [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 rev] # Revision to checkout from Subversion repo [SVN_USERNAME john ] # Username for Subversion checkout and update [SVN_PASSWORD doe ] # 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 [URL /.../src.tgz] # Full path or URL of source [URL_MD5 md5] # MD5 checksum of file at URL [TIMEOUT seconds] # Time allowed for file download operations #--Update/Patch step---------- [UPDATE_COMMAND cmd...] # Source work-tree update command [PATCH_COMMAND cmd...] # Command to patch downloaded source #--Configure step------------- [SOURCE_DIR dir] # Source dir to be used for build [CONFIGURE_COMMAND cmd...] # Build tree configuration command [CMAKE_COMMAND /.../cmake] # Specify alternative cmake executable [CMAKE_GENERATOR gen] # Specify generator for native build [CMAKE_ARGS args...] # Arguments to CMake command line [CMAKE_CACHE_ARGS args...] # Initial cache arguments, of the form -Dvar:string=on #--Build step----------------- [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 #--Install step--------------- [INSTALL_DIR dir] # Installation prefix [INSTALL_COMMAND cmd...] # Command to drive install after build #--Test step------------------ [TEST_BEFORE_INSTALL 1] # Add test step executed before install step [TEST_AFTER_INSTALL 1] # Add test step executed after install step [TEST_COMMAND cmd...] # Command to drive test #--Output logging------------- [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 #--Custom targets------------- [STEP_TARGETS st1 st2 ...] # Generate custom targets for these steps ) The *_DIR options specify directories for the project, with default directories computed as follows. If the PREFIX option is given to ExternalProject_Add() or the EP_PREFIX directory property is set, then an external project is built and installed under the specified prefix: TMP_DIR = <prefix>/tmp STAMP_DIR = <prefix>/src/<name>-stamp DOWNLOAD_DIR = <prefix>/src SOURCE_DIR = <prefix>/src/<name> BINARY_DIR = <prefix>/src/<name>-build INSTALL_DIR = <prefix> 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 default is to set PREFIX to "<name>-prefix". Relative paths are inter‐ preted with respect to the build directory corresponding to the source directory in which ExternalProject_Add is invoked. 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). The 'ExternalProject_Add_Step' function adds a custom step to an external project: ExternalProject_Add_Step(<name> <step> # Names of project and custom step [COMMAND cmd...] # Command line invoked by this step [COMMENT "text..."] # Text printed when step executes [DEPENDEES steps...] # Steps on which this step depends [DEPENDERS steps...] # Steps that depend on this step [DEPENDS files...] # Files on which this step depends [ALWAYS 1] # No stamp file, step always runs [WORKING_DIRECTORY dir] # Working directory for command [LOG 1] # Wrap step in script to log output ) The command line, comment, and working directory of every standard and custom step is processed to replace tokens <SOURCE_DIR>, <BINARY_DIR>, <INSTALL_DIR>, and <TMP_DIR> with corresponding property values. 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. Property names correspond to the keyword argument names of 'ExternalPro‐ ject_Add'. The 'ExternalProject_Add_StepTargets' function generates custom targets for the steps listed: ExternalProject_Add_StepTargets(<name> [step1 [step2 [...]]]) If STEP_TARGETS is set then ExternalProject_Add_StepTargets is automatically called at the end of matching calls to ExternalPro‐ ject_Add_Step. Pass STEP_TARGETS explicitly to individual Exter‐ nalProject_Add calls, or implicitly to all ExternalProject_Add calls by setting the directory property EP_STEP_TARGETS. If STEP_TARGETS is not set, clients may still manually call Exter‐ nalProject_Add_StepTargets after calling ExternalProject_Add or ExternalProject_Add_Step. This functionality is provided to make it easy to drive the steps independently of each other by specifying targets on build command lines. For example, you may be submitting to a sub-project based dashboard, where you want to drive the configure portion of the build, then submit to the dashboard, followed by the build por‐ tion, followed by tests. If you invoke a custom target that depends on a step halfway through the step dependency chain, then all the previous steps will also run to ensure everything is up to date. For example, to drive configure, build and test steps indepen‐ dently for each ExternalProject_Add call in your project, write the following line prior to any ExternalProject_Add calls in your CMakeLists file: set_property(DIRECTORY PROPERTY EP_STEP_TARGETS configure build test) FeatureSummary Macros for generating a summary of enabled/disabled features This module provides the macros feature_summary(), set_pack‐ age_properties() and add_feature_info(). For compatibility it also still provides set_package_info(), set_feature_info(), print_enabled_features() and print_disabled_features(). These macros can be used to generate a summary of enabled and dis‐ abled packages and/or feature for a build tree: -- The following OPTIONAL packages have been found: LibXml2 (required version >= 2.4) , XML processing library. , <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. FEATURE_SUMMARY( [FILENAME <file>] [APPEND] [VAR <variable_name>] [INCLUDE_QUIET_PACKAGES] [FATAL_ON_MISSING_REQUIRED_PACKAGES] [DESCRIPTION "Found packages:"] WHAT (ALL | PACKAGES_FOUND | 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_PROPER‐ TIES() 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 OPTIONAL_PACKAGES_FOUND: only those packages which have been found which have the type OPTIONAL OPTIONAL_PACKAGES_NOT_FOUND: only those packages which have not been found which have the type OPTIONAL RECOMMENDED_PACKAGES_FOUND: only those packages which have been found which have the type RECOMMENDED RECOMMENDED_PACKAGES_NOT_FOUND: only those packages which have not been found which have the type RECOMMENDED REQUIRED_PACKAGES_FOUND: only those packages which have been found which have the type REQUIRED REQUIRED_PACKAGES_NOT_FOUND: only those packages which have not been found which have the type REQUIRED RUNTIME_PACKAGES_FOUND: only those packages which have been found which have the type RUNTIME RUNTIME_PACKAGES_NOT_FOUND: only those packages which have not been found which have the type RUNTIME 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 option is used, the information is "printed" into the specified variable. If FILE‐ NAME 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 content. 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_PACKAGES is given, CMake will abort if a package which is marked as REQUIRED has not been found. Example 1, append everything to a file: 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: feature_summary(WHAT ENABLED_FEATURES INCLUDE_QUIET_PACKAGES DESCRIPTION "Enabled Features:" VAR enabledFeaturesText) message(STATUS "${enabledFeaturesText}") 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: this should be the homepage of the package, or something sim‐ ilar. Ideally this is set already directly in the Find-module. DESCRIPTION: A short description what that package is, at most one sentence. Ideally this is set already directly in the Find-module. TYPE: What type of dependency has the using project on that pack‐ age. 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 resulting 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 FATAL_ON_MISS‐ ING_REQUIRED_PACKAGES argument for feature_summary(). Last, a RUN‐ TIME package is a package which is actually not used at all during the build, but which is required for actually running the result‐ ing binaries. So if such a package is missing, the project can still be built, but it may not work later on. If set_package_prop‐ erties() is called multiple times for the same package with dif‐ ferent 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-module, but must be set in the project. 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_properties() is called multiple times for a package, all PURPOSE 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/") set_package_properties(LibXml2 PROPERTIES TYPE RECOMMENDED PURPOSE "Enables HTML-import in MyWordProcessor") ... 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(<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, <description> is a text describing the feature. The information can be displayed using feature_summary() for ENABLED_FEATURES and DISABLED_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.") The following macros are provided for compatibility with previous CMake versions: 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. PRINT_ENABLED_FEATURES() Does the same as FEATURE_SUMMARY(WHAT ENABLED_FEATURES DESCRIP‐ TION "Enabled features:") PRINT_DISABLED_FEATURES() Does the same as FEATURE_SUMMARY(WHAT DISABLED_FEATURES DESCRIP‐ TION "Disabled features:") SET_FEATURE_INFO(<name> <description> [<url>] ) Does the same as SET_PACKAGE_INFO(<name> <description> <url> ) 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) 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 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") FindBISON Find bison executable and provides macros 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 standard CMake syntax, e.g. find_package(BISON 2.1.3) If bison is found, the module defines the macros: BISON_TARGET(<Name> <YaccInput> <CodeOutput> [VERBOSE <file>] [COMPILE_FLAGS <string>]) which will create a custom rule to generate a parser. <YaccIn‐ put> is the path to a yacc file. <CodeOutput> is the name of the source file generated by bison. A header file is also be gener‐ ated, and contains the token list. If COMPILE_FLAGS option is specified, the next parameter is added in the bison command line. if VERBOSE option is specified, <file> is created and contains verbose descriptions of the grammar and parser. The macro defines a set of 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 - The sources files generated by bison BISON_${Name}_COMPILE_FLAGS - Options used in the bison command line ==================================================================== Example: find_package(BISON) BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp) 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.source‐ forge.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 C/CXX should be enabled to use Intel mkl FindBZip2 Try to find BZip2 Once done this will define 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) FindBoost Try to find Boost include dirs and libraries Usage of this module as follows: NOTE: Take note of the Boost_ADDITIONAL_VERSIONS variable below. Due to Boost naming conventions and limitations in CMake this find module is NOT future safe with respect to Boost version numbers, and may break. == Using Header-Only libraries from within Boost: == find_package( Boost 1.36.0 ) if(Boost_FOUND) include_directories(${Boost_INCLUDE_DIRS}) add_executable(foo foo.cc) endif() == Using actual libraries from within Boost: == set(Boost_USE_STATIC_LIBS ON) 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() The components list needs to contain actual names of boost libraries only, such as "date_time" for "libboost_date_time". If you're using parts of Boost that contain header files only (e.g. foreach) you do not need to specify COMPONENTS. You should provide a minimum version number that should be used. If you provide this version number and specify the REQUIRED attribute, this module will fail if it can't find the specified or a later version. If you specify a version number this is automati‐ cally put into the considered list of version numbers and thus doesn't need to be specified in the Boost_ADDITIONAL_VERSIONS variable (see below). NOTE for Visual Studio Users: Automatic linking is used on MSVC & Borland compilers by default when #including things in Boost. It's important to note that setting Boost_USE_STATIC_LIBS to OFF is NOT enough to get you dynamic linking, should you need this feature. Automatic linking typically uses static libraries with a few exceptions (Boost.Python is one). Please see the section below near Boost_LIB_DIAGNOSTIC_DEFINITIONS for more details. Adding a TARGET_LINK_LIBRARIES() as shown in the example above appears to cause VS to link dynamically if Boost_USE_STATIC_LIBS gets set to OFF. It is suggested you avoid automatic linking since it will make your application less portable. =========== The mess that is Boost_ADDITIONAL_VERSIONS (sorry?) ============ OK, so the Boost_ADDITIONAL_VERSIONS variable can be used to spec‐ ify a list of boost version numbers that should be taken into account when searching for Boost. Unfortunately boost puts the version number into the actual filename for the libraries, so this variable will certainly be needed in the future when new Boost versions are released. Currently this module searches for the following version numbers: 1.33, 1.33.0, 1.33.1, 1.34, 1.34.0, 1.34.1, 1.35, 1.35.0, 1.35.1, 1.36, 1.36.0, 1.36.1, 1.37, 1.37.0, 1.38, 1.38.0, 1.39, 1.39.0, 1.40, 1.40.0, 1.41, 1.41.0, 1.42, 1.42.0, 1.43, 1.43.0, 1.44, 1.44.0, 1.45, 1.45.0, 1.46, 1.46.0, 1.46.1, 1.47, 1.47.0, 1.48, 1.48.0, 1.49, 1.49.0, 1.50, 1.50.0, 1.51, 1.51.0, 1.52, 1.52.0, 1.53, 1.53.0, 1.54, 1.54.0, 1.55, 1.55.0, 1.56, 1.56.0 NOTE: If you add a new major 1.x version in Boost_ADDITIONAL_VER‐ SIONS you should add both 1.x and 1.x.0 as shown above. Official Boost include directories omit the 3rd version number from include paths if it is 0 although not all binary Boost releases do so. set(Boost_ADDITIONAL_VERSIONS "1.78" "1.78.0" "1.79" "1.79.0") ===================================== ============= ======================== Variables used by this module, they can change the default behav‐ iour and need to be set before calling find_package: Boost_USE_MULTITHREADED Can be set to OFF to use the non-multithreaded boost libraries. If not specified, defaults to ON. Boost_USE_STATIC_LIBS Can be set to ON to force the use of the static boost libraries. Defaults to OFF. Boost_NO_SYSTEM_PATHS Set to TRUE to suppress searching in system paths (or other locations outside of BOOST_ROOT or BOOST_INCLUDEDIR). Useful when specifying BOOST_ROOT. Defaults to OFF. [Since CMake 2.8.3] Boost_NO_BOOST_CMAKE Do not do a find_package call in config mode before searching for a regular boost install. This will avoid finding boost-cmake installs. Defaults to OFF. [Since CMake 2.8.6] Boost_USE_STATIC_RUNTIME If enabled, searches for boost libraries linked against a static C++ standard library ('s' ABI tag). This option should be set to ON or OFF because the default behavior if not specified is platform dependent for backwards compatibility. [Since CMake 2.8.3] Boost_USE_DEBUG_PYTHON If enabled, searches for boost libraries compiled against a special debug build of Python ('y' ABI tag). Defaults to OFF. [Since CMake 2.8.3] Boost_USE_STLPORT If enabled, searches for boost libraries compiled against the STLPort standard library ('p' ABI tag). Defaults to OFF. [Since CMake 2.8.3] Boost_USE_STLPORT_DEPRECATED_NATIVE_IOSTREAMS If enabled, searches for boost libraries compiled against the deprecated STLPort "native iostreams" feature ('n' ABI tag). Defaults to OFF. [Since CMake 2.8.3] Other Variables used by this module which you may want to set. Boost_ADDITIONAL_VERSIONS A list of version numbers to use for searching the boost include directory. Please see the documentation above regarding this annoying, but necessary variable :( Boost_DEBUG Set this to TRUE to enable debugging output of FindBoost.cmake if you are having problems. Please enable this before filing any bug reports. Boost_DETAILED_FAILURE_MSG FindBoost doesn't output detailed information about why it failed or how to fix the problem unless this is set to TRUE or the REQUIRED keyword is specified in find_package(). [Since CMake 2.8.0] Boost_COMPILER Set this to the compiler suffix used by Boost (e.g. "-gcc43") if FindBoost has problems finding the proper Boost installation Boost_THREADAPI When building boost.thread, sometimes the name of the library contains an additional "pthread" or "win32" string known as the threadapi. This can happen when compiling against pthreads on Windows or win32 threads on Cygwin. You may specify this variable and if set when FindBoost searches for the Boost threading library it will first try to match the threadapi you specify. For Example: libboost_thread_win32-mgw45-mt-1_43.a might be found if you specified "win32" here before falling back on libboost_thread-mgw45-mt-1_43.a. [Since CMake 2.8.3] Boost_REALPATH Resolves symbolic links for discovered boost libraries to assist with packaging. For example, instead of Boost_SYSTEM_LIBRARY_RELEASE being resolved to "/usr/lib/libboost_system.so" it would be "/usr/lib/libboost_system.so.1.42.0" instead. This does not affect linking and should not be enabled unless the user needs this information. [Since CMake 2.8.3] 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 FindCABLE Find CABLE This module finds if CABLE is installed and determines where the include 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. 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 releases. This script makes use of the standard find_package arguments of <VERSION>, 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 installed version of the toolkit set the environment variable CUDA_BIN_PATH before running cmake (e.g. CUDA_BIN_PATH=/usr/local/cuda1.0 instead of the default /usr/local/cuda) or set CUDA_TOOLKIT_ROOT_DIR after configuring. If you change the value of CUDA_TOOLKIT_ROOT_DIR, various compo‐ nents that depend on the path will be relocated. 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 location. 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_EXECUTABLE, CUDA_ADD_LIBRARY, CUDA_COMPILE, CUDA_COM‐ PILE_PTX 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_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_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_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_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 preceed 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_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 (alterative to: CUDA_ADD_CUBLAS_TO_TARGET macro). CUDA_curand_LIBRARY -- CUDA Random Number Generation library. Only available for CUDA version 3.2+. CUDA_cusparse_LIBRARY -- CUDA Sparse Matrix library. Only available for CUDA version 3.2+. CUDA_npp_LIBRARY -- NVIDIA Performance Primitives library. Only available for CUDA version 4.0+. 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. James Bigler, NVIDIA Corp (nvidia.com - jbigler) Abe Stephens, SCI Institute -- http://www.sci.utah.edu/~abe/FindCuda.html Copyright (c) 2008 - 2009 NVIDIA Corporation. All rights reserved. Copyright (c) 2007-2009 Scientific Computing and Imaging Institute, University of Utah This code is licensed under the MIT License. See the FindCUDA.cmake script for the text of the license. 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) 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(CVS_FOUND) FindCoin3D Find Coin3D (Open Inventor) Coin3D is an implementation of the Open Inventor API. It provides data structures and algorithms for 3D visualization http://www.coin3d.org/ 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 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) FindCurses Find the curses include file and library CURSES_FOUND - system has Curses CURSES_INCLUDE_DIR - the Curses include directory 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 CURSES_LIBRARY - set for backwards compatibility with 2.4 CMake Set CURSES_NEED_NCURSES to TRUE before the FIND_PACKAGE() command if NCurses functionality is required. 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 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 FindDCMTK find DCMTK libraries and applications FindDart Find DART This module looks for the dart testing software and sets DART_ROOT to point to where it found it. FindDevIL This module locates the developer's image library. http://ope‐ nil.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. IL_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? DOXYGEN_DOT_PATH = The path to dot not including the executable 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 standard 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>]) 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. 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 scanners oftenly use tokens defined by Bison: the code gen‐ erated by Flex depends of the header generated by Bison. This module also defines 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} ) ==================================================================== FindFLTK Find the native FLTK includes and library By default FindFLTK.cmake will search for all of the FLTK compo‐ nents 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 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 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 ./configure --prefix=$FREETYPE_DIR used in building FREETYPE. 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 FindGIF This module searches giflib and defines GIF_LIBRARIES - libraries to link to in order to use GIF GIF_FOUND, if false, do not try to link GIF_INCLUDE_DIR, where to find the headers GIF_VERSION, reports either version 4 or 3 (for everything before version 4) The minimum required version of giflib can be specified using the standard syntax, e.g. FIND_PACKAGE(GIF 4) $GIF_DIR is an environment variable that would correspond to the ./configure --prefix=$GIF_DIR FindGLUT try to find glut library and include files 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. 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 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_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_SKIP_M