CPack Package Generators

Overall usage (common to all generators)

Information about CPACK_xxx variables used for CPack configuration
may be found there: CPackConfiguration

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

TBZ2

TZ

Tar UNIX compress compressed packages.

DragNDrop (OSX only)

Mac OSX Drag and Drop installer. Similar to the Bundle generator except that this generator doesn't create the bundle for you.
To make a bundle, use the MACOSX_BUNDLE parameter in add_executable(), and to specify icon, plist, and other bundle properties, just set them with a set_target_properties() call. It also supports creating a folder that contains multiple bundles and other files.

PackageMaker (OSX only)

Some of the variables that you can use to customize the Package Maker generated package:

Variable Name

Description

Default value

CPACK_PREFLIGHT_SCRIPT

This script is launched just after the user clicked on the "Install" button.

-

CPACK_POSTFLIGHT_SCRIPT

This script is launched after the postinstall / postupgrade script or when the package has been

-

CPACK_POSTUPGRADE_SCRIPT

This script is launched after the files in the package have been installed. (Isn't an option for a postinstall script missing? According to Apple documentation, postinstall is executed the first time a package is installed and postupgrade all subsequent times)

-

CPACK_OSX_PACKAGE_VERSION

Set to the minimum OS X version you support. Choices are currently 10.3, 10.4 and 10.5

10.3, unless you specified features that require a higher OS X version (CPACK_DOWNLOAD_SITE, CPACK_COMPONENTS_ALL)

This is a useful site that describes where the scripts get executed and what the arguments to the scripts are. See section "What about scripts?". http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html . In summary the arguments correspond to $0 Script path, $1 Package path, $2 Target location, and $3 Target Volume.

OSXX11 (OSX only)

Mac OSX X11 Bundle. Requires hdiutil for creating the package.

Bundle (OSX only)

Overview

The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.

Important Note: Do not use the MACOSX_BUNDLE property on executables that will be packaged using the bundle-generator! Specifying MACOSX_BUNDLE creates a separate bundle for each individual executable at build-time; the structure of these bundles becomes redundant when the bundle generator consolidates multiple executables into a single bundle.

CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.

The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.

CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:

Starts X11 (required by GTK).

Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.

Updates PATH so the "main" application can easily run "child" binaries included in the bundle.

Sets-up some temporary files and environment variables required by (in this case) GTK.

Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).

CygwinBinary (Cygwin only)

CygwinSource (Cygwin only)

DEB (UNIX only)

Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in CMakeUserUseDebian (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.

Note:
Only binary package are supported. source package do not really make sense since build process is cmake driven.

Here are the variables needed for a binary package:

control file (aka DEBIAN/control) for binary package

Specific variables are needed to generate the control file for debian package. This file is created automatically using the following variables, some of which are mandatory and some are optional.
See also: [1]

package name

debian policy enforce lower case for package name

Package: (mandatory)

if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)

version

Version: (mandatory)

if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION

arch

Architecture: (mandatory)

if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386

Notes:

should be set via: dpkg --print-architecture

There is no such thing as i686 architecture on debian, you should use i386 instead

this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which
may be used by CPack RPM generator.

CPack RPM generators specific variables

CPack RPM specific variables are used to generate an RPM spec file
which will be processed by the rpmbuild tool.
A specific variable may be

optional, the variable may or may not be set and its value is not needed for building a valid spec file.

mandatory, the variable must be set because we need a value for building a valid spec file.

mandatory with default value, the variable must be set but a default value is provided.

mandatory, the variable must be set and no default value is provided.

Here is the list of CPack RPM specific variables (some variable are not yet supported because there are some patches pending):

Variable Name

Description

Default value

CPACK_RPM_PACKAGE_SUMMARY

The RPM package summary

CPACK_PACKAGE_DESCRIPTION_SUMMARY

CPACK_RPM_PACKAGE_NAME

The RPM package name

CPACK_PACKAGE_NAME

CPACK_RPM_PACKAGE_VERSION

The RPM package version

CPACK_PACKAGE_VERSION

CPACK_RPM_PACKAGE_ARCHITECTURE

The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package.

-

CPACK_RPM_PACKAGE_RELEASE

The RPM package release. 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.

1

CPACK_RPM_PACKAGE_LICENSE

The RPM package license policy.

"unknown"

CPACK_RPM_PACKAGE_GROUP

The RPM package group (see /usr/share/doc/rpm-*/GROUPS )

"unknown"

CPACK_RPM_PACKAGE_VENDOR

The RPM package vendor

CPACK_PACKAGE_VENDOR if set or "unknown" if not set

CPACK_RPM_PACKAGE_DESCRIPTION

The RPM package description

The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set

CPACK_RPM_PACKAGE_REQUIRES

May be used to set RPM dependencies. see [RPM dependencies specification]) for precise syntax. 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")

-

CPACK_RPM_SPEC_INSTALL_POST

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 (see [Bug7435])

-

CPACK_RPM_SPEC_MORE_DEFINE

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

-

CPACK_RPM_USER_BINARY_SPECFILE

May be used to specify a user provided spec file instead of generating one. This is an feature which currently needs a patch see [Bug9679]

-

CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE

May be used to generate a template for a user provided spec file. This is an feature which currently needs a patch see [Bug9679]

-

CPACK_RPM_<POST/PRE>_<UN>INSTALL_SCRIPT_FILE

The content of the specified files will be embedded in the RPM spec file in the appropriate sections. This is an feature which currently needs a patch see [Bug8988]

-

CPACK_RPM_PACKAGE_DEBUG

May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

CPack RPM Historical Notes

CPackRPM included along with CMake 2.8.1 is provided many new features and bug fixes
--Erk 14:33, 20 February 2010 (UTC)

The binary CPackRPM generator should now work for many RPM based distribution and rpmbuild version.
Erk was granted CVS commit right for CPackRPM and he's maintaining and improving it as long
as spare time is available --Erk 14:30, 20 February 2010 (UTC)

The built-in CPack support for RPM is based on the work done in the RPM module.
The built-in CPack 2.6.x support for RPM is for binary package only but
the binary RPM package built faster using CPack than CMakeUserUseRPMTools module.
This restriction is due to both a lack of time of the implementor (--Erk 05:01, 7 September 2007 (EDT))
and some design issues in current CPack .