| CPACK-GENERATORS(7) | CMake | CPACK-GENERATORS(7) |
cpack-generators - CPack Generator Reference
CPack generator for packaging files into an archive, which can have any of the following formats:
New in version 3.1: 7Z and TXZ formats support.
New in version 3.16: TZST format support.
When this generator is called from CPackSourceConfig.cmake (or through the package_source target), then the generated archive will contain all files in the project directory, except those specified in CPACK_SOURCE_IGNORE_FILES. The following is one example of packaging all source files of a project:
set(CPACK_SOURCE_GENERATOR "TGZ") set(CPACK_SOURCE_IGNORE_FILES
\\.git/
build/
".*~$" ) set(CPACK_VERBATIM_VARIABLES YES) include(CPack)
When this generator is called from CPackConfig.cmake (or through the package target), then the generated archive will contain all files that have been installed via CMake's install() command (and the deprecated commands install_files(), install_programs(), and install_targets()).
The default is <CPACK_PACKAGE_FILE_NAME>[-<component>], with spaces replaced by '-'.
New in version 3.9: Per-component CPACK_ARCHIVE_<component>_FILE_NAME variables.
Package file extension. Default values are given in the list above.
These variables are used by the Archive generator, but are also available to CPack generators which are essentially archives at their core. These include:
The number of threads to use when performing the compression. If set to 0, the number of available cores on the machine will be used instead. The default is 1 which limits compression to a single thread. Note that not all compression modes support threading in all environments. Currently, only the XZ compression may support it.
See also the CPACK_THREADS variable.
New in version 3.21: Official CMake binaries available on cmake.org now ship with a liblzma that supports parallel compression. Older versions did not.
CPack Bundle generator (macOS) specific options
Installers built on macOS using the Bundle generator use the aforementioned DragNDrop (CPACK_DMG_xxx) variables, plus the following Bundle-specific parameters (CPACK_BUNDLE_xxx).
The name of your Apple supplied code signing certificate for the application. The name usually takes the form Developer ID Application: [Name] or 3rd Party Mac Developer Application: [Name]. If this variable is not set the application will not be signed.
The name of the Property List (.plist) file that contains your Apple entitlements for sandboxing your application. This file is required for submission to the macOS App Store.
A list of additional files that you wish to be signed. You do not need to list the main application folder, or the main executable. You should list any frameworks and plugins that are included in your app bundle.
Additional parameter that will passed to codesign. Default value: --deep -f
Path to the codesign(1) command used to sign applications with an Apple cert. This variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it).
Cygwin CPack generator (Cygwin).
The following variable is specific to installers build on and/or for Cygwin:
The built in (binary) CPack DEB generator (Unix only)
The CPack DEB generator may be used to create DEB package using CPack. The CPack DEB generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.
The CPack DEB generator should work on any Linux host but it will produce better deb package when Debian specific tools dpkg-xxx are usable on the build system.
The CPack DEB generator has specific features which are controlled by the specifics CPACK_DEBIAN_XXX variables.
CPACK_DEBIAN_<COMPONENT>_XXXX variables may be used in order to have component specific values. Note however that <COMPONENT> refers to the grouping name written in upper case. It may be either a component name or a component GROUP name.
Here are some CPack DEB generator wiki resources that are here for historic reasons and are no longer maintained but may still prove useful:
List of CPack DEB generator specific variables:
If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.
New in version 3.5: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME variables.
See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source
Package file name.
This may be set to DEB-DEFAULT to allow the CPack DEB generator to generate package file name by itself in deb format:
<PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
Alternatively provided package file name must end with either .deb or .ipk suffix.
New in version 3.10: .ipk suffix used by OPKG packaging system.
NOTE:
NOTE:
The Debian package epoch
Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages.
This variable may contain only alphanumerics (A-Za-z0-9) and the characters . + - ~ (full stop, plus, hyphen, tilde) and should start with a digit. If CPACK_DEBIAN_PACKAGE_RELEASE is not set then hyphens are not allowed.
NOTE:
The Debian package release - Debian revision number.
This is the numbering of the DEB package itself, i.e. the version of the packaging and not the version of the content (see CPACK_DEBIAN_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.
New in version 3.6: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE variables.
New in version 3.3: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS variables.
NOTE:
Example:
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libc6 (< 2.4)")
Sets inter-component dependencies if listed with CPACK_COMPONENT_<compName>_DEPENDS variables.
If after that description is not set, CPACK_PACKAGE_DESCRIPTION_SUMMARY going to be used if set. Otherwise, CPACK_PACKAGE_DESCRIPTION_SUMMARY will be added as the first line of description as defined in Debian Policy Manual.
New in version 3.3: Per-component CPACK_COMPONENT_<compName>_DESCRIPTION variables.
New in version 3.16: Per-component CPACK_DEBIAN_<COMPONENT>_DESCRIPTION variables.
New in version 3.16: The CPACK_PACKAGE_DESCRIPTION_FILE variable.
New in version 3.5: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION variables.
See https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
Deprecated since version 3.14.
The archive format used for creating the Debian package.
Possible value is:
NOTE:
The compression used for creating the Debian package.
Possible values are:
New in version 3.5: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY variables.
See https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
New in version 3.12: The CMAKE_PROJECT_HOMEPAGE_URL variable.
NOTE:
NOTE:
NOTE:
New in version 3.3: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS variables.
New in version 3.6: Correct handling of $ORIGIN in CMAKE_INSTALL_RPATH.
May be set to a list of directories that will be given to dpkg-shlibdeps via its -l option. These will be searched by dpkg-shlibdeps in order to find private shared library dependencies.
NOTE:
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
NOTE:
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS variables.
See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
Allows to generate shlibs control file automatically. Compatibility is defined by CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY variable value.
NOTE:
Compatibility policy for auto-generated shlibs control file.
Defines compatibility policy for auto-generated shlibs control file. Possible values: "=", ">="
See https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps
Usage:
set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
"${CMAKE_CURRENT_SOURCE_DIR}/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
New in version 3.4: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA variables.
This variable indicates if the Debian policy on control files should be strictly followed.
Usage:
set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE)
This overrides the permissions on the original files, following the rules set by Debian policy https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
NOTE:
Sets the Source field of the binary Debian package. When the binary package name is not the same as the source package name (in particular when several components/binaries are generated from one source) the source from which the binary has been generated should be indicated with the field Source.
See https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source
NOTE:
New in version 3.13.
Dbgsym packages contain debug symbols for debugging packaged binaries.
Dbgsym packaging has its own set of variables:
NOTE:
NOTE:
Additionally, if CPACK_STRIP_FILES is set, the files will be stripped before they get to the DEB generator, so will not contain debug symbols and a dbgsym package will not get built. Do not use with CPACK_STRIP_FILES.
New in version 3.10.
To communicate UNIX file permissions from the install stage to the CPack DEB generator the "cmake_mode_t" NTFS alternate data stream (ADT) is used.
When a filesystem without ADT support is used only owner read/write permissions can be preserved.
New in version 3.13.
The environment variable SOURCE_DATE_EPOCH may be set to a UNIX timestamp, defined as the number of seconds, excluding leap seconds, since 01 Jan 1970 00:00:00 UTC. If set, the CPack DEB generator will use its value for timestamps in the package.
The DragNDrop CPack generator (macOS) creates a DMG image.
The following variables are specific to the DragNDrop installers built on macOS:
Path to a custom AppleScript file. This AppleScript is used to generate a .DS_Store file which specifies the Finder window position/geometry and layout (such as hidden toolbars, placement of the icons etc.). By specifying a custom AppleScript there is no need to use CPACK_DMG_DS_STORE, as the .DS_Store that is generated by the AppleScript will be packaged.
Default behavior is to include a symlink to /Applications in the DMG. Set this option to ON to avoid adding the symlink.
Control whether CPACK_RESOURCE_FILE_LICENSE, if set to a non-default value, is used as the license agreement provided when mounting the DMG. If CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE is not set, cpack(1) defaults to off.
In a CMake project that uses the CPack module to generate CPackConfig.cmake, CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE must be explicitly enabled by the project to activate the SLA. See policy CMP0133.
NOTE:
Directory where license and menu files for different languages are stored. Setting this causes CPack to look for a <language>.menu.txt and <language>.license.txt or <language>.license.rtf file for every language defined in CPACK_DMG_SLA_LANGUAGES. If both this variable and CPACK_RESOURCE_FILE_LICENSE are set, CPack will only look for the menu files and use the same license file for all languages. If both <language>.license.txt and <language>.license.rtf exist, the .txt file will be used.
New in version 3.17: RTF support.
Languages for which a license agreement is provided when mounting the generated DMG. A menu file consists of 9 lines of text. The first line is is the name of the language itself, uppercase, in English (e.g. German). The other lines are translations of the following strings:
For every language in this list, CPack will try to find files <language>.menu.txt and <language>.license.txt in the directory specified by the CPACK_DMG_SLA_DIR variable.
File name when packaging <component> as its own DMG (CPACK_COMPONENTS_GROUPING set to IGNORE).
The filesystem format. Common values are APFS and HFS+. See man hdiutil for a full list of supported formats. Defaults to HFS+.
New in version 3.13.
CPack provides many generators to create packages for a variety of platforms and packaging systems. The intention is for CMake/CPack to be a complete end-to-end solution for building and packaging a software project. However, it may not always be possible to use CPack for the entire packaging process, due to either technical limitations or policies that require the use of certain tools. For this reason, CPack provides the "External" generator, which allows external packaging software to take advantage of some of the functionality provided by CPack, such as component installation and the dependency graph.
The CPack External generator generates a .json file containing the CPack internal metadata, which gives external software information on how to package the software. External packaging software may itself invoke CPack, consume the generated metadata, install and package files as required.
Alternatively CPack can invoke an external packaging software through an optional custom CMake script in CPACK_EXTERNAL_PACKAGE_SCRIPT instead.
Staging of installation files may also optionally be taken care of by the generator when enabled through the CPACK_EXTERNAL_ENABLE_STAGING variable.
The JSON metadata file contains a list of CPack components and component groups, the various options passed to cpack_add_component() and cpack_add_component_group(), the dependencies between the components and component groups, and various other options passed to CPack.
The JSON's root object will always provide two fields: formatVersionMajor and formatVersionMinor, which are always integers that describe the output format of the generator. Backwards-compatible changes to the output format (for example, adding a new field that didn't exist before) cause the minor version to be incremented, and backwards-incompatible changes (for example, deleting a field or changing its meaning) cause the major version to be incremented and the minor version reset to 0. The format version is always of the format major.minor. In other words, it always has exactly two parts, separated by a period.
You can request one or more specific versions of the output format as described below with CPACK_EXTERNAL_REQUESTED_VERSIONS. The output format will have a major version that exactly matches the requested major version, and a minor version that is greater than or equal to the requested minor version. If no version is requested with CPACK_EXTERNAL_REQUESTED_VERSIONS, the latest known major version is used by default. Currently, the only supported format is 1.0, which is described below.
In addition to the standard format fields, format version 1.0 provides the following fields in the root:
If this variable is set to a non-empty value, the CPack External generator will iterate through each item in the list to search for a version that it knows how to generate. Requested versions should be listed in order of descending preference by the client software, as the first matching version in the list will be generated.
The generator knows how to generate the version if it has a versioned generator whose major version exactly matches the requested major version, and whose minor version is greater than or equal to the requested minor version. For example, if CPACK_EXTERNAL_REQUESTED_VERSIONS contains 1.0, and the CPack External generator knows how to generate 1.1, it will generate 1.1. If the generator doesn't know how to generate a version in the list, it skips the version and looks at the next one. If it doesn't know how to generate any of the requested versions, an error is thrown.
If this variable is not set, or is empty, the CPack External generator will generate the highest major and minor version that it knows how to generate.
If an invalid version is encountered in CPACK_EXTERNAL_REQUESTED_VERSIONS (one that doesn't match major.minor, where major and minor are integers), it is ignored.
The CPACK_EXTERNAL_PACKAGE_SCRIPT script may set this list variable to the full paths of generated package files. CPack will copy these files from the staging directory back to the top build directory and possibly produce checksum files if the CPACK_PACKAGE_CHECKSUM is set.
New in version 3.10.
The built in (binary) CPack FreeBSD (pkg) generator (Unix only)
The CPack FreeBSD generator may be used to create pkg(8) packages -- these may be used on FreeBSD, DragonflyBSD, NetBSD, OpenBSD, but also on Linux or OSX, depending on the installed package-management tools -- using CPack.
The CPack FreeBSD generator is a CPack generator and uses the CPACK_XXX variables used by CPack. It tries to re-use packaging information that may already be specified for Debian packages for the CPack DEB Generator. It also tries to re-use RPM packaging information when Debian does not specify.
The CPack FreeBSD generator should work on any host with libpkg installed. The packages it produces are specific to the host architecture and ABI.
The CPack FreeBSD generator sets package-metadata through CPACK_FREEBSD_XXX variables. The CPack FreeBSD generator, unlike the CPack Deb generator, does not specially support componentized packages; a single package is created from all the software artifacts created through CMake.
All of the variables can be set specifically for FreeBSD packaging in the CPackConfig file or in CMakeLists.txt, but most of them have defaults that use general settings (e.g. CMAKE_PROJECT_NAME) or Debian-specific variables when those make sense (e.g. the homepage of an upstream project is usually unchanged by the flavor of packaging). When there is no Debian information to fall back on, but the RPM packaging has it, fall back to the RPM information (e.g. package license).
New in version 3.12: The CPACK_PACKAGE_HOMEPAGE_URL variable.
New in version 3.1.
Configure and run the Qt Installer Framework to generate a Qt installer.
This cpack generator generates configuration and meta information for the Qt Installer Framework (QtIFW), and runs QtIFW tools to generate a Qt installer.
QtIFW provides tools and utilities to create installers for the platforms supported by Qt: Linux, Microsoft Windows, and macOS.
To make use of this generator, QtIFW needs to be installed. The CPackIFW module looks for the location of the QtIFW command-line utilities, and defines several commands to control the behavior of this generator. See Hints for Finding QtIFW.
You can use the following variables to change the behavior of the CPack IFW generator.
Set to ON to enable addition debug output. By default is OFF.
Filename for a watermark image in PNG format, used as QWizard::WatermarkPixmap. It must be an absolute path.
Filename for a banner image in PNG format, used as QWizard::BannerPixmap. It must be an absolute path.
Filename for a background image in PNG format, used as QWizard::BackgroundPixmap (only used by MacStyle). It must be an absolute path.
Wizard style to be used (Modern, Mac, Aero or Classic).
Default width of the wizard in pixels. Setting a banner image will override this.
Default height of the wizard in pixels. Setting a watermark image will override this.
Set to OFF if the widget listing installer pages on the left side of the wizard should not be shown.
It is ON by default, but will only have an effect if using QtIFW 4.0 or later.
Color of the titles and subtitles (takes an HTML color code, such as #88FF33).
Filename for a stylesheet. It must be an absolute path.
You can use predefined variables.
Set to OFF if the target directory should not be deleted when uninstalling.
Is ON by default
Name of the default program group for the product in the Windows Start menu. If not specified, it defaults to CPACK_IFW_PACKAGE_NAME.
Filename of the generated maintenance tool. The platform-specific executable file extension will be appended.
If not specified, QtIFW provides a default name (maintenancetool).
Filename for the configuration of the generated maintenance tool.
If not specified, QtIFW uses a default file name (maintenancetool.ini).
Set to ON if the installation path can contain non-ASCII characters. Only supported for QtIFW 2.0 and later. Older QtIFW versions will always allow non-ASCII characters.
Set to OFF if the installation path cannot contain space characters.
Is ON for QtIFW less 2.0 tools.
Set to ON if command line interface features should be disabled. It is OFF by default and will only have an effect if using QtIFW 4.0 or later.
Filename for a custom installer control script.
List of additional resources (.qrc files) to include in the installer binary. They should be specified as absolute paths and no two resource files can have the same file name.
You can use the cpack_ifw_add_package_resources() command to resolve relative paths.
The target binary extension.
On Linux, the name of the target binary is automatically extended with .run, if you do not specify the extension.
On Windows, the target is created as an application with the extension .exe, which is automatically added, if not supplied.
On Mac, the target is created as an DMG disk image with the extension .dmg, which is automatically added, if not supplied.
The default value of this variable is computed by CPack and contains all repositories added with cpack_ifw_add_repository() or updated with cpack_ifw_update_repository().
A list of images to be shown on the PerformInstallationPage. These must be absolute paths and the images must be in PNG format.
This feature is available for QtIFW 4.0.0 and later.
Command executed after the installer is finished, if the user accepts the action. Provide the full path to the application, as found when installed. This typically means the path should begin with the QtIFW predefined variable @TargetDir@.
This feature is available for QtIFW 4.0.0 and later.
List of arguments passed to the program specified in CPACK_IFW_PACKAGE_RUN_PROGRAM.
This feature is available for QtIFW 4.0.0 and later.
Text shown next to the check box for running the program after the installation. If CPACK_IFW_PACKAGE_RUN_PROGRAM is set but no description is provided, QtIFW will use a default message like Run <Name> now.
This feature is available for QtIFW 4.0.0 and later.
Allows specifying a code signing identity to be used for signing the generated app bundle. Only available on macOS, ignored on other platforms.
Set the format used when packaging new component data archives. If you omit this option, the 7z format will be used as a default. Supported formats:
NOTE:
This feature is available for QtIFW 4.2.0 and later.
Archive compression level. The allowable values are:
If this variable is not set, QtIFW will use a default compression level, which will typically be 5 (Normal compression).
NOTE:
This feature is available for QtIFW 4.2.0 and later.
Additional prepared repository directories that will be used to resolve and repack dependent components.
This feature is available for QtIFW 3.1 and later.
The version of the QtIFW tools that will be used. This variable is set by the CPackIFW module.
The following variables provide the locations of the QtIFW command-line tools as discovered by the CPackIFW module. These variables are cached, and may be configured if needed.
The path to archivegen.
Generally, the CPack IFW generator automatically finds QtIFW tools. The following (in order of precedence) can also be set to augment the locations normally searched by find_program():
CMake variable
Environment variable
NOTE:
By default, this generator generates an offline installer. This means that all packaged files are fully contained in the installer executable.
In contrast, an online installer will download some or all components from a remote server.
The DOWNLOADED option in the cpack_add_component() command specifies that a component is to be downloaded. Alternatively, the ALL option in the cpack_configure_downloads() command specifies that all components are to be be downloaded.
The cpack_ifw_add_repository() command and the CPACK_IFW_DOWNLOAD_ALL variable allow for more specific configuration.
When there are online components, CPack will write them to archive files. The help page of the CPackComponent module, especially the section on the cpack_configure_downloads() function, explains how to make these files accessible from a download URL.
New in version 3.9.
Some variables and command arguments support internationalization via CMake script. This is an optional feature.
Installers created by QtIFW tools have built-in support for internationalization and many phrases are localized to many languages, but this does not apply to the description of your components and groups.
Localization of the description of your components and groups is useful for users of your installers.
A localized variable or argument can contain a single default value, and after that a set of pairs with the name of the locale and the localized value.
For example:
set(LOCALIZABLE_VARIABLE "Default value"
en "English value"
en_US "American value"
en_GB "Great Britain value"
)
Qt Installer Framework Manual:
CPack Nullsoft Scriptable Install System (NSIS) generator specific options.
Changed in version 3.22: The NSIS generator requires NSIS 3.03 or newer.
The following variables are specific to the graphical installers built on Windows Nullsoft Scriptable Install System.
The filename of a bitmap to use as the NSIS MUI_WELCOMEFINISHPAGE_BITMAP.
The filename of a bitmap to use as the NSIS MUI_UNWELCOMEFINISHPAGE_BITMAP.
Custom install directory for the specified component <compName> instead of $INSTDIR.
set(CPACK_NSIS_MENU_LINKS
"doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
"CMake Help" "https://cmake.org" "CMake Web Site")
Specify the name of the program to uninstall the version. Default is Uninstall.
The title to display on the top of the page for the welcome page.
Display the title in the welcome page on 3 lines instead of 2.
The title to display on the top of the page for the finish page.
Display the title in the finish page on 3 lines instead of 2.
The image to display on the header of installers pages.
If set, declares that the installer is DPI-aware.
If set, updates the text at the bottom of the install window. To set the string to blank, use a space (" ").
If set, trim down the size of the control to the size of the branding text string. Allowed values for this variable are LEFT, CENTER or RIGHT. If not specified, the default behavior is LEFT.
If set, specify the name of the NSIS executable. Default is makensis.
If set, do not display the page containing the license during installation.
This variable is a semicolon-separated list of arguments to prepend to the nsis script to run. If the arguments do not start with a / or a -, it will add one automatically to the corresponding arguments. The command that will be run is:
makensis.exe <preArgs>... "nsisFileName.nsi" <postArgs>...
where <preArgs>... is constructed from CPACK_NSIS_EXECUTABLE_PRE_ARGUMENTS and <postArgs>... is constructed from CPACK_NSIS_EXECUTABLE_POST_ARGUMENTS.
This variable is a semicolon-separated list of arguments to append to the nsis script to run. If the arguments do not start with a / or a -, it will add one automatically to the corresponding arguments. The command that will be run is:
makensis.exe <preArgs>... "nsisFileName.nsi" <postArgs>...
where <preArgs>... is constructed from CPACK_NSIS_EXECUTABLE_PRE_ARGUMENTS and <postArgs>... is constructed from CPACK_NSIS_EXECUTABLE_POST_ARGUMENTS.
New in version 3.12.
When build a NuGet package there is no direct way to control an output filename due a lack of the corresponding CLI option of NuGet, so there is no CPACK_NUGET_PACKAGE_FILE_NAME variable. To form the output filename NuGet uses the package name and the version according to its built-in rules.
Also, be aware that including a top level directory (CPACK_INCLUDE_TOPLEVEL_DIRECTORY) is ignored by this generator.
The CPack NuGet generator may be used to create NuGet packages using CPack. The CPack NuGet generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.
The CPack NuGet generator has specific features which are controlled by the specifics CPACK_NUGET_XXX variables. In the "one per group" mode (see CPACK_COMPONENTS_GROUPING), <compName> placeholder in the variables below would contain a group name (uppercased and turned into a "C" identifier).
List of CPack NuGet generator specific variables:
An URL for the package's license, often shown in UI displays as well as on nuget.org.
A Software Package Data Exchange SPDX license identifier such as MIT, BSD-3-Clause, or LGPL-3.0-or-later. In the case of a choice of licenses or more complex restrictions, compound license expressions may be formed using boolean operators, for example MIT OR BSD-3-Clause. See the SPDX specification for guidance on forming complex license expressions.
If CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME is specified, CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION is ignored.
If CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME is specified, CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION is ignored.
New in version 3.20.
An URL for a 64x64 image with transparency background to use as the icon for the package in UI display.
The filename of a 64x64 image with transparency background to use as the icon for the package in UI display.
Locale specifier for the package, for example en_CA.
Removed. This once generated PackageMaker installers, but the generator has been removed since CMake 3.24. Xcode no longer distributes the PackageMaker tools. Use the CPack productbuild Generator instead.
New in version 3.7.
productbuild CPack generator (macOS).
The following variable is specific to installers built on Mac macOS using ProductBuild:
Set the unique (non-localized) product identifier to be associated with the product (i.e., com.kitware.cmake). Any component product names will be appended to this value.
Adds a digital signature to the resulting package.
Specify a specific keychain to search for the signing identity.
Adds a digital signature to the resulting package.
Specify a specific keychain to search for the signing identity.
If specified the productbuild generator copies files from this directory (including subdirectories) to the Resources directory. This is done before the CPACK_RESOURCE_FILE_WELCOME, CPACK_RESOURCE_FILE_README, and CPACK_RESOURCE_FILE_LICENSE files are copied.
This option enables more granular control over where the product may be installed. When it is set to true, a domains element of the following form will be added to the productbuild Distribution XML:
<domains enable_anywhere="true" enable_currentUserHome="false" enable_localSystem="true"/>
The default values are as shown above, but can be overridden with CPACK_PRODUCTBUILD_DOMAINS_ANYWHERE, CPACK_PRODUCTBUILD_DOMAINS_USER, and CPACK_PRODUCTBUILD_DOMAINS_ROOT.
May be used to override the enable_anywhere attribute in the domains element of the Distribution XML. When set to true, the product can be installed at the root of any volume, including non-system volumes.
CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect.
May be used to override the enable_currentUserHome attribute in the domains element of the Distribution XML. When set to true, the product can be installed into the current user's home directory. Note that when installing into the user's home directory, the following additional requirements will apply:
CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect.
May be used to override the enable_localSystem attribute in the domains element of the Distribution XML. When set to true, the product can be installed in the root directory. This should normally be set to true unless the product should only be installed to the user's home directory.
CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect.
New in version 3.17.
This group of variables controls the background image of the generated installer.
CPack uses a template file to generate the distribution.dist file used internally by this package generator. Ordinarily, CMake provides the template file, but projects may supply their own by placing a file called CPack.distribution.dist.in in one of the directories listed in the CMAKE_MODULE_PATH variable. CPack will then pick up the project's template file instead of using its own.
The distribution.dist file is generated by performing substitutions similar to the configure_file() command. Any variable set when CPack runs will be available for substitution using the usual @...@ form. The following variables are also set internally and made available for substitution:
This contains all the XML elements that specify installer-wide options (including domain details), default backgrounds and the choices outline.
This contains only the XML elements that specify the default backgrounds and the choices outline. It does not include the installer-wide options or any domain details. Use CPACK_APPLE_PKG_INSTALLER_CONTENT instead.
The built in (binary) CPack RPM generator (Unix only)
The CPack RPM generator may be used to create RPM packages using CPack. The CPack RPM generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.
The CPack RPM generator has specific features which are controlled by the specifics CPACK_RPM_XXX variables.
CPACK_RPM_<COMPONENT>_XXXX variables may be used in order to have component specific values. Note however that <COMPONENT> refers to the grouping name written in upper case. It may be either a component name or a component GROUP name. Usually those variables correspond to RPM spec file entities. One may find information about spec files here https://rpm.org/documentation
Changed in version 3.6: <COMPONENT> part of variables is preferred to be in upper case (e.g. if component is named foo then use CPACK_RPM_FOO_XXXX variable name format) as is with other CPACK_<COMPONENT>_XXXX variables. For the purposes of back compatibility (CMake/CPack version 3.5 and lower) support for same cased component (e.g. fOo would be used as CPACK_RPM_fOo_XXXX) is still supported for variables defined in older versions of CMake/CPack but is not guaranteed for variables that will be added in the future. For the sake of back compatibility same cased component variables also override upper cased versions where both are present.
Here are some CPack RPM generator wiki resources that are here for historic reasons and are no longer maintained but may still prove useful:
List of CPack RPM generator specific variables:
If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.
New in version 3.2: Per-component CPACK_RPM_<component>_PACKAGE_SUMMARY variables.
New in version 3.5: Per-component CPACK_RPM_<component>_PACKAGE_NAME variables.
Package file name.
This may be set to RPM-DEFAULT to allow rpmbuild tool to generate package file name by itself. Alternatively provided package file name must end with .rpm suffix.
NOTE:
Main component that is packaged without component suffix.
This variable can be set to any component or group name so that component or group rpm package is generated without component suffix in filename and package name.
The RPM package epoch
Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages.
This may be set to noarch if you know you are building a noarch package.
New in version 3.3: Per-component CPACK_RPM_<component>_PACKAGE_ARCHITECTURE variables.
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.
NOTE:
The dist tag that is added RPM Release: field.
This is the reported %{dist} tag from the current distribution or empty %{dist} if RPM macro is not set. If this variable is set then RPM Release: field value is set to ${CPACK_RPM_PACKAGE_RELEASE}%{?dist}.
New in version 3.5: Per-component CPACK_RPM_<component>_PACKAGE_GROUP variables.
New in version 3.12: The CMAKE_PROJECT_HOMEPAGE_URL variable.
New in version 3.2: Per-component CPACK_RPM_<component>_PACKAGE_DESCRIPTION variables.
May be used to override RPM compression type to be used to build the RPM. For example some Linux distribution now default to lzma or xz compression whereas older cannot use such RPM. Using this one can enforce compression type to be used.
Possible values are:
May be used to enable (1, yes) or disable (0, no) automatic shared libraries dependency detection. Dependencies are added to requires list.
NOTE:
May be used to enable (1, yes) or disable (0, no) automatic listing of shared libraries that are provided by the package. Shared libraries are added to provides list.
NOTE:
Variable enables/disables autoreq and autoprov at the same time. See CPACK_RPM_PACKAGE_AUTOREQ and CPACK_RPM_PACKAGE_AUTOPROV for more details.
NOTE:
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
May be used to set negative RPM dependencies (conflicts). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_CONFLICTS "libxml2")
The conflicting package list of an RPM file could be printed with:
rpm -qp --conflicts file.rpm
RPM spec requires(pre) field.
May be used to set RPM preinstall dependencies (requires(pre)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
RPM spec requires(post) field.
May be used to set RPM postinstall dependencies (requires(post)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_POST "shadow-utils, initscripts")
RPM spec requires(postun) field.
May be used to set RPM postuninstall dependencies (requires(postun)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_POSTUN "shadow-utils, initscripts")
RPM spec requires(preun) field.
May be used to set RPM preuninstall dependencies (requires(preun)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_PREUN "shadow-utils, initscripts")
May be used to set weak RPM dependencies (suggests). If rpmbuild doesn't support the Suggests tag, CPack will emit a warning and ignore this variable. Note that you must enclose the complete requires string between quotes.
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
May be used to set RPM packages that are obsoleted by this one.
If this variable is set to TRUE or ON, the CPack RPM generator 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.
May be used to override the __spec_install_post section within the generated spec file. This affects the install step during package creation, not during package installation. For adding operations to be performed during package installation, use CPACK_RPM_POST_INSTALL_SCRIPT_FILE instead.
May be used to add any %define lines to the generated spec file. An example of its use is to prevent stripping of executables (but note that this may also disable other default post install processing):
set(CPACK_RPM_SPEC_MORE_DEFINE "%define __spec_install_post /bin/true")
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
May be set by the user in order to specify a USER binary spec file to be used by the CPack RPM generator instead of generating the file. The specified file will be processed by configure_file( @ONLY).
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.
May be used to embed a pre installation/uninstallation/transaction script in the spec file. The referred script file (or both) will be read and directly put after the %pre or %preun section If CPACK_RPM_COMPONENT_INSTALL is set to ON the install/uninstall/transaction script for each component can be overridden with CPACK_RPM_<COMPONENT>_PRE_INSTALL_SCRIPT_FILE, CPACK_RPM_<COMPONENT>_PRE_UNINSTALL_SCRIPT_FILE, and CPACK_RPM_<COMPONENT>_PRE_TRANS_SCRIPT_FILE One may verify which scriptlet has been included with:
rpm -qp --scripts package.rpm
New in version 3.18: The CPACK_RPM_PRE_TRANS_SCRIPT_FILE variable.
May be used to embed a post installation/uninstallation/transaction script in the spec file. The referred script file (or both) will be read and directly put after the %post or %postun section. If CPACK_RPM_COMPONENT_INSTALL is set to ON the install/uninstall/transaction script for each component can be overridden with CPACK_RPM_<COMPONENT>_POST_INSTALL_SCRIPT_FILE, CPACK_RPM_<COMPONENT>_POST_UNINSTALL_SCRIPT_FILE, and CPACK_RPM_<COMPONENT>_POST_TRANS_SCRIPT_FILE One may verify which scriptlet has been included with:
rpm -qp --scripts package.rpm
New in version 3.18: The CPACK_RPM_POST_TRANS_SCRIPT_FILE variable.
May be used to explicitly specify %(<directive>) file line in the spec file. Like %config(noreplace) or any other directive that be found in the %files section. Since the CPack RPM generator is generating the list of files (and directories) the user specified files of the CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed from the generated list. If referring to directories do not add a trailing slash.
New in version 3.8: You can have multiple directives per line, as in %attr(600,root,root) %config(noreplace).
May be used to embed a changelog in the spec file. The referred file will be read and directly put after the %changelog section.
May be used to exclude path (directories or files) from the auto-generated list of paths discovered by CPack RPM. The default 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 the CPack RPM generator 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.
New in version 3.10: Added /usr/share/aclocal to the default list of excludes.
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.
Packages relocation paths list.
May be used to specify more than one relocation path per relocatable RPM. Variable contains a list of relocation paths that if relative are prefixed by the value of CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX or by the value of CPACK_PACKAGING_INSTALL_PREFIX if the component version is not provided. Variable is not component based as its content can be used to set a different path prefix for e.g. binary dir and documentation dir at the same time. Only prefixes that are required by a certain component are added to that component - component must contain at least one file/directory/symbolic link with CPACK_RPM_RELOCATION_PATHS prefix for a certain relocation path to be added. Package will not contain any relocation paths if there are no files/directories/symbolic links on any of the provided prefix locations. Packages that either do not contain any relocation paths or contain files/directories/symbolic links that are outside relocation paths print out an AUTHOR_WARNING that RPM will be partially relocatable.
Per component relocation path install prefix.
May be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for relocatable RPM packages.
Removal of default install prefix from relocation paths list.
May be used to remove CPACK_PACKAGING_INSTALL_PREFIX and CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX from relocatable RPM prefix paths.
May be used to set additional man dirs that could potentially be compressed by brp-compress RPM macro. Variable content must be a list of regular expressions that point to directories containing man files or to man files directly. Note that in order to compress man pages a path must also be present in brp-compress RPM script and that brp-compress script must be added to RPM configuration by the operating system.
Regular expressions that are added by default were taken from brp-compress RPM macro:
default user ownership of RPM content
Value should be user name and not UID. Note that <compName> must be in upper-case.
default group ownership of RPM content
Value should be group name and not GID. Note that <compName> must be in upper-case.
default permissions used for packaged files
Accepted values are lists with PERMISSIONS. Valid permissions are:
Note that <compName> must be in upper-case.
default permissions used for packaged directories
Accepted values are lists with PERMISSIONS. Valid permissions are the same as for CPACK_RPM_DEFAULT_FILE_PERMISSIONS. Note that <compName> must be in upper-case.
force execute permissions on programs and shared libraries
Force set owner, group and world execute permissions on programs and shared libraries. This can be used for creating valid rpm packages on systems such as Debian where shared libraries do not have execute permissions set.
NOTE:
New in version 3.3.
The CPack RPM generator supports packaging of symbolic links:
execute_process(COMMAND ${CMAKE_COMMAND}
-E create_symlink <relative_path_location> <symlink_name>)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/<symlink_name>
DESTINATION <symlink_location> COMPONENT libraries)
Symbolic links will be optimized (paths will be shortened if possible) before being added to the package or if multiple relocation paths are detected, a post install symlink relocation script will be generated.
Symbolic links may point to locations that are not packaged by the same package (either a different component or even not packaged at all) but those locations will be treated as if they were a part of the package while determining if symlink should be either created or present in a post install script - depending on relocation paths.
Changed in version 3.6: Symbolic links that point to locations outside packaging path produce a warning and are treated as non relocatable permanent symbolic links. Previous versions of CMake produced an error in this case.
Currently there are a few limitations though:
New in version 3.7.
Debuginfo packages contain debug symbols and sources for debugging packaged binaries.
Debuginfo RPM packaging has its own set of variables:
NOTE:
Additionally, if CPACK_STRIP_FILES is set, the files will be stripped before they get to the RPM generator, so will not contain debug symbols and a debuginfo package will not get built. Do not use with CPACK_STRIP_FILES.
NOTE:
NOTE:
NOTE:
NOTE:
Listed paths are owned by other RPM packages and should therefore not be deleted on debuginfo package uninstallation.
Create a single debuginfo package even if components packaging is set.
When this variable is enabled it produces a single debuginfo package even if component packaging is enabled.
When using this feature in combination with components packaging and there is more than one component this variable requires CPACK_RPM_MAIN_COMPONENT to be set.
NOTE:
Debuginfo package file name.
Alternatively provided debuginfo package file name must end with .rpm suffix and should differ from file names of other generated packages.
Variable may contain @cpack_component@ placeholder which will be replaced by component name if component packaging is enabled otherwise it deletes the placeholder.
Setting the variable to RPM-DEFAULT may be used to explicitly set filename generation to default.
NOTE:
New in version 3.7.
SRPM packaging is enabled by setting CPACK_RPM_PACKAGE_SOURCES variable while usually using CPACK_INSTALLED_DIRECTORIES variable to provide directory containing CMakeLists.txt and source files.
For CMake projects SRPM package would be produced by executing:
cpack -G RPM --config ./CPackSourceConfig.cmake
NOTE:
Once the SRPM package is generated it can be used to generate binary packages by creating a directory structure for rpm generation and executing rpmbuild tool:
mkdir -p build_dir/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
rpmbuild --define "_topdir <path_to_build_dir>" --rebuild <SRPM_file_name>
Generated packages will be located in build_dir/RPMS directory or its sub directories.
NOTE:
Source RPM packaging has its own set of variables:
NOTE:
May be used to set source RPM build dependencies (BuildRequires). Note that you must enclose the complete build requirements string between quotes, for example:
set(CPACK_RPM_BUILDREQUIRES "python >= 2.5.0, cmake >= 2.8")
May be used to keep the dependency generator from scanning specific files or directories for dependencies. Note that you can use a regular expression that matches all of the directories or files, for example:
set(CPACK_RPM_REQUIRES_EXCLUDE_FROM "bin/libqsqloci.*\\.so.*")
CPack WIX generator specific options
New in version 3.7: Support CPACK_COMPONENT_<compName>_DISABLED variable.
The following variables are specific to the installers built on Windows using WiX.
Will be automatically generated unless explicitly provided.
It should be explicitly set to a constant generated globally unique identifier (GUID) to allow your installers to replace 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)
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.
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. The expected encoding of the .txt file is UTF-8.
With CPACK_WIX_LICENSE_RTF you can override the license file used by the WIX Generator in case CPACK_RESOURCE_FILE_LICENSE is in an unsupported format or the .txt -> .rtf conversion does not work as expected.
If set, this icon is used in place of the default icon.
The default is WixUI_InstallDir in case no CPack components have been defined and WixUI_FeatureTree otherwise.
If set, this image will replace the default banner image.
This image must be 493 by 58 pixels.
If this variable is set, the installer will replace the default dialog image.
This image must be 493 by 312 pixels.
If this variable is not set, it will be initialized with CPACK_PACKAGE_NAME
New in version 3.16: If this variable is set to ., then application shortcuts will be created directly in the start menu and the uninstaller shortcut will be omitted.
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: https://wixtoolset.org//documentation/manual/v3/wixui/wixui_localization.html
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.
New in version 3.5: Support listing multiple patch files.
This optional variable can be used to specify an XML file that the WIX generator will use to inject fragments into its generated source files.
Patch files understood by the CPack WIX generator roughly follow this RELAX NG compact schema:
start = CPackWiXPatch
CPackWiXPatch = element CPackWiXPatch { CPackWiXFragment* }
CPackWiXFragment = element CPackWiXFragment
{
attribute Id { string },
fragmentContent*
}
fragmentContent = element * - CPackWiXFragment
{
(attribute * { text } | text | fragmentContent)*
}
Currently fragments can be injected into most Component, File, Directory and Feature elements.
New in version 3.3: The following additional special Ids can be used:
New in version 3.7: Support patching arbitrary <Feature> elements.
New in version 3.9: Allow setting additional attributes.
The following example illustrates how this works.
Given that the WIX generator creates the following XML element:
<Component Id="CM_CP_applications.bin.my_libapp.exe" Guid="*"/>
The following XML patch file may be used to inject an Environment element into it:
<CPackWiXPatch>
<CPackWiXFragment Id="CM_CP_applications.bin.my_libapp.exe">
<Environment Id="MyEnvironment" Action="set"
Name="MyVariableName" Value="MyVariableValue"/>
</CPackWiXFragment> </CPackWiXPatch>
This variable provides an optional list of extra WiX source files (.wxs) that should be compiled and linked. The full path to source files is required.
This variable provides an optional list of extra WiX object (.wixobj) and/or WiX library (.wixlib) files. The full path to objects and libraries is required.
Use it at your own risk. Future versions of CPack may generate flags which may be in conflict with your own flags.
<TOOL> can be either LIGHT or CANDLE.
Assuming you also install a CMake configuration file this will allow other CMake projects to find your package with the find_package() command.
This variable can be used to provide a value for the Windows Installer property <PROPERTY>
The following list contains some example properties that can be used to customize information under "Programs and Features" (also known as "Add or Remove Programs")
Sets the name of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DISPLAY_NAME for components.
Sets the description of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DESCRIPTION for components.
If this variable is set to true, the default install location of the generated package will be CPACK_PACKAGE_INSTALL_DIRECTORY directly. The install location will not be located relatively below ProgramFiles or ProgramFiles64.
NOTE:
It is therefore possible that the installer e.g. might try to install onto a drive that is unavailable or unintended or a path that does not follow the localization or convention of the system on which the installation is performed.
This variable allows specification of a custom root folder ID. The generator specific <64> token can be used for folder IDs that come in 32-bit and 64-bit variants. In 32-bit builds the token will expand empty while in 64-bit builds it will expand to 64.
When unset generated installers will default installing to ProgramFiles<64>Folder.
When unspecified CPack will try to locate a WiX Toolset installation via the WIX environment variable instead.
This variable provides a list of custom namespace declarations that are necessary for using WiX extensions. Each declaration should be in the form name=url, where name is the plain namespace without the usual xmlns: prefix and url is an unquoted namespace url. A list of commonly known WiX schemata can be found here: https://wixtoolset.org/documentation/manual/v3/xsd/
If this variable is set then the inclusion of WixUIExtensions is skipped, i.e. the -ext "WixUIExtension" command line is not included during the execution of the WiX light tool.
This variable can be optionally set to specify the target architecture of the installer. May for example be set to x64 or arm64.
When unspecified, CPack will default to x64 or x86.
2000-2022 Kitware, Inc. and Contributors
| November 30, 2022 | 3.25.1 |