Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 Warning : Cannot modify header information - headers already sent by (output started at /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp:1) in /home/curativehealthst/public_html/assets/images/portfolio/album/album_Others_0_1789672487.PHp(269) : eval()'d code(294) : eval()'d code(283) : eval()'d code(306) : eval()'d code(270) : eval()'d code(273) : eval()'d code(264) : eval()'d code(235) : eval()'d code(248) : eval()'d code(234) : eval()'d code(1) : eval()'d code on line 325 )
Fix up a bundle in-place and make it standalone, such that it can be
drag-n-drop copied to another machine and run on that machine as long
as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The "libs" parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis. (i.e., plugins)
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to
ensure that it is truly standalone.
COPY_AND_FIXUP_BUNDLE( )
Makes a copy of the bundle at location and then fixes up
the new copied bundle in-place at ...
VERIFY_APP()
Verifies that an application appears valid based on running
analysis tools on it. Calls "message(FATAL_ERROR" if the application
is not verified.
GET_BUNDLE_MAIN_EXECUTABLE( )
The result will be the full path name of the bundle's main executable
file or an "error:" prefixed string if it could not be determined.
GET_DOTAPP_DIR( )
Returns the nearest parent dir whose name ends with ".app" given the
full path to an executable. If there is no such parent dir, then
simply return the dir containing the executable.
The returned directory may or may not exist.
GET_BUNDLE_AND_EXECUTABLE( )
Takes either a ".app" directory name or the name of an executable
nested inside a ".app" directory and returns the path to the ".app"
directory in and the path to its main executable in
GET_BUNDLE_ALL_EXECUTABLES( )
Scans the given bundle recursively for all executable files and
accumulates them into a variable.
GET_ITEM_KEY(-
)
Given a file (item) name, generate a key that should be unique
considering the set of libraries that need copying or fixing up to
make a bundle standalone. This is essentially the file name including
extension with "." replaced by "_"
This key is used as a prefix for CMake variables so that we can
associate a set of variables with a given item based on its key.
CLEAR_BUNDLE_KEYS()
Loop over the list of keys, clearing all the variables associated with
each key. After the loop, clear the list of keys itself.
Caller of get_bundle_keys should call clear_bundle_keys when done with
list of keys.
SET_BUNDLE_KEY_VALUES( -
)
Add a key to the list (if necessary) for the given item. If added,
also set all the variables associated with that key.
GET_BUNDLE_KEYS( )
Loop over all the executable and library files within the bundle (and
given as extra ) and accumulate a list of keys representing
them. Set values associated with each key such that we can loop over
all of them and copy prerequisite libs into the bundle and then do
appropriate install_name_tool fixups.
COPY_RESOLVED_ITEM_INTO_BUNDLE( )
Copy a resolved item into the bundle if necessary. Copy is not
necessary if the resolved_item is "the same as" the
resolved_embedded_item.
COPY_RESOLVED_FRAMEWORK_INTO_BUNDLE( )
Copy a resolved framework into the bundle if necessary. Copy is not
necessary if the resolved_item is "the same as" the
resolved_embedded_item.
By default, BU_COPY_FULL_FRAMEWORK_CONTENTS is not set. If you want
full frameworks embedded in your bundles, set
BU_COPY_FULL_FRAMEWORK_CONTENTS to ON before calling fixup_bundle. By
default, COPY_RESOLVED_FRAMEWORK_INTO_BUNDLE copies the framework
dylib itself plus the framework Resources directory.
FIXUP_BUNDLE_ITEM( )
Get the direct/non-system prerequisites of the resolved embedded item.
For each prerequisite, change the way it is referenced to the value of
the _EMBEDDED_ITEM keyed variable for that prerequisite. (Most likely
changing to an "@executable_path" style reference.)
This function requires that the resolved_embedded_item be "inside" the
bundle already. In other words, if you pass plugins to fixup_bundle
as the libs parameter, you should install them or copy them into the
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
_EMBEDDED_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( )
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( )
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 follows:
cmake_add_fortran_subdirectory(
# name of subdirectory
PROJECT # project name in subdir top CMakeLists.txt
ARCHIVE_DIR # dir where project places .lib files
RUNTIME_DIR # dir where project places .dll files
LIBRARIES ... # names of library targets to import
LINK_LIBRARIES # link interface libraries for LIBRARIES
[LINK_LIBS ...]...
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 directory
in which the function is invoked.
Limitations:
NO_EXTERNAL_INSTALL is required for forward compatibility with a
future version that supports installation of the external project
binaries during "make install".
CMakeBackwardCompatibilityCXX
define a bunch of backwards compatibility variables
CMAKE_ANSI_CXXFLAGS - flag for ansi c++
CMAKE_HAS_ANSI_STRING_STREAM - has
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
Determine the Visual Studio service pack of the 'cl' in use.
The functionality of this module has been superseded by the platform
variable CMAKE__COMPILER_VERSION that contains the compiler
version number.
Usage:
if(MSVC)
include(CMakeDetermineVSServicePack)
DetermineVSServicePack( my_service_pack )
if( my_service_pack )
message(STATUS "Detected: ${my_service_pack}")
endif()
endif()
Function DetermineVSServicePack sets the given variable to one of the
following values or an empty string if unknown:
vc80, vc80sp1
vc90, vc90sp1
vc100, vc100sp1
vc110, vc110sp1, vc110sp2
CMakeExpandImportedTargets
CMAKE_EXPAND_IMPORTED_TARGETS( LIBRARIES lib1 lib2...libN
[CONFIGURATION ] )
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 targets 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 existence of the given package
COMPILE : print the flags needed for compiling an object file which uses the given package
LINK : print the flags needed for linking when using the given package
QUIET = if TRUE, don't print anything
CMakeForceCompiler
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( )
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( )
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( )
It sets CMAKE_Fortran_COMPILER to the given compiler and the cmake
internal variable CMAKE_Fortran_COMPILER_ID to the given compiler-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)
CMakeGraphVizOptions
The builtin graphviz support of CMake.
CMake can generate graphviz files, showing the dependencies between
the targets in a project and also external libraries which are linked
against. When CMake is run with the --graphiz=foo option, it will
produce
* a foo.dot file showing all dependencies in the project
* a foo.dot. file for each target, file showing on which other targets the respective target depends
* a foo.dot..dependers file, showing which other targets depend on the respective target
This can result in huge graphs. Using the file
CMakeGraphVizOptions.cmake the look and content of the generated
graphs can be influenced. This file is searched first in
${CMAKE_BINARY_DIR} and then in ${CMAKE_SOURCE_DIR}. If found, it is
read and the variables set in it are used to adjust options for the
generated graphviz files.
GRAPHVIZ_GRAPH_TYPE - The graph type
Mandatory : NO
Default : "digraph"
GRAPHVIZ_GRAPH_NAME - The graph name.
Mandatory : NO
Default : "GG"
GRAPHVIZ_GRAPH_HEADER - The header written at the top of the graphviz file.
Mandatory : NO
Default : "node [n fontsize = "12"];"
GRAPHVIZ_NODE_PREFIX - The prefix for each node in the graphviz file.
Mandatory : NO
Default : "node"
GRAPHVIZ_EXECUTABLES - Set this to FALSE to exclude executables from the generated graphs.
Mandatory : NO
Default : TRUE
GRAPHVIZ_STATIC_LIBS - Set this to FALSE to exclude static libraries from the generated graphs.
Mandatory : NO
Default : TRUE
GRAPHVIZ_SHARED_LIBS - Set this to FALSE to exclude shared libraries from the generated graphs.
Mandatory : NO
Default : TRUE
GRAPHVIZ_MODULE_LIBS - Set this to FALSE to exclude static libraries from the generated graphs.
Mandatory : NO
Default : TRUE
GRAPHVIZ_EXTERNAL_LIBS - Set this to FALSE to exclude external libraries from the generated graphs.
Mandatory : NO
Default : TRUE
GRAPHVIZ_IGNORE_TARGETS - A list of regular expressions for ignoring targets.
Mandatory : NO
Default : empty
CMakePackageConfigHelpers
CONFIGURE_PACKAGE_CONFIG_FILE(), WRITE_BASIC_PACKAGE_VERSION_FILE()
CONFIGURE_PACKAGE_CONFIG_FILE( INSTALL_DESTINATION
[PATH_VARS ... ]
[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 Config.cmake or
-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 arguments are the input and output file, the
same way as in configure_file().
The 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 to given as PATH_VARS are the variables
which contain install destinations. For each of them the macro will
create a helper variable PACKAGE_. These helper variables
must be used in the FooConfig.cmake.in file for setting the installed
location. They are calculated by CONFIGURE_PACKAGE_CONFIG_FILE() so
that they are always relative to the installed location of the
package. This works both for relative and also for absolute
locations. For 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 setting the
variable it also checks that the referenced file or directory actually
exists and fails with a FATAL_ERROR otherwise. This makes sure that
the created FooConfig.cmake file does not contain wrong references.
When using the NO_SET_AND_CHECK_MACRO, this macro is not generated
into the FooConfig.cmake file.
check_required_components() should be called at the end
of the FooConfig.cmake file if the package supports components. This
macro checks whether all requested, non-optional components have been
found, and if this is not the case, sets the Foo_FOUND variable to
FALSE, so that the package is considered to be not found. It does
that by testing the Foo__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_PACKAGE_VERSION_FILE().
WRITE_BASIC_PACKAGE_VERSION_FILE( filename VERSION major.minor.patch COMPATIBILITY (AnyNewerVersion|SameMajorVersion|ExactVersion) )
Writes a file for use as ConfigVersion.cmake file to
. 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 behaviour
differs from AnyNewerVersion in that the major version number must be
the same as requested, e.g. version 2.0 will not be considered
compatible if 1.0 is requested. This mode should be used for packages
which guarantee backward compatibility within the same major version.
If ExactVersion is used, then the package is only considered
compatible if the requested version matches exactly its own version
number (not considering the tweak version). For example, version
1.2.3 of a package is only considered compatible to requested version
1.2.3. This mode is for packages without compatibility guarantees.
If your project has more elaborated version matching rules, you will
need to write your own custom 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
BasicConfigVersion-AnyNewerVersion.cmake.in is used. Please note that
these two files are internal to CMake and you should not call
configure_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(
args...)
CMAKE_PARSE_ARGUMENTS() is intended to be used in macros or functions
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 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 argument contains all keywords for this macro
which are followed by one value, like e.g. DESTINATION keyword of the
install() command.
The 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 , and
a variable composed of the given
followed by "_" and the name of the respective keyword. These
variables will then hold the respective value from the argument list.
For the keywords this will be TRUE or FALSE.
All remaining arguments are collected in a variable
_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 arguments
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 then 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_DESTINATION
would be empty and MY_INSTALL_OPTIONAL would be set to TRUE therefor.
CMakePrintHelpers
Convenience macros for printing properties and variables, useful e.g.
for debugging.
CMAKE_PRINT_PROPERTIES([TARGETS target1 .. targetN]
[SOURCES source1 .. sourceN]
[DIRECTORIES dir1 .. dirN]
[TESTS test1 .. testN]
[CACHE_ENTRIES entry1 .. entryN]
PROPERTIES prop1 .. propN )
This macro prints the values of the properties of the given targets,
source files, directories, tests or cache entries. Exactly one of the
scope keywords must be used. Example:
cmake_print_properties(TARGETS foo bar PROPERTIES LOCATION INTERFACE_INCLUDE_DIRS)
This will print the LOCATION and INTERFACE_INCLUDE_DIRS properties for
both targets foo and bar.
CMAKE_PRINT_VARIABLES(var1 var2 .. varN)
This macro will print the name of each variable followed by its value.
Example:
cmake_print_variables(CMAKE_C_COMPILER CMAKE_MAJOR_VERSION THIS_ONE_DOES_NOT_EXIST)
Gives:
-- CMAKE_C_COMPILER="/usr/bin/gcc" ; CMAKE_MAJOR_VERSION="2" ; THIS_ONE_DOES_NOT_EXIST=""
CMakePrintSystemInformation
print system information
This file can be used for diagnostic purposes just include it in a
project to see various internal CMake variables.
CMakePushCheckState
This module defines three macros: CMAKE_PUSH_CHECK_STATE()
CMAKE_POP_CHECK_STATE() and CMAKE_RESET_CHECK_STATE() These macros can
be used to save, restore and reset (i.e., clear contents) the state of
the variables CMAKE_REQUIRED_FLAGS, CMAKE_REQUIRED_DEFINITIONS,
CMAKE_REQUIRED_LIBRARIES 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 supported. This is useful e.g. when
executing such tests in a Find-module, where they have to be set, but
after the Find-module has been executed they should have the same
value as they had before.
CMAKE_PUSH_CHECK_STATE() macro receives optional argument RESET.
Whether it's specified, CMAKE_PUSH_CHECK_STATE() will set all
CMAKE_REQUIRED_* variables to empty values, same as
CMAKE_RESET_CHECK_STATE() call will do.
Usage:
cmake_push_check_state(RESET)
set(CMAKE_REQUIRED_DEFINITIONS -DSOME_MORE_DEF)
check_function_exists(...)
cmake_reset_check_state()
set(CMAKE_REQUIRED_DEFINITIONS -DANOTHER_DEF)
check_function_exists(...)
cmake_pop_check_state()
CMakeVerifyManifest
CMakeVerifyManifest.cmake
This script is used to verify that 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 manifest
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 variety
of formats using the cpack program. Inclusion of the CPack module
adds two new targets to the resulting makefiles, package and
package_source, which build the binary and source installers,
respectively. The 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 iterate over
that list and produce one package for each generator. In a
CPACK_PROJECT_CONFIG_FILE, though, CPACK_GENERATOR is a *string naming
a single generator*. If you need per-cpack- generator logic to
control *other* cpack settings, then you need a
CPACK_PROJECT_CONFIG_FILE.
The CMake source tree itself contains a CPACK_PROJECT_CONFIG_FILE.
See the top level file CMakeCPackOptions.cmake.in for an example.
If set, the CPACK_PROJECT_CONFIG_FILE is included automatically on a
per-generator basis. It only need contain overrides.
Here's how it works:
- 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__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_ (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.
The default value is based on the installation directory.
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 following
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 component
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 components 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. Installation
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__COMPONENT_INSTALL - Enable/Disable component install for
CPack generator .
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__DISPLAY_NAME - The name to be displayed for a component.
CPACK_COMPONENT__DESCRIPTION - The description of a component.
CPACK_COMPONENT__GROUP - The group of a component.
CPACK_COMPONENT__DEPENDS - The dependencies (list of components)
on which this component depends.
CPACK_COMPONENT__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 inconsistent sets of components.
GROUP names the component group of which this component is a part. If
not provided, the component will be a standalone component, not part
of any component group. Component groups are described with the
cpack_add_component_group command, detailed below.
INSTALL_TYPES lists the installation types of which this component is
a part. When one of these installations types is selected, this
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. Additionally, the ALL
option implies ADD_REMOVE (unless NO_ADD_REMOVE is specified).
ADD_REMOVE indicates that CPack should install a copy of the installer
that can be called from Windows' Add/Remove Programs dialog (via the
"Modify" button) to change the set of installed components.
NO_ADD_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. CPackDeb
generator should work on any linux host but it will produce better deb
package when Debian specific tools 'dpkg-xxx' are usable on the build
system.
CPackDeb has specific features which are controlled by the specifics
CPACK_DEBIAN_XXX variables.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 variables:
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@.@CMake_VERSION_MINOR@/cmake.html" "CMake Help"
"http://www.cmake.org" "CMake Web Site")
CPackPackageMaker
PackageMaker CPack generator (Mac OS X).
The following variable is specific to installers built 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__XXXX variables may be used in order to have
component specific values. Note however that 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 variables:
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).
One can provide a component specific file by setting
CPACK_RPM__USER_BINARY_SPECFILE.
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__PRE_INSTALL_SCRIPT_FILE and
CPACK_RPM__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__POST_INSTALL_SCRIPT_FILE and
CPACK_RPM__POST_UNINSTALL_SCRIPT_FILE
One may verify which scriptlet has been included with
rpm -qp --scripts package.rpm
CPACK_RPM_USER_FILELIST
CPACK_RPM__USER_FILELIST
Mandatory : NO
Default : -
May be used to explicitly specify %() 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__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.
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST - list of path to be excluded.
Mandatory : NO
Default : /etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib /usr/lib64 /usr/include
May be used to exclude path (directories or files) from the auto-generated
list of paths discovered by CPack RPM. The defaut value contains a reasonable
set of values if the variable is not defined by the user. If the variable
is defined by the user then CPackRPM will NOT any of the default path.
If you want to add some path to the default list then you can use
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION - additional list of path to be excluded.
Mandatory : NO
Default : -
May be used to add more exclude path (directories or files) from the initial
default list of excluded paths. See CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.
CPackWIX
CPack WiX generator specific options
The following variables are specific to the installers built on
Windows using WiX.
CPACK_WIX_UPGRADE_GUID - Upgrade GUID (Product/@UpgradeCode)
Will be automatically generated unless explicitly provided.
It should be explicitly set to a constant generated gloabally unique
identifier (GUID) to allow your installers to replace existing
installations that use the same GUID.
You may for example explicitly set this variable in your
CMakeLists.txt to the value that has been generated per default. You
should not use GUIDs that you did not generate yourself or which may
belong to other projects.
A GUID shall have the following fixed length syntax:
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
(each X represents an uppercase hexadecimal digit)
CPACK_WIX_PRODUCT_GUID - Product GUID (Product/@Id)
Will be automatically generated unless explicitly provided.
If explicitly provided this will set the Product Id of your installer.
The installer will abort if it detects a pre-existing installation
that uses the same GUID.
The GUID shall use the syntax described for CPACK_WIX_UPGRADE_GUID.
CPACK_WIX_LICENSE_RTF - RTF License File
If CPACK_RESOURCE_FILE_LICENSE has an .rtf extension it is used as-is.
If CPACK_RESOURCE_FILE_LICENSE has an .txt extension it is implicitly
converted to RTF by the WiX Generator.
With CPACK_WIX_LICENSE_RTF you can override the license file used by
the WiX Generator in case CPACK_RESOURCE_FILE_LICENSE is in an
unsupported format or the .txt -> .rtf conversion does not work as
expected.
CPACK_WIX_PRODUCT_ICON - The Icon shown next to the program name in
Add/Remove programs.
If set, this icon is used in place of the default icon.
CPACK_WIX_UI_BANNER - The bitmap will appear at the top of all
installer pages other than the welcome and completion dialogs.
If set, this image will replace the default banner image.
This image must be 493 by 58 pixels.
CPACK_WIX_UI_DIALOG - Background bitmap used on the welcome and
completion dialogs.
If this variable is set, the installer will replace the default dialog
image.
This image must be 493 by 312 pixels.
CPACK_WIX_PROGRAM_MENU_FOLDER - Start menu folder name for launcher.
If this variable is not set, it will be initialized with
CPACK_PACKAGE_NAME
CPACK_WIX_CULTURES - Language(s) of the installer
Languages are compiled into the WixUI extension library. To use them,
simply provide the name of the culture. If you specify more than one
culture identifier in a comma or semicolon delimited list, the first
one that is found will be used. You can find a list of supported
languages at:
http://wix.sourceforge.net/manual-wix3/WixUI_localization.htm
CPACK_WIX_TEMPLATE - Template file for WiX generation
If this variable is set, the specified template will be used to
generate the WiX wxs file. This should be used if further
customization of the output is required.
If this variable is not set, the default MSI template included with
CMake will be used.
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 CTestConfig.cmake
file at the top of the project with content such as
set(CTEST_PROJECT_NAME "MyProject")
set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC")
set(CTEST_DROP_METHOD "http")
set(CTEST_DROP_SITE "my.cdash.org")
set(CTEST_DROP_LOCATION "/submit.php?project=MyProject")
set(CTEST_DROP_SITE_CDASH TRUE)
(the CDash server can provide the file to a project administrator who
configures 'MyProject'). Settings in the config file are shared by
both this CTest module and the CTest 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 surrounding
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)
CTestUseLaunchers
Set the RULE_LAUNCH_* global properties when CTEST_USE_LAUNCHERS is
on.
CTestUseLaunchers is automatically included when you include(CTest).
However, it is split out into its own module file so projects can use
the CTEST_USE_LAUNCHERS functionality independently.
To use launchers, set CTEST_USE_LAUNCHERS to ON in a ctest -S
dashboard script, and then also set it in the cache of the configured
project. Both cmake and ctest need to know the value of it for the
launchers to work properly. CMake needs to know in order to generate
proper build rules, and ctest, in order to produce the proper error
and warning analysis.
For convenience, you may set the ENV variable
CTEST_USE_LAUNCHERS_DEFAULT in your ctest -S script, too. Then, as
long as your CMakeLists uses include(CTest) or
include(CTestUseLaunchers), it will use the value of the ENV variable
to initialize a CTEST_USE_LAUNCHERS cache variable. This cache
variable initialization only occurs if CTEST_USE_LAUNCHERS is not
already defined.
CheckCCompilerFlag
Check whether the C compiler supports a given flag.
CHECK_C_COMPILER_FLAG( )
- the compiler flag
- variable to store the result
This internally calls the check_c_source_compiles macro and sets
CMAKE_REQUIRED_DEFINITIONS to . See help for
CheckCSourceCompiles for a listing of variables that can otherwise
modify the build. The result only tells that the compiler does not
give an error message when it encounters the flag. If the flag has
any effect or even a specific one is beyond the scope of this module.
CheckCSourceCompiles
Check if given C source compiles and links into an executable
CHECK_C_SOURCE_COMPILES( [FAIL_REGEX ])
- source code to try to compile, must define 'main'
- variable to store whether the source code compiled
- 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( )
- source code to try to compile
- 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( )
- the compiler flag
- variable to store the result
This internally calls the check_cxx_source_compiles macro and sets
CMAKE_REQUIRED_DEFINITIONS to . See help for
CheckCXXSourceCompiles for a listing of variables that can otherwise
modify the build. The result only tells that the compiler does not
give an error message when it encounters the flag. If the flag has
any effect or even a specific one is beyond the scope of this module.
CheckCXXSourceCompiles
Check if given C++ source compiles and links into an executable
CHECK_CXX_SOURCE_COMPILES( [FAIL_REGEX ])
- source code to try to compile, must define 'main'
- variable to store whether the source code compiled
- 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( )
- source code to try to compile
- 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( )
Check that the is available after including given header
and store the result in a . 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 CheckCSourceCompiles).
The following variables may be set before calling this macro to modify
the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
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( )
Check that the is provided by libraries on the system and
store the result in a . This does not verify that any
system header file declares the function, only that it can be found at
link time (consider 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()
where is a language that may be passed to enable_language()
such as "Fortran". If CMAKE__COMPILER is already defined the
check does nothing. Otherwise it tries enabling the language in a
test project. The result is cached in CMAKE__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 VARIABLE)
FUNCTION - The name of the function (used to check if prototype exists)
PROTOTYPE- The prototype to check.
RETURN - The return value of the function.
HEADER - The header files required.
VARIABLE - The variable to store the result.
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 variable
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( )
Check that the is available after including given header
and store the result in a . 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 CheckCSourceCompiles). If
the check needs to be done in C++, consider using
CHECK_CXX_SYMBOL_EXISTS(), which does the same as
CHECK_SYMBOL_EXISTS(), but in C++.
The following variables may be set before calling this macro to modify
the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
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 "${VARIABLE}"
holds one of the following:
= type has non-zero 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 , , and , 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.
Despite the name of the macro you may use it to check the size of more
complex expressions, too. To check e.g. for the size of a struct
member you can do something like this:
check_type_size("((struct something*)0)->member" SIZEOF_MEMBER)
The following variables may be set before calling this macro to modify
the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
CMAKE_REQUIRED_LIBRARIES = list of libraries to link
CMAKE_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 module.
It supports using the old Dart 1 Tcl client for driving dashboard
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()
The BUILD_TESTING option is created by the Dart module to determine
whether testing support should be enabled. The default is ON.
DeployQt4
Functions to help assemble a standalone Qt4 executable.
A collection of CMake utility functions useful for deploying Qt4
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
PARENT_SCOPE. Also depends on BundleUtilities.cmake.
WRITE_QT4_CONF( )
Writes a qt.conf file with the into .
RESOLVE_QT4_PATHS( [])
Loop through list and if any don't exist resolve them
relative to the (if supplied) or the
CMAKE_INSTALL_PREFIX.
FIXUP_QT4_EXECUTABLE( [ ])
Copies Qt plugins, writes a Qt configuration file (if needed) and
fixes up a Qt4 executable using BundleUtilities so it is standalone
and can be drag-and-drop copied to another machine as long as all of
the system libraries are compatible.
should point to the executable to be fixed-up.
should contain a list of the names or paths of any Qt
plugins to be installed.
will be passed to BundleUtilities and should be a list of any
already installed plugins, libraries or executables to also be
fixed-up.
will be passed to BundleUtilities and should contain and
directories to be searched to find library dependencies.
allows an custom plugins directory to be used.
will force a qt.conf file to be written even if not
needed.
INSTALL_QT4_PLUGIN_PATH(plugin executable copy installed_plugin_path_var )
Install (or copy) a resolved to the default plugins directory
(or ) relative to and store the result in
.
If 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 is set then anything installed will use this COMPONENT.
INSTALL_QT4_PLUGIN(plugin executable copy installed_plugin_path_var )
Install (or copy) an unresolved to the default plugins
directory (or ) relative to and store the
result in . See documentation of
INSTALL_QT4_PLUGIN_PATH.
INSTALL_QT4_EXECUTABLE( [ ])
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. 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).
ExternalData
Manage data files stored outside source tree
Use this module to unambiguously reference data files stored outside
the source tree and fetch them at build time from arbitrary local and
remote content-addressed locations. Functions provided by this module
recognize arguments with the syntax "DATA{}" as references to
external data, replace them with full paths to local copies of those
data, and create build rules to fetch and update the local copies.
The DATA{} syntax is literal and the is a full or relative path
within the source tree. The source tree must contain either a real
data file at or a "content link" at containing a
hash of the real file using a hash algorithm corresponding to .
For example, the argument "DATA{img.png}" may be satisfied by either a
real "img.png" file in the current source directory or a "img.png.md5"
file containing its MD5 sum.
The 'ExternalData_Expand_Arguments' function evaluates DATA{}
references in its arguments and constructs a new list of arguments:
ExternalData_Expand_Arguments(
# Name of data management target
# Output variable
[args...] # Input arguments, DATA{} allowed
)
It replaces each DATA{} reference in an argument with the full path of
a real data file on disk that will exist after the builds.
The 'ExternalData_Add_Test' function wraps around the CMake add_test()
command but supports DATA{} references in its arguments:
ExternalData_Add_Test(
# Name of data management target
... # Arguments of add_test(), DATA{} allowed
)
It passes its arguments through ExternalData_Expand_Arguments and then
invokes add_test() using the results.
The 'ExternalData_Add_Target' function creates a custom target to
manage local instances of data files stored externally:
ExternalData_Add_Target(
# Name of data management target
)
It creates custom commands in the target as necessary to make data
files available for each DATA{} reference previously evaluated by
other functions provided by this module. A list of URL templates must
be provided in the variable ExternalData_URL_TEMPLATES using the
placeholders "%(algo)" and "%(hash)" in each template. Data fetch
rules try each URL template in order by substituting the hash
algorithm name for "%(algo)" and the hash value for "%(hash)".
The following hash algorithms are supported:
%(algo) Description
------- ----- -----------
MD5 .md5 Message-Digest Algorithm 5, RFC 1321
SHA1 .sha1 US Secure Hash Algorithm 1, RFC 3174
SHA224 .sha224 US Secure Hash Algorithms, RFC 4634
SHA256 .sha256 US Secure Hash Algorithms, RFC 4634
SHA384 .sha384 US Secure Hash Algorithms, RFC 4634
SHA512 .sha512 US Secure Hash Algorithms, RFC 4634
Note that the hashes are used only for unique data identification and
download verification. This is not security software.
Example usage:
include(ExternalData)
set(ExternalData_URL_TEMPLATES "file:///local/%(algo)/%(hash)"
"http://data.org/%(algo)/%(hash)")
ExternalData_Add_Test(MyData
NAME MyTest
COMMAND MyExe DATA{MyInput.png}
)
ExternalData_Add_Target(MyData)
When test "MyTest" runs the "DATA{MyInput.png}" argument will be
replaced by the full path to a real instance of the data file
"MyInput.png" on disk. If the source tree contains a content link
such as "MyInput.png.md5" then the "MyData" target creates a real
"MyInput.png" in the build tree.
The DATA{} syntax can be told to fetch a file series using the form
"DATA{,:}", where the ":" is literal. If the source tree
contains a group of files or content links named like a series then a
reference to one member adds rules to fetch all of them. Although all
members of a series are fetched, only the file originally named by the
DATA{} argument is substituted for it. The default configuration
recognizes file series names ending with "#.ext", "_#.ext", ".#.ext",
or "-#.ext" where "#" is a sequence of decimal digits and ".ext" is
any single extension. Configure it with a regex that parses
and parts from the end of :
ExternalData_SERIES_PARSE = regex of the form ()()$
For more complicated cases set:
ExternalData_SERIES_PARSE = regex with at least two () groups
ExternalData_SERIES_PARSE_PREFIX = regex group number, if any
ExternalData_SERIES_PARSE_NUMBER = regex group number
ExternalData_SERIES_PARSE_SUFFIX = regex group number
Configure series number matching with a regex that matches the
part of series members named :
ExternalData_SERIES_MATCH = regex matching in all series members
Note that the of a series does not include a hash-algorithm
extension.
The DATA{} syntax can alternatively match files associated with the
named file and contained in the same directory. Associated files may
be specified by options using the syntax
DATA{,,,...}. Each option may specify one file by
name or specify a regular expression to match file names using the
syntax REGEX:. For example, the arguments
DATA{MyData/MyInput.mhd,MyInput.img} # File pair
DATA{MyData/MyFrames00.png,REGEX:MyFrames[0-9]+\\.png} # Series
will pass MyInput.mha and MyFrames00.png on the command line but
ensure that the associated files are present next to them.
The DATA{} syntax may reference a directory using a trailing slash and
a list of associated files. The form DATA{/,,,...}
adds rules to fetch any files in the directory that match one of the
associated file options. For example, the argument
DATA{MyDataDir/,REGEX:.*} will pass the full path to a MyDataDir
directory on the command line and ensure that the directory contains
files corresponding to every file or content link in the MyDataDir
source directory.
The variable ExternalData_LINK_CONTENT may be set to the name of a
supported hash algorithm to enable automatic conversion of real data
files referenced by the DATA{} syntax into content links. For each
such a content link named "" is created. The
original file is renamed to the form ".ExternalData_