CPACK-GENERATORS(7)

📦
version 4.4.5 · 21 versions
, in arch rolling

🌸 CPack Generators, bestie 🌸

Okay so this is the cpack-generators page — the CPack Generator Reference 💅 like, the whole master list of every generator CPack can ship your stuff with. Grab a strawberry drink 🍓, we're going through it together, and yes we're keeping every single detail because that's just how I roll.

✨ GENERATORS ✨

🎀 CPack AppImage Generator

Added in version 4.2.

So the CPack AppImage generator (over at <https://appimage.org>, iykyk) lets you bundle your whole app into the AppImage format. It uses appimagetool to pack everything up, and patchelf to set your app's RPATH to a relative path — and that path is based on where the AppImage is gonna get mounted. Clever, right? 🧚

Real talk though: appimagetool does not scan for library dependencies. It literally only packs the installed content and checks whether the .desktop file you gave it was properly created. That's it. For best compatibility, it's recommended that you build on an old LTS distribution and include any dependencies in the generated file. 🫶

The snippet below can be added to your CMakeLists.txt. Just swap my_application_target for your actual application target. This example does a best effort to identify the libraries your application links to and copy them to the install location:

install(CODE [[
    file(GET_RUNTIME_DEPENDENCIES
        EXECUTABLES $<TARGET_FILE:my_application_target>
        RESOLVED_DEPENDENCIES_VAR resolved_deps
    )

    foreach(dep ${resolved_deps})
        # copy the symlink
        file(COPY ${dep} DESTINATION ${CMAKE_INSTALL_PREFIX}/lib)

        # Resolve the real path of the dependency (follows symlinks)
        file(REAL_PATH ${dep} resolved_dep_path)

        # Copy the resolved file to the destination
        file(COPY ${resolved_dep_path} DESTINATION ${CMAKE_INSTALL_PREFIX}/lib)
    endforeach()
]])

The CPack AppImage generator will generate a default AppRun (check <https://docs.appimage.org/introduction/software-overview.html#apprun>) based on the .desktop entry you provide. OR — plot twist — if a custom AppRun is installed, like via the install() command, then that one gets used instead of the generated one. Main character energy from your custom file, honestly. 👑

For Qt-based projects: it is recommended to call qt_generate_deploy_app_script() or qt_generate_deploy_qml_app_script() and install the files generated by the script. That's what installs the Qt plugins. ✨

You must also set CPACK_PACKAGE_ICON with the same value listed in the Desktop file. No cap, it has to match.

🦋 Variables Specific to CPack AppImage Generator

  • CPACK_APPIMAGE_TOOL_EXECUTABLE — Name of the appimagetool executable. If you don't give it as an absolute path, logic based on find_program() will be used internally with this value to find the executable.
    • Default: appimagetool
  • CPACK_APPIMAGE_PATCHELF_EXECUTABLE — Name of the patchelf executable. If you don't give it as an absolute path, logic based on find_program() will be used internally with this value to find the executable.
    • Default: patchelf
  • CPACK_APPIMAGE_DESKTOP_FILE — Name of the freedesktop.org desktop file to be installed. If not specified, the first .desktop file found in the list of files to be installed will be used. There must be a valid .desktop file for the package, and it must include an Icon entry that matches CPACK_PACKAGE_ICON without the file extension. The actual installed location of the icon should follow the freedesktop.org specification.
    • Default: Unset
  • CPACK_APPIMAGE_UPDATE_INFORMATION — Embed the value of this variable as the update information. See the appimagetool source code for the supported values and formats of the --updateinformation option. It is highly recommended to have the zsyncmake tool installed if using zsync update information.
    • Default: Unset
  • CPACK_APPIMAGE_GUESS_UPDATE_INFORMATION — When this variable is true, add the --guess option to the appimagetool invocation. This directs the tool to try to guess appropriate update information based on GitHub or GitLab environment variables.
    • Default: Unset
  • CPACK_APPIMAGE_COMPRESSOR — Override the appimagetool's default type of squashfs compression (zstd). This corresponds to the appimagetool --comp option.
    • Default: Unset
  • CPACK_APPIMAGE_MKSQUASHFS_OPTIONS — List of arguments to pass through to mksquashfs. Each of these will be preceded by --mksquashfs-opt on the appimagetool command line.
    • Default: Unset
  • CPACK_APPIMAGE_NO_APPSTREAM — If set to true, do not check AppStream metadata. This passes the --no-appstream option to appimagetool.
    • Default: Unset
  • CPACK_APPIMAGE_EXCLUDE_FILE — Use the specified file as an exclude file for mksquashfs, in addition to .appimageignore. This uses the --exclude-file option to appimagetool.
    • Default: Unset
  • CPACK_APPIMAGE_RUNTIME_FILE — Specify a runtime file to use instead of letting the appimagetool download a runtime to embed in the generated AppImage.
    • Default: Unset
  • CPACK_APPIMAGE_SIGN — When set to true, sign the generated AppImage with gpg[2]. CPACK_APPIMAGE_SIGN_KEY should also be specified if using this option.
    • Default: Unset
  • CPACK_APPIMAGE_SIGN_KEY — Key ID to use for gpg[2] signatures when signing is enabled with CPACK_APPIMAGE_SIGN.
    • Default: Unset

🌈 CPack Archive Generator

CPack generator for packaging files into an archive — and the archive can have any of these formats. Buckle up bestie, it's a long list but every one of them ate:

  • 7Z — 7zip - (.7z) - LZMA compressed
    • Added in version 3.1.
    • This is an alias for 7Z_LZMA
  • 7Z_BZ2 — 7zip - (.7z) - BZip2 compressed
    • Added in version 4.3.
  • 7Z_DEFLATE — 7zip - (.7z) - Deflate compressed
    • Added in version 4.3.
  • 7Z_LZMA — 7zip - (.7z) - LZMA compressed
    • Added in version 4.3.
  • 7Z_LZMA2 — 7zip - (.7z) - LZMA2 compressed
    • Added in version 4.3.
  • 7Z_PPMD — 7zip - (.7z) - PPMd compressed
    • Added in version 4.3.
  • 7Z_STORE — 7zip - (.7z) - no compression is used
    • Added in version 4.3.
  • 7Z_ZSTD — 7zip - (.7z) - Zstandard compressed
    • Added in version 4.3.
  • TAR (.tar) - no compression is used
    • Added in version 4.0.
  • TBZ2 (.tar.bz2) - BZip2 compressed
  • TGZ (.tar.gz) - Deflate compressed
  • TXZ (.tar.xz) - LZMA2 compressed
    • Added in version 3.1.
  • TZ (.tar.Z) - LZW compressed
  • TZST (.tar.zst) - Zstandard compressed
    • Added in version 3.16.
  • ZIP (.zip) - Deflate compressed
    • This is an alias for ZIP_DEFLATE
  • ZIP_BZ2 (.zip) - BZip2 compressed
    • Added in version 4.3.
  • ZIP_DEFLATE (.zip) - Deflate compressed
    • Added in version 4.3.
  • ZIP_LZMA (.zip) - LZMA compressed
    • Added in version 4.3.
  • ZIP_LZMA2 (.zip) - LZMA2 compressed
    • Added in version 4.3.
  • ZIP_STORE (.zip) - no compression is used
    • Added in version 4.3.
  • ZIP_ZSTD (.zip) - Zstandard compressed
    • Added in version 4.3.

Okay so when this generator is called from CPackSourceConfig.cmake (or through the package_source target), the generated archive will contain all files in the project directory, except those specified in CPACK_SOURCE_IGNORE_FILES. Here's 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)

And 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 (plus the deprecated commands install_files(), install_programs(), and install_targets()). 💖

🌸 Variables specific to CPack Archive generator

  • CPACK_ARCHIVE_FILE_NAME
    • Added in version 3.9.
    • Archive name for component-based packages, without extension.
    • Default: CPACK_PACKAGE_FILE_NAME
    • The extension is appended automatically.
    • If CPACK_COMPONENTS_GROUPING is set to ALL_COMPONENTS_IN_ONE, this will be the name of the one output archive.
    • Changed in version 4.0: this variable also works for non-component packages.
  • CPACK_ARCHIVE_<component>_FILE_NAME
    • Added in version 3.9.
    • Component archive name without extension.
    • Default: <CPACK_ARCHIVE_FILE_NAME>-<component>, with spaces replaced by -.
    • The extension is appended automatically. Note that <component> is all uppercase in the variable name. Don't forget, bestie 🫶
  • CPACK_ARCHIVE_FILE_EXTENSION
    • Added in version 3.25.
    • Archive file extension.
    • Default: default values are given in the list above.
  • CPACK_ARCHIVE_COMPONENT_INSTALL
    • Enable component packaging.
    • Default: OFF
    • If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.
  • CPACK_ARCHIVE_UID
    • Set the UID of entries contained in the archive. Specify -1 to use the UID of the current user.
    • Default: 0 (see policy CMP0206)
  • CPACK_ARCHIVE_GID
    • Set the GID of entries contained in the archive. Specify -1 to use the GID of the current user.
    • Default: 0 (see policy CMP0206)

💜 Variables used by CPack Archive generator

These variables are used by the Archive generator, but they're also available to CPack generators which are essentially archives at their core. Those include:

  • CPack Cygwin Generator
  • CPack FreeBSD Generator
  • CPACK_ARCHIVE_THREADS
    • Added in version 3.18.
    • The number of threads to use when performing the compression.
    • Default: value of CPACK_THREADS
    • If set to 0, the number of available cores on the machine will be used instead. Note that not all compression modes support threading in all environments. 💀 so like, don't assume, okay?

Also, real quick — Added in version 3.21: the official CMake binaries you grab from cmake.org now ship with a liblzma that actually supports parallel compression. Older versions? Did not. 💀

CPACK_ARCHIVE_COMPRESSION_LEVEL

Added in version 4.3.

The compression level to use when compressing the archive 🗜️✨

  • Default: the value of CPACK_COMPRESSION_LEVEL

So like, the compression level should sit between 0 and 9.

For the Zstandard-based algorithm you can set it between 0 and 19 — except for the ZIP_ZSTD mode, which is not invited to that party 🙈.

The value 0 means "use the default compression level." That default gets picked automatically by the archive library backend and is not directly set by CMake itself, so it can vary between archive formats, platforms, etc. Basically it's giving "whatever the backend feels like" energy.

CPACK_ARCHIVE_ENCODING

Added in version 4.4.

Specifies the pathname character encoding used in package archives 🔤💖

  • Default: UTF-8

Wanna know which encoding names are supported? Go peek at the cmake -E tar tool's --cmake-tar-encoding flag — that's the whole list, bestie.

In CMake 4.3 and below, the OEM encoding (current locale) was always used. No choices, no vibes, just locale. 😭

🎀 CPack Bundle Generator

CPack Bundle generator (macOS) specific options — yes, we're in Apple territory now 🍎

Variables specific to CPack Bundle generator

Installers built on macOS with the Bundle generator use all the DragNDrop stuff we already covered (the CPACK_DMG_xxx variables) plus these Bundle-specific parameters, aka the CPACK_BUNDLE_xxx crew 🫶

CPACK_BUNDLE_NAME

The name of the generated bundle. This is the name that shows up in the macOS Finder as the bundle name. Required.

CPACK_BUNDLE_PLIST

Path to a macOS Property List (.plist) file that'll be used for the generated bundle. This assumes the caller has already generated or specified their own Info.plist file — so like, do your homework first 📝. Required.

CPACK_BUNDLE_ICON

Path to a macOS icon file that'll be used as the icon for the generated bundle. This is the icon that appears in the macOS Finder for the bundle, and in the macOS dock when the bundle is opened. Main character icon energy 👑 Required.

CPACK_BUNDLE_STARTUP_COMMAND

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

CPACK_BUNDLE_APPLE_CERT_APP

Added in version 3.2.

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

CPACK_BUNDLE_APPLE_ENTITLEMENTS

Added in version 3.2.

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 — no entitlements, no App Store, sorry bestie 🥲

CPACK_BUNDLE_APPLE_CODESIGN_FILES

Added in version 3.2.

A list of additional files that you want signed. You do not need to list the main application folder or the main executable — they're already handled. You should list any frameworks and plugins that are included in your app bundle 💅

CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER

Added in version 3.3.

Additional parameter that will be passed to codesign.

  • Default value: --deep -f

CPACK_COMMAND_CODESIGN

Added in version 3.2.

Path to the codesign(1) command used to sign applications with an Apple cert. This variable lets you override the automatically detected command, or specify its location if the auto-detection fails to find it 🔍

🌸 CPack Cygwin Generator

Cygwin CPack generator (Cygwin).

Variables affecting the CPack Cygwin generator

  • Added in version 3.18: CPACK_ARCHIVE_THREADS

Variables specific to CPack Cygwin generator

The following variable is specific to installers built 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.

(Yeah, all three of those are literally flagged incomplete in the source. I'm not making it up, I promise 🙈)

🔥 CPack DEB Generator

The built-in (binary) CPack DEB generator (Unix only).

Variables specific to CPack Debian (DEB) generator

The CPack DEB generator can be used to create a DEB package using CPack. It is a CPack generator, so it uses the CPACK_XXX variables that CPack uses. Same family, same rules 💖

The CPack DEB generator should work on any Linux host, but it'll produce a better deb package when the Debian-specific tools dpkg-xxx are usable on the build system. Like, it works either way, but it slays when dpkg is around ✨

The CPack DEB generator has specific features which are controlled by the specific CPACK_DEBIAN_XXX variables.

CPACK_DEBIAN_<COMPONENT>_XXXX variables can be used to get component-specific values. But heads up: <COMPONENT> refers to the grouping name written in upper case. It can be either a component name or a component GROUP name 🫶

Here are some CPack DEB generator wiki resources that are hanging around for historic reasons — they're no longer maintained, but they may still prove useful:

List of CPack DEB generator specific variables — buckle up, there's a lot 👇

CPACK_DEB_COMPONENT_INSTALL

Enables component packaging for CPackDEB.

  • Mandatory: No
  • Default: OFF

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

CPACK_DEBIAN_PACKAGE_NAME / CPACK_DEBIAN_<COMPONENT>_PACKAGE_NAME

Set the Package control field (the variable is automatically transformed to lower case, no cap).

  • Mandatory: Yes
  • Default:
    • CPACK_PACKAGE_NAME for non-component based installations
    • CPACK_DEBIAN_PACKAGE_NAME suffixed with -<COMPONENT> for component-based installations

Added 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

CPACK_DEBIAN_FILE_NAME / CPACK_DEBIAN_<COMPONENT>_FILE_NAME

Added in version 3.6.

Package file name.

  • Mandatory: Yes
  • Default: <CPACK_PACKAGE_FILE_NAME>[-<component>].deb

This may be set to:

  • DEB-DEFAULT — tells CPack to automatically generate the package file name in deb format:
<PackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb

This setting is recommended as the preferred behavior, but for backward compatibility with the CPack DEB generator in CMake prior to version 3.6, it's not the default. Without this, duplicate names may occur. Duplicate files get overwritten and it's up to the packager to set the variables in a way that prevents those errors 😬

  • <file-name>[.deb] — use the given file name.

Changed in version 3.29: The .deb suffix is automatically added if the file name doesn't end in .deb or .ipk. Previously the suffix was required. Glow-up fr fr ✨

  • <file-name>.ipk — Added in version 3.10. Use the given file name. The .ipk suffix is what the OPKG packaging system uses.

CPACK_DEBIAN_PACKAGE_EPOCH

Added in version 3.10.

The Debian package epoch.

  • Mandatory: No
  • Default: None

Optional number that should be incremented when you change versioning schemas or fix mistakes in the version numbers of older packages 🔢

CPACK_DEBIAN_PACKAGE_VERSION

The Debian package version.

  • Mandatory: Yes
  • Default: CPACK_PACKAGE_VERSION

This variable may contain only alphanumerics (A-Za-z0-9) and the characters . + - ~ (full stop, plus, hyphen, tilde) and it should start with a digit. If CPACK_DEBIAN_PACKAGE_RELEASE is not set, then hyphens are not allowed 🚫

Note: for backward compatibility with CMake 3.9 and lower, a failed test of this variable's content is not a hard error when both the CPACK_DEBIAN_PACKAGE_RELEASE and CPACK_DEBIAN_PACKAGE_EPOCH variables are not set. An author warning is reported instead. So like, it yells at you but doesn't actually stop you 😭

CPACK_DEBIAN_PACKAGE_RELEASE

Added in version 3.6.

The Debian package release — the Debian revision number.

  • Mandatory: No
  • Default: None

This is the numbering of the DEB package itself, i.e. the version of the packaging, not the version of the content (that one's CPACK_DEBIAN_PACKAGE_VERSION, don't mix them up bestie 💅). You can change the default value if the previous packaging was buggy and/or you want to put a fancy Linux-distro-specific numbering here.

CPACK_DEBIAN_PACKAGE_ARCHITECTURE / CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE

The Debian package architecture.

  • Mandatory: Yes
  • Default: output of dpkg --print-architecture (or i386 if dpkg is not found)

Added in version 3.6: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_ARCHITECTURE variables.

CPACK_DEBIAN_PACKAGE_DEPENDS / CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS

Sets the Debian dependencies of this package 🧲

  • Mandatory: No
  • Default:
    • An empty string for non-component based installations
    • CPACK_DEBIAN_PACKAGE_DEPENDS for component-based installations

Added in version 3.3: Per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS variables.

Note: if CPACK_DEBIAN_PACKAGE_SHLIBDEPS — or, more specifically, CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS — is set for this component, then the deps it discovers get appended to CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS, not to CPACK_DEBIAN_PACKAGE_DEPENDS. And if CPACK_DEBIAN_<COMPONENT>_PACKAGE_DEPENDS is an empty string, then literally only the automatically discovered deps get set for that component. iykyk 💅

Changed in version 3.31: the variable is always expanded as a list now. Before, it only got expanded if you were using it together with CPACK_DEB_COMPONENT_INSTALL, CPACK_DEBIAN_PACKAGE_SHLIBDEPS or CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS. Which meant that if a component had no shared libraries discovered (like, say, a package made entirely of scripts 🐚) you had to join the list yourself just to get a valid Depends field. annoying, honestly.

Example:

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

🌸 CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS

Added in version 3.6.

Sets inter-component dependencies — but only if you listed them with the CPACK_COMPONENT_<compName>_DEPENDS variables. so it's a whole "you have to opt in" situation 🫶

Mandatory — No

Default — None

🎀 CPACK_DEBIAN_PACKAGE_MAINTAINER

The Debian package maintainer. yes, someone has to take the credit (and the bug reports 😭).

Mandatory — Yes

Default — CPACK_PACKAGE_CONTACT

🦋 CPACK_DEBIAN_PACKAGE_DESCRIPTION

🦋 CPACK_DEBIAN_<COMPONENT>_DESCRIPTION

The Debian package description. the little blurb that sells your package, bestie ✨

Mandatory — Yes

Default — in this exact order, first one that hits:

  • CPACK_DEBIAN_<COMPONENT>_DESCRIPTION (component based installers only) if set, or CPACK_DEBIAN_PACKAGE_DESCRIPTION if set, or
  • CPACK_COMPONENT_<compName>_DESCRIPTION (component based installers only) if set, or CPACK_PACKAGE_DESCRIPTION if set, or
  • the content of the file specified in CPACK_PACKAGE_DESCRIPTION_FILE if set

And if after all that the description is still not set, then CPACK_PACKAGE_DESCRIPTION_SUMMARY is going to be used if it's set. Otherwise? CPACK_PACKAGE_DESCRIPTION_SUMMARY gets added as the first line of the description, as defined in the Debian Policy Manual (https://www.debian.org/doc/debian-policy/ch-controlfields.html#description).

Added in version 3.3: per-component CPACK_COMPONENT_<compName>_DESCRIPTION variables.

Added in version 3.16: per-component CPACK_DEBIAN_<COMPONENT>_DESCRIPTION variables.

Added in version 3.16: the CPACK_PACKAGE_DESCRIPTION_FILE variable.

🌈 CPACK_DEBIAN_PACKAGE_SECTION

🌈 CPACK_DEBIAN_<COMPONENT>_PACKAGE_SECTION

Sets the Section control field, e.g. admin, devel, doc, ... you know, the classic categories 🗂️

Mandatory — Yes

Default — devel

Added 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

⭐ CPACK_DEBIAN_ARCHIVE_TYPE

Added in version 3.7.

Deprecated since version 3.14.

The archive format used for creating the Debian package.

Mandatory — Yes

Default — gnutar

Possible value is: gnutar — that's it, that's the whole list 🎯

Note: this variable used to default to the paxr value, but dpkg has never supported that tar format. for backwards compatibility the paxr value gets mapped to gnutar and a deprecation message gets emitted. so like, it works, but it's gonna side-eye you about it 🙈

🔥 CPACK_DEBIAN_COMPRESSION_TYPE

Added in version 3.1.

The compression used for creating the Debian package.

Mandatory — Yes

Default — gzip

Possible values are, and yes I'm listing every single one 💅

  • lzma — Lempel-Ziv-Markov chain algorithm
  • xz — XZ Utils LZMA2 (Lempel-Ziv-Markov chain algorithm, version 2) compression
  • bzip2 — bzip2 Burrows-Wheeler algorithm
  • gzip — GNU Gzip Deflate compression
  • zstd — Added in version 3.22. Zstandard compression

🧚 CPACK_DEBIAN_COMPRESSION_LEVEL

Added in version 4.3.

The compression level used for creating the Debian package. the fine-tuning knob, the "how hard should we squeeze this" dial 🎛️

Mandatory — No

Default — the value of CPACK_COMPRESSION_LEVEL

This variable lets you fine-tune the compression ratio and the speed for the Debian package archive. It controls the numeric compression level passed to the compressor defined by CPACK_DEBIAN_COMPRESSION_TYPE. If CPACK_DEBIAN_COMPRESSION_LEVEL is not set, or is set to 0, the default value gets used. simple as that ✨

The valid range and how it's interpreted depend on the compression type you picked:

  • gzip — level 1-9
  • bzip2 — level 1-9
  • xz — level 1-9
  • lzma — level 1-9
  • zstd — level 1-19

Example usage:

set(CPACK_DEBIAN_COMPRESSION_TYPE "xz")
set(CPACK_DEBIAN_COMPRESSION_LEVEL 9)

include(CPack)

💜 CPACK_DEBIAN_PACKAGE_PRIORITY

💜 CPACK_DEBIAN_<COMPONENT>_PACKAGE_PRIORITY

Sets the Priority control field, e.g. required, important, standard, optional, extra. it's giving "how much does your system need this" energy 👑

Mandatory — Yes

Default — optional

Added 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

🌸 CPACK_DEBIAN_PACKAGE_HOMEPAGE

The URL of the web site for this package — preferably (when applicable) the site from which the original source can be obtained, plus any additional upstream documentation or info that might live there. basically: where do people go to learn more about your masterpiece 🏠

Mandatory — No

Default — CMAKE_PROJECT_HOMEPAGE_URL

Added in version 3.12: the CMAKE_PROJECT_HOMEPAGE_URL variable.

Note: the content of this field is a plain simple URL with no surrounding characters like <>. no angle brackets, no cute decorations, just the URL. periodt 💅

🦋 CPACK_DEBIAN_PACKAGE_SHLIBDEPS

🦋 CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS

May be set to ON in order to use dpkg-shlibdeps to generate a better package dependency list. like, actual real deps, discovered for you 🔍✨

Mandatory — No

Default —

  • CPACK_DEBIAN_PACKAGE_SHLIBDEPS if set, or
  • OFF
Note: you may need to set CMAKE_INSTALL_RPATH to an appropriate value if you use this feature, because if you don't, dpkg-shlibdeps may fail to find your own shared libs. no cap, it will just give up 😭 See https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling
Note: you can also set CPACK_DEBIAN_PACKAGE_SHLIBDEPS_PRIVATE_DIRS to an appropriate value if you use this feature, in order to please dpkg-shlibdeps. however — and this is important — you should only do this for private shared libraries that could not get resolved otherwise. don't be out here spoiling it 🙈

Added in version 3.3: per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_SHLIBDEPS variables.

Added in version 3.6: correct handling of $ORIGIN in CMAKE_INSTALL_RPATH.

🎀 CPACK_DEBIAN_PACKAGE_SHLIBDEPS_PRIVATE_DIRS

Added in version 3.20.

May be set to a list of directories that will be given to dpkg-shlibdeps via its -l option. these get searched by dpkg-shlibdeps in order to find private shared library dependencies 🕵️‍♀️

Mandatory — No

Default — None

Note: you should prefer to set CMAKE_INSTALL_RPATH to an appropriate value if you use dpkg-shlibdeps. The current option is really only needed for private shared library dependencies. like, it's the last resort, not the main character 👑

</br>

🫶 CPACK_DEBIAN_PACKAGE_DEBUG

May be set when invoking cpack in order to trace debug information during the CPack DEB generator run. the "please tell me what's happening" switch 🐛

Mandatory — No

Default — None

⭐ CPACK_DEBIAN_PACKAGE_PREDEPENDS

⭐ CPACK_DEBIAN_<COMPONENT>_PACKAGE_PREDEPENDS

Sets the Pre-Depends field of the Debian package. it's like Depends, except it also forces dpkg to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency. so like, ultra-depends. it goes first, no skipping the line 🚨

Mandatory — No

Default —

  • an empty string for non-component based installations
  • CPACK_DEBIAN_PACKAGE_PREDEPENDS for component-based installations.

Added 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

🌈 CPACK_DEBIAN_PACKAGE_ENHANCES

🌈 CPACK_DEBIAN_<COMPONENT>_PACKAGE_ENHANCES

Sets the Enhances field of the Debian package. Similar to Suggests but it works in the opposite direction: it declares that a package can enhance the functionality of another package. so it's not "I need you", it's "you'd be even better with me in the picture" 💖

Mandatory — No

Default —

  • an empty string for non-component based installations
  • CPACK_DEBIAN_PACKAGE_ENHANCES for component-based installations.

Added 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

💅 CPACK_DEBIAN_PACKAGE_BREAKS

(to be continued…)

  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_BREAKS — sets the Breaks field of the Debian package. Bestie, here's the tea ☕: when a binary package (P) declares that it breaks other packages (B), dpkg will not allow the package (P) which declares Breaks to be unpacked unless the packages that will be broken (B) are deconfigured first. And as long as package (P) is configured, those previously deconfigured packages (B) cannot be reconfigured again. it's giving "you can't sit with us" energy 💅
  • CPACK_DEBIAN_PACKAGE_CONFLICTS
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONFLICTS — sets the Conflicts field of the Debian package. When one binary package declares a conflict with another using a Conflicts field, dpkg will not allow them to be unpacked on the system at the same time. literally cannot coexist, it's giving oil and water 🫠
    • Mandatory — No
    • Default
      • An empty string for non-component based installations
      • CPACK_DEBIAN_PACKAGE_CONFLICTS for component-based installations.
    • Added 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 — this is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the "Unpacked" state but allows both packages to be unpacked at the same time. so like, Breaks is "you're on pause", Conflicts is "we're never in the same room". periodt 💀
  • CPACK_DEBIAN_PACKAGE_PROVIDES
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_PROVIDES — sets the Provides field of the Debian package. A virtual package is one which appears in the Provides control field of another package. main character energy: existing in the Provides field of someone else's whole narrative 👑
  • CPACK_DEBIAN_PACKAGE_REPLACES
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_REPLACES — sets the Replaces field of the Debian package. Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. not just showing up, but taking the whole closet 💅
  • CPACK_DEBIAN_PACKAGE_RECOMMENDS
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_RECOMMENDS — sets the Recommends field of the Debian package. Allows packages to declare a strong, but not absolute, dependency on other packages. like a "you should really come to this party" invite 🎀
  • CPACK_DEBIAN_PACKAGE_SUGGESTS
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SUGGESTS — sets the Suggests field of the Debian package. Allows packages to declare a suggested package install grouping. the softest of soft launches, ngl 🌸
  • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS — added in version 3.6 ✨
    • Mandatory — No
    • Default — OFF
    • Allows to generate shlibs control file automatically. Compatibility is defined by the CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY variable value.
    • Note — libraries are only considered if they have both library name and version set. This can be done by setting SOVERSION property with the set_target_properties() command. no version, no entry, iykyk 🧚
  • CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS_POLICY — added in version 3.6
  • CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA — this variable allows advanced users to add a custom script to the control.tar.gz. Typical usage is for conffiles, postinst, postrm, prerm. the DIY era of your packaging journey 🛠️
    • Mandatory — No
    • Default — None
    • Usage:
set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
    "${CMAKE_CURRENT_SOURCE_DIR}/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm")
  • Added in version 3.4 — per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_EXTRA variables.
  • CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_CONTROL_STRICT_PERMISSION — added in version 3.4
    • This variable indicates if the Debian policy on control files should be strictly followed.
    • Mandatory — No
    • Default — FALSE
    • 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 — the original permissions of the files will be used in the final package unless this variable is set to TRUE. In particular, the scripts should have the proper executable flag prior to the generation of the package. so like, chmod before you ship, bestie 🙈
  • CPACK_DEBIAN_PACKAGE_SOURCE
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_SOURCE — added in version 3.5
    • 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. it's giving "yes i have a parent, here's their name" 🌈
    • Mandatory — No
    • Default
      • An empty string for non-component based installations
      • CPACK_DEBIAN_PACKAGE_SOURCE for component-based installations.
    • See — https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source
    • Note — this value is not interpreted. It is possible to pass an optional revision number of the referenced source package as well.
  • CPACK_DEBIAN_PACKAGE_MULTIARCH
  • CPACK_DEBIAN_<COMPONENT>_PACKAGE_MULTIARCH — sets the Multi-Arch field of the Debian package. Packages can declare in their control file how they should handle situations where packages for different architectures are being installed on the same machine. coexist gracefully, we love to see it 🦋
    • Mandatory — No
    • Default
      • An empty string for non-component based installations
      • CPACK_DEBIAN_PACKAGE_MULTIARCH for component-based installations.
    • Added in version 3.31 — per-component CPACK_DEBIAN_<COMPONENT>_PACKAGE_MULTIARCH variables.
    • See — https://wiki.debian.org/MultiArch/Hints
    • Note — this value is validated. It must be one of the following values: same, foreign, allowed. no custom vibes allowed here ⭐

🐛 Packaging of debug information 🐛

Added in version 3.13.

Dbgsym packages contain debug symbols for debugging packaged binaries.

Dbgsym packaging has its own set of variables:

  • CPACK_DEBIAN_DEBUGINFO_PACKAGE
  • CPACK_DEBIAN_<component>_DEBUGINFO_PACKAGE — enable generation of dbgsym .ddeb package(s). ✨
    • Mandatory — No
    • Default — OFF
Note — setting this also strips the ELF files in the generated non-dbgsym package, which results in debuginfo only being available in the dbgsym package. so the debug info ships in exactly one place, no duplicates 💅
Note — binaries must contain debug symbols before packaging, so use either Debug or RelWithDebInfo for the CMAKE_BUILD_TYPE variable value. 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. for real, don't do it 😭

🪟 Building Debian packages on Windows 🪟

Added 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. that's the whole deal, ngl 😌

🕰️ Reproducible packages 🕰️

Added 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. frozen in time, iconic behavior 🎀

🍩 CPack DragNDrop Generator 🍩

The DragNDrop CPack generator (macOS) creates a DMG image. drag, drop, done — that's the whole personality 🖱️✨

Variables specific to CPack DragNDrop generator 🍎✨

okay so these are the variables that only matter for the DragNDrop installer you build on macOS — like, the fancy drag-to-Applications disk image situation. every single one, coming right up 💅

  • CPACK_DMG_VOLUME_NAME — the volume name of the generated disk image. yes, the name that shows up when you mount it, main character energy fr fr.

Default: CPACK_PACKAGE_FILE_NAME

  • CPACK_DMG_FORMAT — the disk image format. the whole vibe of the file, lowkey.

Default: UDZO

common values are UDRO (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF bzip2-compressed). for the tea on other available formats, go check hdiutil(1) — it has the whole menu 🫶

  • CPACK_DMG_DS_STORE — path to a custom .DS_Store file. bestie, this is the file that specifies the Finder window position/geometry and layout (think hidden toolbars, placement of the icons, all the aesthetic stuff ✨). it has to be generated by the Finder — either manually or through AppleScript — using a normal folder from which the .DS_Store file can then be extracted. no shortcuts, the Finder has to make it 💀
  • CPACK_DMG_DS_STORE_SETUP_SCRIPT — Added in version 3.5.

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 (hidden toolbars, placement of the icons, etc., same deal as above). and here's the slay: by specifying a custom AppleScript there's no need to use CPACK_DMG_DS_STORE, because the .DS_Store that gets generated by the AppleScript will be packaged. iconic 🌸

  • CPACK_DMG_BACKGROUND_IMAGE — Default: (empty)

path to an image file to be used as the background. this file gets copied to .background/background.<ext>, where <ext> is the original image file extension, no cap. the background image is installed into the image before CPACK_DMG_DS_STORE_SETUP_SCRIPT is executed or CPACK_DMG_DS_STORE is installed. by default no background image is set — sorry, blank canvas bestie 🎨

  • CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK — Added in version 3.6.

default behavior is to include a symlink to /Applications in the DMG. set this option to ON to avoid adding the symlink. that's it, that's the whole thing 🦋

  • CPACK_DMG_SLA_USE_RESOURCE_FILE_LICENSE — Added in version 3.23.

Default: OFF

this controls 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: this option was added in response to macOS 12.0's deprecation of the hdiutil udifrez command, to make its use optional. CPack 3.22 and below always use CPACK_RESOURCE_FILE_LICENSE, if set to a non-default value, as the DMG license. so yeah, old behavior was not optional, periodt 😭
  • CPACK_DMG_SLA_DIR — Added in version 3.5.

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. and if both <language>.license.txt and <language>.license.rtf exist, the .txt file will be used — .txt wins, sorry rtf girlies 🙈

Added in version 3.17: RTF support. 🎀

  • CPACK_DMG_SLA_LANGUAGES — Added in version 3.5.

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 the name of the language itself, uppercase, in English (e.g. German). the other lines are translations of the following strings:

  • Agree
  • Disagree
  • Print
  • Save...
  • You agree to the terms of the License Agreement when you click the "Agree" button.
  • Software License Agreement
  • This text cannot be saved. The disk may be full or locked, or the file may be locked.
  • Unable to print. Make sure you have selected a printer.

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

  • CPACK_DMG_<component>_FILE_NAME — Added in version 3.17.

file name when packaging <component> as its own DMG (CPACK_COMPONENTS_GROUPING set to IGNORE).

Default: CPACK_PACKAGE_FILE_NAME-<component>

  • CPACK_DMG_FILESYSTEM — Added in version 3.21.

Default: HFS+

the filesystem format. common values are APFS and HFS+. see man hdiutil for a full list of supported formats — it's giving options 💜

  • CPACK_COMMAND_HDIUTIL — path to the hdiutil(1) command used to operate on disk image files on macOS. this variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it). basically: if the auto-detect is being flaky, you just tell it where the tool lives 🫶
  • CPACK_COMMAND_SETFILE — path to the SetFile(1) command used to set extended attributes on files and directories on macOS. this variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it). same energy 🔥
  • CPACK_COMMAND_REZ — path to the Rez(1) command used to compile resources on macOS. this variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it). yes bestie, another "point it at the tool" variable ✨
  • CPACK_COMMAND_SYNC — Added in version 4.2.

path to the sync(8) command used to force completion of pending disk writes on macOS. this variable can be used to override the automatically detected command (or specify its location if the auto-detection fails to find it). flush those buffers, periodt 💅

CPack External Generator 🌐

Added in version 3.13.

okay so 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 — like, the whole arc, main character energy 👑. but 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. and 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. sharing the load, we love to see it 🫶

Integration with External Packaging Tools 🧚

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. do your thing bestie, the metadata is right there 🎀

alternatively, CPack can invoke an external packaging software through an optional custom CMake script in CPACK_EXTERNAL_PACKAGE_SCRIPT instead. your choice, both are valid 🌸

staging of installation files may also optionally be taken care of by the generator when enabled through the CPACK_EXTERNAL_ENABLE_STAGING variable. optional, but handy, ngl ✨

JSON Format 🦋

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. it's literally the whole picture in one file 💖

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. so how does versioning work? 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. two parts, no more, no less, periodt 💅

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. one format, and it's iconic 🌟

Version 1.0 📦

in addition to the standard format fields, format version 1.0 provides the following fields in the root:

  • components — the components field is an object with component names as the keys and objects describing the components as the values. the component objects have the following fields:
    • name — the name of the component. this is always the same as the key in the components object. consistency king 👑
    • displayName — the value of the DISPLAY_NAME field passed to cpack_add_component().
    • description — the value of the DESCRIPTION field passed to cpack_add_component().
    • isHidden — true if HIDDEN was passed to cpack_add_component(), false if it was not.
    • isRequired — true if REQUIRED was passed to cpack_add_component(), false if it was not.
    • isDisabledByDefault — true if DISABLED was passed to cpack_add_component(), false if it was not.
    • group — only present if GROUP was passed to cpack_add_component(). if so, this field is a string value containing the component's group. it's giving conditional field, love that for us 🍓
  • dependencies — an array of the components this component depends on 💜 it's literally just the values you passed in the DEPENDS argument of cpack_add_component(). No DEPENDS argument? Then it's an empty list, bestie, no cap.
  • installationTypes — an array of the installation types this component is part of 🎀 it holds the values from the INSTALL_TYPES argument you gave to cpack_add_component(). Didn't pass INSTALL_TYPES? Empty list, that's it, periodt.
  • isDownloaded — true if DOWNLOADED was passed to cpack_add_component(), false if it wasn't. Simple as, ngl.
  • archiveFile — the name of the archive file you passed with the ARCHIVE_FILE argument to cpack_add_component() 🦋 if you never passed ARCHIVE_FILE, this is an empty string.

✨ componentGroups ✨

The componentGroups field is an object where the keys are component group names and the values are objects describing those component groups 🔥 those component group objects have these fields:

  • name — the name of the component group. This is always the same as the key in the componentGroups object, like, obviously 💅
  • displayName — the value of the DISPLAY_NAME field that was passed to cpack_add_component_group().
  • description — the value of the DESCRIPTION field that was passed to cpack_add_component_group().
  • parentGroup — only present if PARENT_GROUP was passed to cpack_add_component_group() 👀 if it was, this field is a string containing the component group's parent group.
  • isExpandedByDefault — true if EXPANDED was passed to cpack_add_component_group(), false if it was not.
  • isBold — true if BOLD_TITLE was passed to cpack_add_component_group(), false if it was not 🌸
  • components — an array of the names of components that are direct members of the group (aka the components that have this group as their GROUP). Components of subgroups are not included, so don't come for me 🫶
  • subgroups — an array of the names of component groups that are subgroups of this group (groups that have this group as their PARENT_GROUP).

✨ installationTypes ✨

The installationTypes field is an object where the keys are installation type names and the values are objects describing those installation types ✨ those objects have these fields:

  • name — the name of the installation type. Always identical to the key in the installationTypes object.
  • displayName — the value of the DISPLAY_NAME field passed to cpack_add_install_type().
  • index — the integer index of the installation type in the list 🔢

✨ projects ✨

The projects field is an array of objects describing the CMake projects that make up the CPack project 💖 these values are derived from CPACK_INSTALL_CMAKE_PROJECTS. In most cases this is only, like, a single project. The project objects have these fields:

  • projectName — the project name passed to CPACK_INSTALL_CMAKE_PROJECTS.
  • component — the name of the component or component set which comprises the project.
  • directory — the build directory of the CMake project. This is the directory that contains the cmake_install.cmake script 📁
  • subDirectory — the subdirectory to install the project into, inside the CPack package.

✨ packageName ✨

The package name given in CPACK_PACKAGE_NAME 🎀 only present if this option is set.

✨ packageVersion ✨

The package version given in CPACK_PACKAGE_VERSION. Only present if this option is set.

✨ packageDescriptionFile ✨

The package description file given in CPACK_PACKAGE_DESCRIPTION_FILE 📄 only present if this option is set.

✨ packageDescriptionSummary ✨

The package description summary given in CPACK_PACKAGE_DESCRIPTION_SUMMARY. Only present if this option is set.

✨ buildConfig ✨

The build configuration given to CPack with the cpack -C option ⭐ only present if this option is set.

✨ defaultDirectoryPermissions ✨

The default directory permissions given in CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS. Only present if this option is set.

✨ setDestdir ✨

true if CPACK_SET_DESTDIR is true, false if it is not 💅

✨ packagingInstallPrefix ✨

The install prefix given in CPACK_PACKAGING_INSTALL_PREFIX. Only present if CPACK_SET_DESTDIR is true 👑 (yeah, the presence of this one is tied to CPACK_SET_DESTDIR, not to the prefix variable itself — that's the vibe).

✨ stripFiles ✨

true if CPACK_STRIP_FILES is true, false if it is not.

✨ warnOnAbsoluteInstallDestination ✨

true if CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION is true, false if it is not 🙈

✨ errorOnAbsoluteInstallDestination ✨

true if CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION is true, false if it is not.

🌈 Variables specific to CPack External generator 🌈

CPACK_EXTERNAL_REQUESTED_VERSIONS

This variable is how you request a specific version of the CPack External generator 💜 it's a list of major.minor values, separated by semicolons.

If this variable is set to a non-empty value, the CPack External generator will iterate through each item in the list looking for a version it knows how to generate 🧚 requested versions should be listed in order of descending preference by the client software, because the first matching version in the list is the one that gets generated. First come, first slay.

The generator "knows how to generate" a 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 that version and looks at the next one. And if it doesn't know how to generate any of the requested versions? An error is thrown 💀 not the vibe, but that's the rule.

If this variable is not set, or is empty, the CPack External generator will generate the highest major and minor version 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 🫶

CPACK_EXTERNAL_ENABLE_STAGING

You can set this variable to true to enable optional installation into a temporary staging area, which can then be picked up and packaged by an external packaging tool 🎀 the top level directory CPack uses for the current packaging task lives in CPACK_TOPLEVEL_DIRECTORY. It's automatically cleaned up on each run before packaging is initiated, and it can be used for custom temporary files that the external packaging tool needs. It also contains the staging area CPACK_TEMPORARY_DIRECTORY, which is where CPack does the installation when staging is enabled 🌸

CPACK_EXTERNAL_PACKAGE_SCRIPT

This variable can optionally specify the full path to a CMake script file that gets run as part of the CPack invocation 🦋 it's invoked after the (optional) staging took place and may run an external packaging tool. The script has access to the variables defined by the CPack config file, iykyk.

CPACK_EXTERNAL_BUILT_PACKAGES

Added in version 3.19. ⭐

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 CPACK_PACKAGE_CHECKSUM is set.

🧚 CPack FreeBSD Generator 🧚

Added in version 3.10.

The built in (binary) CPack FreeBSD (pkg) generator (Unix only) 🔥

Variables affecting the CPack FreeBSD (pkg) generator

  • Added in version 3.18: CPACK_ARCHIVE_THREADS 🎀

Variables specific to CPack FreeBSD (pkg) generator

The CPack FreeBSD generator may be used to create pkg(8) packages — and these may be used on FreeBSD, DragonflyBSD, NetBSD, OpenBSD, but also on Linux or OSX, depending on which package-management tools are installed — using CPack 💅

The CPack FreeBSD generator is a CPack generator and uses the CPACK_XXX variables used by CPack. It tries to reuse packaging information that may already be specified for Debian packages for the CPack DEB Generator 👀 it also tries to reuse 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 🌈 (so like, don't expect them to be portable across architectures, bestie — that's not what they're giving).

Okay so the FreeBSD generator does all its package-metadata setting through CPACK_FREEBSD_XXX variables — iconic, love that for us. And here's the thing bestie: unlike the Deb generator, this one does not specially support componentized packages. Like, not even a little. A single package gets created from all the software artifacts created through CMake. one package, no crumbs, periodt 💅

You can set every one of these variables specifically for FreeBSD packaging — either in the CPackConfig file or in CMakeLists.txt — but ngl most of them come with defaults that pull from general settings (like CMAKE_PROJECT_NAME) or from the Debian-specific variables when that actually makes sense (an upstream project's homepage doesn't magically change based on how you package it, bestie 💖). And when there's no Debian info to fall back on but the RPM packaging has it? Then it falls back to the RPM info — like the package license. slay.

🦋 CPACK_FREEBSD_PACKAGE_NAME

Sets the package name — it shows up in the package manifest, and it also affects the output filename. so it's kind of booked and busy.

  • Mandatory: Yes
  • Default:
    • CPACK_PACKAGE_NAME (this is always set by CPack itself, based on CMAKE_PROJECT_NAME).

🌸 CPACK_FREEBSD_PACKAGE_COMMENT

Sets the package comment. This is the short description that pkg(8) shows off in the standard pkg info output. it's giving "one-line elevator pitch".

  • Mandatory: Yes
  • Default:
    • CPACK_PACKAGE_DESCRIPTION_SUMMARY (this is always set by CPack itself, if nothing else sets it explicitly).

🎀 CPACK_FREEBSD_PACKAGE_DESCRIPTION

Sets the package description — the long one, the one pkg info hands you when you pass a specific package as an argument. the full lore, basically 📖

  • Mandatory: Yes
  • Default:
    • CPACK_DEBIAN_PACKAGE_DESCRIPTION (this may be set already for Debian packaging, so it gets used as a fallback).
    • CPACK_PACKAGE_DESCRIPTION_SUMMARY (this is always set by CPack itself, if nothing else sets it explicitly).
    • PROJECT_DESCRIPTION (this one can be set with the DESCRIPTION parameter for project()).

✨ CPACK_FREEBSD_PACKAGE_WWW

The URL of the web site for this package — and preferably, when it applies, the site the original source can be obtained from, plus any extra upstream documentation or info you might find there. give the people a place to click 🫶

  • Mandatory: Yes
  • Default:
    • CPACK_PACKAGE_HOMEPAGE_URL, or if that is not set,
    • CPACK_DEBIAN_PACKAGE_HOMEPAGE (this may be set already for Debian packaging, so it gets used as a fallback).
Added in version 3.12: the CPACK_PACKAGE_HOMEPAGE_URL variable joined the chat ✨

💜 CPACK_FREEBSD_PACKAGE_LICENSE

The license, or licenses, that apply to this software package. This must be one or more license-identifiers that pkg recognizes as acceptable license identifiers (e.g. "GPLv2"). no improvising, she's picky.

  • Mandatory: Yes
  • Default:
    • CPACK_RPM_PACKAGE_LICENSE

🌈 CPACK_FREEBSD_PACKAGE_LICENSE_LOGIC

This one only matters if there's more than one license. The default is "single", which — you guessed it — only applies to a single license. The other acceptable values are determined by pkg; those are "dual" or "multi", meaning either choice (OR) or simultaneous (AND) application of the licenses. choose your fighter ⚔️

  • Mandatory: No
  • Default: single

🍓 CPACK_FREEBSD_PACKAGE_MAINTAINER

The FreeBSD maintainer of this package (e.g. kde@freebsd.org). your person, your point of contact 👑

  • Mandatory: Yes
  • Default: none

🧚 CPACK_FREEBSD_PACKAGE_ORIGIN

The origin (ports label) of this package. For packages built by CPack outside of the ports system this is of less importance — but the default still parks the package somewhere under misc/, as a stopgap. it's a placeholder bestie, don't read into it.

  • Mandatory: Yes
  • Default: misc/<package name>

🔥 CPACK_FREEBSD_PACKAGE_CATEGORIES

The ports categories this package lives in (if it were to be built from ports). If none is set, a single category gets determined based on the package origin. girl math, but make it ports.

  • Mandatory: Yes
  • Default: derived from ORIGIN

🌟 CPACK_FREEBSD_PACKAGE_DEPS

A list of package origins that should be added as package dependencies. These are in the form <category>/<packagename>, e.g. x11/libkonq. No version information needs to be provided — it's not included in the manifest anyway. so don't stress about semver, it's not that kind of party 🎉

  • Mandatory: No
  • Default: empty

🎀 CPack Inno Setup Generator 🎀

Added in version 3.27.

Inno Setup is a free installer for Windows programs, by Jordan Russell and Martijn Laan (https://jrsoftware.org/isinfo.php). iconique founder moment.

This documentation explains the options that are specific to the Inno Setup generator.

The generator serves up a lot of options — components and all that. Unfortunately not every feature (component dependencies, for example) is currently supported by Inno Setup, so the generator just ignores them for now. it's not personal, it's just how she is 🙈

⚠️ CPack requires Inno Setup 6 or greater.
Added in version 3.30: the generator is now available on non-Windows hosts too — but it requires Wine to run the Inno Setup tools. cross-platform slay with a tiny asterisk 💅

🦋 Variables specific to CPack Inno Setup generator

You can use the following variables to change the behavior of the CPack INNOSETUP generator:

🌸 General

None of the following variables is required to be set for the Inno Setup generator to work. If a variable is marked as mandatory below but you don't set it, its default value is taken. so basically nobody has to do anything, and that's the vibe.

The variables can also contain Inno Setup constants like {app}. Please refer to the documentation of Inno Setup for more info on those.

If you're asked to provide the path to any file, you can always give an absolute path, or — in most cases — the relative path from the top-level directory where all the files being installed by an install() instruction reside. easy.

CPack tries to escape quotes and other special characters for you. However, using special characters could cause problems. just a lil heads-up 🫶

The following variable simplifies the usage of Inno Setup in CMake:

CPACK_INNOSETUP_USE_CMAKE_BOOL_FORMAT — Inno Setup only uses yes or no as boolean formats, meanwhile CMake uses a whole zoo of alternative formats like ON or OFF. Turning this option on enables an automatic conversion. consider it a translator bestie.

Consider the following example:

set(CMAKE_INNOSETUP_SETUP_AllowNoIcons OFF)

If this option is turned on, the following line will be created in the output script: AllowNoIcons=no. Else, the following erroneous line will be created: AllowNoIcons=OFF. 😭 we love a save.

The conversion is enabled in every Inno Setup specific variable.

  • Mandatory: Yes
  • Default: ON

⭐ Setup Specific Variables

CPACK_INNOSETUP_ARCHITECTURE — One of x86, x64, arm64 or ia64. This variable specifies the target architecture of the installer. It also affects the Program Files folder or the registry keys being used — so like, it has range.

CPack tries to determine the correct value with a try compile (see CMAKE_SIZEOF_VOID_P), but this option can be manually specified too — especially when you're using ia64 or doing cross-platform compilation.

  • Mandatory: Yes
  • Default: Either x86 or x64, depending on the results of the try-compile

CPACK_INNOSETUP_INSTALL_ROOT — If you don't want the installer to create the installation directory under Program Files, you've got to specify the installation root here.

The full directory of the installation will be: ${CPACK_INNOSETUP_INSTALL_ROOT}/${CPACK_PACKAGE_INSTALL_DIRECTORY}.

  • Mandatory: Yes
  • Default: {autopf}

CPACK_INNOSETUP_ALLOW_CUSTOM_DIRECTORY — If turned on, the installer lets the user change the installation directory by giving them an extra wizard page. user agency, we love to see it ✨

  • Mandatory: Yes
  • Default: ON

CPACK_INNOSETUP_PROGRAM_MENU_FOLDER — The initial name of the start menu folder being created.

If this variable is set to ., then no separate folder is created and the application shortcuts will appear right in the top-level start menu folder. minimalism, but make it Windows.

  • Mandatory: Yes
  • Default: The value of CPACK_PACKAGE_NAME

CPACK_INNOSETUP_LANGUAGES — A semicolon-separated list of the languages you want Inno Setup to include. multilingual queen 👑

Currently available: armenian, brazilianPortuguese, bulgarian, catalan, corsican, czech, danish, dutch, english, finnish, french, german, hebrew, icelandic, italian, japanese, norwegian, polish, portuguese, russian, slovak, slovenian, spanish, turkish and ukrainian. This list might differ depending on the version of Inno Setup — so like, check your own install, iykyk.

  • Mandatory: Yes
  • Default: english

CPACK_INNOSETUP_IGNORE_LICENSE_PAGE — If you don't specify a license file using CPACK_RESOURCE_FILE_LICENSE, CPack uses a file for demonstration purposes. If you want the installer to ignore license files entirely, you can enable this option.

  • Mandatory: Yes
  • Default: OFF

CPACK_INNOSETUP_IGNORE_README_PAGE — If you don't specify a readme file using CPACK_RESOURCE_FILE_README, CPack uses a file for demonstration purposes. If you want the installer to ignore readme files entirely, you can enable this option. > Make sure the option is disabled when you're using a custom readme file. don't shoot yourself in the foot bestie 🙈

  • Mandatory: Yes
  • Default — ON (yeah, finishing off the last one from before, we're still rolling 💫)
  • CPACK_INNOSETUP_PASSWORD — turns on password protection and file encryption, using whatever password you hand it 🔐
    • Mandatory — No
  • CPACK_INNOSETUP_USE_MODERN_WIZARD — gives you the modern look-and-feel that Inno Setup provides ✨ flip it off and you get the classic style instead. Heads up: images and icon files are affected by this too, it's not just the chrome 🎀
    • Mandatory — Yes
    • Default — OFF because of compatibility reasons (the classic look stays winning for now 💅)
  • CPACK_INNOSETUP_ICON_FILE — the path to a custom installer .ico file 🖼️
    • Oh and btw, use CPACK_PACKAGE_ICON (that's the variable) to customize the bitmap file that gets shown in the wizard.
    • Mandatory — No
  • CPACK_INNOSETUP_SETUP_<directive> — this whole group is your "adapt anything" pass for the [Setup] section directives that Inno Setup provides, where directive is the directive's name 👑
    • Some examples, because examples ate:
set(CPACK_INNOSETUP_SETUP_WizardSmallImageFile "my_bitmap.bmp")
set(CPACK_INNOSETUP_SETUP_AllowNoIcons OFF) # This requires CPACK_INNOSETUP_USE_CMAKE_BOOL_FORMAT to be on
  • Real talk: all of these variables have higher priority than the others. Consider this little situation:
set(CPACK_INNOSETUP_SETUP_Password "admin")
set(CPACK_INNOSETUP_PASSWORD "secret")

The password will be admin at the end, because CPACK_INNOSETUP_PASSWORD has less priority than CPACK_INNOSETUP_SETUP_Password. The specific one wins, periodt 👑

  • Mandatory — No

File Specific Variables 🗂️

So like, every file that gets installed by an install() command is automatically processed and added to the installer — that's just the vibe. But there are some variables to customize the installation process if you wanna get hands-on 🫶

Before using executables (only .exe or .com, nothing else bestie) in shortcuts (e.g. CPACK_CREATE_DESKTOP_LINKS) or [Run] entries, you've got to add the raw file name — no path, no extension — to CPACK_PACKAGE_EXECUTABLES and create a start menu shortcut for them.

⚠️ If you have two files with the same raw name (e.g. a/executable.exe and b/executable.com), an entry in the section is created twice. That results in undefined behavior and is not recommended. Don't do it 💀
  • CPACK_INNOSETUP_CUSTOM_INSTALL_INSTRUCTIONS — this variable should contain a semicolon-separated list (yk, a CMake list) of pairs of path, instruction, and it lets you customize the install command that gets automatically created for each file or directory ✍️
    • CPack creates the following Inno Setup instruction for every file...
Source: "absolute\path\to\my_file.txt"; DestDir: "{app}"; Flags: ignoreversion
  • ...and the following line for every directory:
Name: "{app}\my_folder"
  • Say you wanna change the destination directory or the flags of my_file.txt. Since we can also provide a relative path, the line you'd like to have is this one:
Source: "my_file.txt"; DestDir: "{userdocs}"; Flags: ignoreversion uninsneveruninstall
set(CPACK_INNOSETUP_CUSTOM_INSTALL_INSTRUCTIONS "my_file.txt;Source: \\\"my_file.txt\\\"\\; DestDir: \\\"{userdocs}\\\"\\; Flags: ignoreversion uninsneveruninstall")
  • To improve readability, you should go around the escaping problem entirely by using CPACK_VERBATIM_VARIABLES or by placing the instruction into a separate CPack project config file. Do yourself the favor 🧚
  • If you customize the install instruction of a specific file, you lose the connection to its component. To go around that, manually add Components: <component>. You also need to add its shortcuts and [Run] entries by yourself in a custom section, since the executable won't be found anymore by CPACK_PACKAGE_EXECUTABLES. Yeah, it's giving manual labor 🙈
  • Here's another example (Note: you've got to go around the escaping problem for the example to work):
set(CPACK_INNOSETUP_CUSTOM_INSTALL_INSTRUCTIONS
    "component1/my_folder" "Name: \"{userdocs}\\my_folder\"\; Components: component1"
    "component2/my_folder2/my_file.txt" "Source: \"component2\\my_folder2\\my_file.txt\"\; DestDir: \"{app}\\my_folder2\\my_file.txt\"\; Flags: ignoreversion uninsneveruninstall\; Components: component2")
  • Mandatory — No
  • CPACK_INNOSETUP_MENU_LINKS — this one should contain a semicolon-separated list (CMake list, you know the drill) of pairs of link, link name, and it adds shortcuts into the start menu folder beside those of the executables (see CPACK_PACKAGE_EXECUTABLES) 🎀 While link name is the label, link can be a URL or a path relative to the installation directory.
    • Here's an example:
set(CPACK_INNOSETUP_MENU_LINKS
    "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
    "CMake Help" "https://cmake.org" "CMake Web Site")
  • Mandatory — No
  • CPACK_INNOSETUP_CREATE_UNINSTALL_LINK — turn this on and a shortcut to the application's uninstaller is automatically added to the start menu folder 🗑️
    • Mandatory — Yes
    • Default — OFF
  • CPACK_INNOSETUP_RUN_EXECUTABLES — a semicolon-separated list (CMake list 💫) of executables being specified in CPACK_PACKAGE_EXECUTABLES which the user can run when the installer finishes. They're internally added to the [Run] section 🏃‍♀️
    • Mandatory — No

Components Specific Variables 🧩

The generator supports components and also downloaded components, slay. However, there are some features of components that aren't supported yet (especially component dependencies). These variables are ignored for now, no cap.

CPack will change a component's name in Inno Setup if it has a parent group, for technical reasons. So consider using group\component as the component name in Inno Setup scripts if you have the component component and its parent group group. iykyk 🌀

Here are some additional variables for components:

  • CPACK_INNOSETUP_<compName>_INSTALL_DIRECTORY — if you don't want the component compName to be installed under {app}, you've got to specify its installation directory here 📁
    • Mandatory — No
  • CPACK_INNOSETUP_VERIFY_DOWNLOADS — this option only affects downloaded components ⚠️
    • If it's turned on, the hashes of the downloaded archives are calculated during compile and download time. The installer will only proceed if they match. Security check, we stan 🔥
    • Mandatory — Yes
    • Default — ON

Compilation and Scripting Specific Variables 🛠️

  • CPACK_INNOSETUP_EXECUTABLE — the filename of the Inno Setup Script Compiler command 🖥️
    • Mandatory — Yes
    • Default — ISCC
  • CPACK_INNOSETUP_EXECUTABLE_ARGUMENTS — a semicolon-separated list (CMake list bestie 🎀) of extra command-line options for the Inno Setup Script Compiler command.
  • CPACK_INNOSETUP_DEFINE_<macro> — this group lets you add custom define directives as command-line options to the Inno Setup Preprocessor command. Each entry emulates a #define public <macro> directive, and its macro is accessible from anywhere (public!), so it can also be used in extra script files 🌈
    • Macro names must not contain any special characters. Refer to the Inno Setup Preprocessor documentation for the detailed rules, fr fr.
    • Consider the following example:
# The following line emulates: #define public MyMacro "Hello, World!"
set(CPACK_INNOSETUP_DEFINE_MyMacro "Hello, World!")
  • At this point, you can use MyMacro anywhere. For example in the following extra script:
AppComments={#emit "'My Macro' has the value: " + MyMacro}
  • CPACK_INNOSETUP_EXTRA_SCRIPTS — a semicolon-separated list (CMake list 💖) of paths to additional .iss script files to be processed.
    • They're internally included at the top of the output script file using a #include directive.
    • You can add any section in your file to extend the installer (e.g. adding additional tasks or registry keys). But prefer using CPACK_INNOSETUP_SETUP_<directive> when extending the [Setup] section 👑
    • Mandatory — No
  • CPACK_INNOSETUP_CODE_FILES — a semicolon-separated list (CMake list ✨) of paths to additional Pascal files to be processed.
    • This variable is actually the same as CPACK_INNOSETUP_EXTRA_SCRIPTS, except you don't have to add [Code] at the top of your file.
    • > 💀 Never change the current section in a code file. This will result in undefined behavior! Treat them as normal Pascal scripts instead. I'm so serious, bestie.
    • Code files are included at the very bottom of the output script.
    • Mandatory — No

CPack IFW Generator 🧚

Added in version 3.1.

Configure and run the Qt Installer Framework to generate a Qt installer. Okay this one's iconic 💅

Overview

This cpack generator generates configuration and meta information for the Qt Installer Framework (https://doc.qt.io/qtinstallerframework/index.html) — QtIFW for short — and runs QtIFW tools to generate a Qt installer 🌸

QtIFW provides tools and utilities to create installers for the platforms supported by Qt (https://www.qt.io): Linux, Microsoft Windows, and macOS. All three of them, we love a cross-platform moment 🦋

To make use of this generator, QtIFW needs to be installed. The CPackIFW module hunts down where the QtIFW command-line utilities are living, and it defines a bunch of commands to control how this generator behaves. See Hints for Finding QtIFW. 🕵️‍♀️

Variables 🧩

You can use the following variables to change the behavior of the CPack IFW generator. Yes, all of them. There are a lot. Grab a snack. 🍓

Debug 🐛

  • CPACK_IFW_VERBOSE — Added in version 3.3. Set it to ON to get addition debug output. It's OFF by default bestie, so flip it if you wanna peek under the hood. 🔍

Package 📦

  • CPACK_IFW_PACKAGE_TITLE — the name of the installer, the way it shows up on the title bar. If you don't specify it, it just defaults to CPACK_PACKAGE_DESCRIPTION_SUMMARY. ✨
  • CPACK_IFW_PACKAGE_PUBLISHER — who's publishing this software, as shown in the Windows Control Panel. If it's not specified, it defaults to CPACK_PACKAGE_VENDOR. 👑
  • CPACK_IFW_PRODUCT_URL — a URL to a page on your web site that has product info. Link it up. 🔗
  • CPACK_IFW_PACKAGE_ICON — filename for a custom installer icon. It must be an absolute path. This should be a .icns file on macOS and a .ico file on Windows. It's ignored on other platforms, so don't stress about it elsewhere. 💅
  • CPACK_IFW_PACKAGE_WINDOW_ICON — filename for a custom window icon in PNG format for the Installer application. Absolute path, no exceptions. 🪟
  • CPACK_IFW_PACKAGE_LOGO — filename for a logo image in PNG format, used as QWizard::LogoPixmap. Absolute path required. 🎀
  • CPACK_IFW_PACKAGE_WATERMARK — Added in version 3.8. Filename for a watermark image in PNG format, used as QWizard::WatermarkPixmap. Must be an absolute path. 💧
  • CPACK_IFW_PACKAGE_BANNER — Added in version 3.8. Filename for a banner image in PNG format, used as QWizard::BannerPixmap. Absolute path, always. 🏳️
  • CPACK_IFW_PACKAGE_BACKGROUND — Added in version 3.8. Filename for a background image in PNG format, used as QWizard::BackgroundPixmap (and it's only used by MacStyle, iykyk). Must be an absolute path. 🌈
  • CPACK_IFW_PACKAGE_WIZARD_STYLE — Added in version 3.8. The wizard style to be used: Modern, Mac, Aero or Classic. Pick your vibe. 💫
  • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH — Added in version 3.8. Default width of the wizard, in pixels. Heads up: setting a banner image will override this. 📐
  • CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT — Added in version 3.8. Default height of the wizard, in pixels. And setting a watermark image will override this one. 📏
  • CPACK_IFW_PACKAGE_WIZARD_SHOW_PAGE_LIST — Added in version 3.20. Set to OFF if you don't want the widget listing installer pages on the left side of the wizard to show. It's ON by default, but it will only have an effect if using QtIFW 4.0 or later. 🫥
  • CPACK_IFW_PACKAGE_TITLE_COLOR — Added in version 3.8. Color of the titles and subtitles. It takes an HTML color code, such as #88FF33. 💚
  • CPACK_IFW_PACKAGE_STYLE_SHEET — Added in version 3.15. Filename for a stylesheet. It must be an absolute path. Slay that styling. 💄
  • CPACK_IFW_TARGET_DIRECTORY — the default target directory for installation. If CPACK_PACKAGE_INSTALL_DIRECTORY is set, this defaults to @ApplicationsDir@/${CPACK_PACKAGE_INSTALL_DIRECTORY}. If that variable isn't set either, the default used is @RootDir@/usr/local. Those predefined variables of the form @...@ get expanded by the QtIFW scripting engine, fr fr. 🗂️
  • CPACK_IFW_ADMIN_TARGET_DIRECTORY — the default target directory for installation with administrator rights. You can use predefined variables here too. 🔐
  • CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR — Added in version 3.11. Set to OFF if the target directory should not be deleted when uninstalling. It is ON by default. 🗑️
  • CPACK_IFW_PACKAGE_GROUP — the group which will be used to configure the root package. 🎯
  • CPACK_IFW_PACKAGE_NAME — the root package name, used if the configuration group is not specified. 🏷️
  • CPACK_IFW_PACKAGE_START_MENU_DIRECTORY — Added in version 3.3. Name of the default program group for the product in the Windows Start menu. If not specified, it defaults to CPACK_IFW_PACKAGE_NAME. 🪟
  • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_NAME — Added in version 3.3. Filename of the generated maintenance tool. The platform-specific executable file extension will be appended for you. If not specified, QtIFW provides a default name (maintenancetool). 🔧
  • CPACK_IFW_PACKAGE_MAINTENANCE_TOOL_INI_FILE — Added in version 3.3. Filename for the configuration of the generated maintenance tool. If not specified, QtIFW uses a default file name (maintenancetool.ini). 📄
  • CPACK_IFW_PACKAGE_ALLOW_NON_ASCII_CHARACTERS — Added in version 3.3. 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 anyway. 🌍
  • CPACK_IFW_PACKAGE_ALLOW_SPACE_IN_PATH — Added in version 3.3. Set to OFF if the installation path cannot contain space characters. It is ON for QtIFW less 2.0 tools. ␣
  • CPACK_IFW_PACKAGE_DISABLE_COMMAND_LINE_INTERFACE — Added in version 3.23. 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. 🖥️
  • CPACK_IFW_PACKAGE_CONTROL_SCRIPT — Added in version 3.3. Filename for a custom installer control script. 📜
  • CPACK_IFW_PACKAGE_RESOURCES — Added in version 3.7. 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. 🧺
  • CPACK_IFW_PACKAGE_FILE_EXTENSION — Added in version 3.10. The target binary extension. Ok so: on Linux, the name of the target binary is automatically extended with .run if you don't 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 a DMG disk image with the extension .dmg, which is automatically added if not supplied. Cute, right? 💽
  • CPACK_IFW_REPOSITORIES_ALL — the list of remote repositories. 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(). 📚
  • CPACK_IFW_DOWNLOAD_ALL — if this is ON, all components will be downloaded. If it's not set, the behavior is determined by whether cpack_configure_downloads() has been called with the ALL option or not. ⬇️
  • CPACK_IFW_PACKAGE_PRODUCT_IMAGES — Added in version 3.23. 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. 🖼️
  • CPACK_IFW_PACKAGE_PRODUCT_IMAGE_URLS — Added in version 3.31. A list of URLs associated with the ProductImages. Only used if CPACK_IFW_PACKAGE_PRODUCT_IMAGES is defined and it has the same size. This feature is available for QtIFW 4.0.0 and later. 🔗
  • CPACK_IFW_PACKAGE_RUN_PROGRAM — Added in version 3.23. 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. 🚀
  • CPACK_IFW_PACKAGE_RUN_PROGRAM_ARGUMENTS — Added in version 3.23. 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. 🧾
  • CPACK_IFW_PACKAGE_RUN_PROGRAM_DESCRIPTION — Added in version 3.23. 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. 💬
  • CPACK_IFW_PACKAGE_SIGNING_IDENTITY — Added in version 3.23. Lets you specify a code signing identity to be used for signing the generated app bundle. Only available on macOS — ignored on other platforms, sorry besties. 🍎
  • CPACK_IFW_ARCHIVE_FORMAT — Added in version 3.23. Sets 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:
    • 7z
    • zip
    • tar.gz
    • tar.bz2
    • tar.xz
Note: If the Qt Installer Framework tools were built without libarchive support, only 7z format is supported. 💀

This feature is available for QtIFW 4.2.0 and later. 📦

  • CPACK_IFW_ARCHIVE_COMPRESSION — Added in version 3.23. Archive compression level. The allowable values are:
    • 0 (No compression)
    • 1 (Fastest compression)
    • 3 (Fast compression)
    • 5 (Normal compression)
    • 7 (Maximum compression)
    • 9 (Ultra compression)

If this variable is not set, QtIFW will use a default compression level, which will typically be 5 (Normal compression).

Note: Some formats do not support all the possible values. For example zip compression only supports values from 1 to 7. Keep that in mind, ok? 🙈

This feature is available for QtIFW 4.2.0 and later. 🗜️

Components 🧱

  • CPACK_IFW_RESOLVE_DUPLICATE_NAMES — resolve duplicate names when installing components with groups. Iconic behavior honestly. 🫶
  • CPACK_IFW_PACKAGES_DIRECTORIES — extra directories full of already-prepped packages that get used to resolve dependent components 🫶
  • CPACK_IFW_REPOSITORIES_DIRECTORIES — Added in version 3.10. More directories of already-prepared repositories, used to resolve and repack dependent components. Heads up: this one's only a thing on QtIFW 3.1 and later ✨

🧰 QtIFW Tools

  • CPACK_IFW_FRAMEWORK_VERSION — Added in version 3.3. Which version of the QtIFW tools you're rolling with. The CPackIFW module sets this bad boy for you.

The next batch are the locations of the QtIFW command-line tools, as found by the CPackIFW module. They're cached, so you can configure them yourself if the auto-detect is being weird 💅

  • CPACK_IFW_ARCHIVEGEN_EXECUTABLE — Added in version 3.19. Path to archivegen.
  • CPACK_IFW_BINARYCREATOR_EXECUTABLE — Path to binarycreator.
  • CPACK_IFW_REPOGEN_EXECUTABLE — Path to repogen.
  • CPACK_IFW_INSTALLERBASE_EXECUTABLE — Path to installerbase.
  • CPACK_IFW_DEVTOOL_EXECUTABLE — Path to devtool.

🔍 Hints for Finding QtIFW

okay so normally the CPack IFW generator just finds the QtIFW tools on its own, no drama. But if you wanna give it a nudge, you can set any of the following to add to the places find_program() already searches — and they're listed in order of precedence 👑

  • CPACK_IFW_ROOT — Added in version 3.9. As a CMake variable.
  • CPACK_IFW_ROOT — Added in version 3.9. As an environment variable.
  • QTIFWDIR — As a CMake variable.
  • QTIFWDIR — As an environment variable.
⚠️ bestie listen — the path you give should not have bin stuck on the end. Like, it should look like D:\DevTools\QtIFW2.0.5, not the bin folder inside it. 🙈

🎛️ Other Settings

🌐 Online installer

So by default this generator makes you an offline installer, meaning literally every packaged file is fully tucked inside the installer executable. Cute, self-contained, chunky.

An online installer is the opposite vibe: it downloads some or all of the components from a remote server. 🌈

  • The DOWNLOADED option in the cpack_add_component() command says "this component gets downloaded."
  • Or alternatively, the ALL option in the cpack_configure_downloads() command says "okay download everything."

And if you want something more specific, the cpack_ifw_add_repository() command plus the CPACK_IFW_DOWNLOAD_ALL variable have you covered 💅

When you do have online components, CPack writes them out to archive files. The CPackComponent module's help page — especially the bit about the cpack_configure_downloads() function — explains how to make those files reachable from a download URL. ✨

🌍 Internationalization

Added in version 3.9.

Some variables and command arguments support internationalization through the CMake script. It's optional, no pressure. 🦋

Installers made by QtIFW tools already have built-in i18n and loads of phrases are localized into many languages — but that does not cover the description of your components and groups. 😭

Localizing those descriptions is genuinely useful for the people using your installers, so like… do it.

A localized variable or argument can hold a single default value, and then after that, a set of pairs: the locale name, and the localized value.

For example:

set(LOCALIZABLE_VARIABLE "Default value"
  en "English value"
  en_US "American value"
  en_GB "Great Britain value"
  )

🔗 See Also

Qt Installer Framework Manual:

Download Qt Installer Framework for your platform from the Qt site: https://download.qt.io/official_releases/qt-installer-framework

🪟 CPack NSIS Generator

CPack Nullsoft Scriptable Install System (NSIS) generator–specific options. Yes, that's the real full name, no cap. 💀

Changed in version 3.22: the NSIS generator needs NSIS 3.03 or newer. Old NSIS? Not invited to the party.

🧩 Variables specific to CPack NSIS generator

These are the variables that belong specifically to the graphical installers built on Windows with Nullsoft Scriptable Install System. Let's go 👑

  • CPACK_NSIS_INSTALL_ROOT — the default install directory the NSIS installer shows your user lives under this root dir. The full directory the user actually sees is: ${CPACK_NSIS_INSTALL_ROOT}/${CPACK_PACKAGE_INSTALL_DIRECTORY}
  • CPACK_NSIS_MUI_ICON — an icon filename, bestie. The name of a *.ico file used as the main icon for the generated install program. 🎀
  • CPACK_NSIS_MUI_UNIICON — another 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. (yes, that's literally it. iconic honestly 💀)
  • CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP — Added in version 3.5. The filename of a bitmap to use as the NSIS MUI_WELCOMEFINISHPAGE_BITMAP.
  • CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP — Added in version 3.5. The filename of a bitmap to use as the NSIS MUI_UNWELCOMEFINISHPAGE_BITMAP.
  • CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS — extra NSIS commands that get dropped at the beginning of the install Section, before your install tree even exists on the target system.
  • CPACK_NSIS_EXTRA_INSTALL_COMMANDS — extra NSIS commands that get dropped at 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 get added to the uninstall Section, before your install tree gets removed from the target system.
  • CPACK_NSIS_COMPRESSOR — the arguments that get passed to the NSIS SetCompressor command.
  • CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL — asks about uninstalling previous versions first. If you set this to ON, the installer goes looking for previously installed versions, and if it finds one it asks the user whether to uninstall it before carrying on with the install. 🫶
  • CPACK_NSIS_MODIFY_PATH — the Modify PATH toggle. Set it to ON and an extra page pops up in the installer letting the user choose whether the program directory should be added to the system PATH variable. Lowkey the most-requested checkbox of all time.
  • CPACK_NSIS_DISPLAY_NAME — the display name string that shows up in Windows Apps & features in 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 that helps people install your application.
  • CPACK_NSIS_URL_INFO_ABOUT — URL to a web site with more info about your application.
  • CPACK_NSIS_CONTACT — contact info for questions and comments about the installation process.
  • CPACK_NSIS_<compName>_INSTALL_DIRECTORY — Added in version 3.7. A custom install directory for the component named <compName>, instead of $INSTDIR.
  • CPACK_NSIS_CREATE_ICONS_EXTRA — additional NSIS commands for creating Start Menu shortcuts.
  • CPACK_NSIS_DELETE_ICONS_EXTRA — additional NSIS commands to uninstall Start Menu shortcuts.
  • CPACK_NSIS_EXECUTABLES_DIRECTORY — creating NSIS Start Menu links assumes they live in bin unless you set this variable. Like, you'd set it to exec if your executables are in an exec directory. iykyk 💅
  • 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 the [application] menu. This should contain a list of pairs: link, link name. The link can be a URL or a path relative to the installation prefix. Like this:
set(CPACK_NSIS_MENU_LINKS
  "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake.html"
  "CMake Help" "https://cmake.org" "CMake Web Site")
  • CPACK_NSIS_UNINSTALL_NAME — Added in version 3.17. Specify the name of the program to uninstall the version. Default is Uninstall.
  • CPACK_NSIS_WELCOME_TITLE — Added in version 3.17. The title to display at the top of the page for the welcome page.
  • CPACK_NSIS_WELCOME_TITLE_3LINES — Added in version 3.17. Display the title on the welcome page on 3 lines instead of 2.
  • CPACK_NSIS_FINISH_TITLE — Added in version 3.17. The title to display at the top of the page for the finish page.
  • CPACK_NSIS_FINISH_TITLE_3LINES — Added in version 3.17. Display the title in the finish page on 3 lines instead of 2.
  • CPACK_NSIS_MUI_HEADERIMAGE — Added in version 3.17. The image to display on the header of installer pages. 🌸
  • CPACK_NSIS_MANIFEST_DPI_AWARE — Added in version 3.18. If set, it declares that the installer is DPI-aware. ✨
  • CPACK_NSIS_BRANDING_TEXT — Added in version 3.20. If set, updates the text at the bottom of the install window. Wanna set the string to blank? Use a space (" "). That's the move.
  • CPACK_NSIS_BRANDING_TEXT_TRIM_POSITION — Added in version 3.20. If set, trims down the size of the control to the size of the branding text string. Allowed values are LEFT, CENTER or RIGHT. If you don't specify one, the default behavior is LEFT.
  • CPACK_NSIS_EXECUTABLE — Added in version 3.21. If set, specifies the name of the NSIS executable. Default is makensis.
  • CPACK_NSIS_IGNORE_LICENSE_PAGE — Added in version 3.22. If set, don't display the page containing the license during installation. (we're all clicking accept anyway 🙈)
  • CPACK_NSIS_EXECUTABLE_PRE_ARGUMENTS — Added in version 3.25. This variable is a semicolon-separated list of arguments to prepend to the nsis script that gets run. If the arguments don't start with a / or a -, it'll automatically add one to the corresponding arguments. The command that ends up running is:
makensis.exe <preArgs>... "nsisFileName.nsi" <postArgs>...

...where <preArgs>... gets built from CPACK_NSIS_EXECUTABLE_PRE_ARGUMENTS, and <postArgs>... gets built from CPACK_NSIS_EXECUTABLE_POST_ARGUMENTS. The whole thing it runs is literally:

makensis.exe <preArgs>... "nsisFileName.nsi" <postArgs>...
  • CPACK_NSIS_CRC_CHECK — added in version 4.2. Controls whether the installer does a CRC on itself before it'll let the install happen (self-care check, honestly iconic of it 🫶). Allowed values are on, off, and force. If you don't set it, the default behavior is on.
  • CPACK_NSIS_IGNORE_COMPONENTS_PAGE — added in version 4.4. If it's set, the installer will not show the page containing the license during installation. That's it, that's the whole vibe.

🍬 CPack NuGet Generator

Added in version 3.12.

Okay so real talk: when you build a NuGet package there is no direct way to control an output filename, because NuGet just doesn't have the corresponding CLI option for it. So there's no CPACK_NUGET_PACKAGE_FILE_NAME variable, sorry bestie 😭. To form the output filename, NuGet uses the package name and the version according to its own built-in rules. Not our call!

Also, be aware that including a top level directory (CPACK_INCLUDE_TOPLEVEL_DIRECTORY) is ignored by this generator. Like, straight up ignored. 💀

✨ Variables specific to CPack NuGet generator

The CPack NuGet generator is what you use to create NuGet packages with CPack. And because it is a CPack generator, it uses all the CPACK_XXX variables that CPack itself uses — same family, same energy.

On top of that, it has its own little specifics, controlled by the CPACK_NUGET_XXX variables. And heads up: in the "one per group" mode (peep CPACK_COMPONENTS_GROUPING), the <compName> placeholder in the variables below holds a group name — uppercased and turned into a "C" identifier. Cute, right? 🎀

Here's the list of CPack NuGet generator specific variables:

  • CPACK_NUGET_COMPONENT_INSTALL — enables component packaging for the CPack NuGet generator.
    • Mandatory — No
    • Default — OFF
  • CPACK_NUGET_PACKAGE_DEBUG — enables debug messages while the CPack NuGet generator is executing (for when you need to see what's actually going on 👀).
    • Mandatory — No
    • Default — OFF
  • CPACK_NUGET_SYMBOL_PACKAGE — added in version 4.1. generates a NuGet symbol package (.snupkg).
    • Mandatory — No
    • Default — OFF

🌟 Required metadata variables

Okay these next ones? Mandatory. Like, you must set them, no cap. 💅

  • CPACK_NUGET_PACKAGE_NAME, CPACK_NUGET_<compName>_PACKAGE_NAME — the NuGet package name. CPACK_NUGET_PACKAGE_NAME is what gets used as the package id on nuget.org (the site lives at https://www.nuget.org).
    • Mandatory — Yes
    • Default — CPACK_PACKAGE_NAME
  • CPACK_NUGET_PACKAGE_VERSION, CPACK_NUGET_<compName>_PACKAGE_VERSION — the NuGet package version.
    • Mandatory — Yes
    • Default — CPACK_PACKAGE_VERSION
  • CPACK_NUGET_PACKAGE_DESCRIPTION, CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION — a long description of the package, for UI display. The whole "tell me about yourself" moment ✨.
    • Mandatory — Yes
    • Default — one of:
      • CPACK_COMPONENT_<compName>_DESCRIPTION
      • CPACK_COMPONENT_GROUP_<groupName>_DESCRIPTION
      • CPACK_PACKAGE_DESCRIPTION
  • CPACK_NUGET_PACKAGE_AUTHORS, CPACK_NUGET_<compName>_PACKAGE_AUTHORS — a comma-separated list of package authors, matching the profile names on nuget.org (https://www.nuget.org). These show up in the NuGet Gallery on nuget.org (https://www.nuget.org) and get used to cross-reference packages by the same authors. Main character credits, basically 👑.
    • Mandatory — Yes
    • Default — CPACK_PACKAGE_VENDOR

🌈 Optional metadata variables

These ones are the vibe-optional extras — set them if you want your package looking extra polished. 🦋

  • CPACK_NUGET_PACKAGE_OWNERS, CPACK_NUGET_<compName>_PACKAGE_OWNERS — deprecated since version 3.20: use authors (CPACK_NUGET_PACKAGE_AUTHORS) instead. A comma-separated list of the package creators using profile names on nuget.org (https://www.nuget.org). This is often the same list as in authors, and it's ignored when uploading the package to nuget.org (https://www.nuget.org).
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_HOMEPAGE_URL, CPACK_NUGET_<compName>_PACKAGE_HOMEPAGE_URL — a URL for the package's home page, often shown in UI displays as well as on nuget.org (https://www.nuget.org).
    • Mandatory — No
    • Default — CPACK_PACKAGE_HOMEPAGE_URL
  • CPACK_NUGET_PACKAGE_LICENSEURL, CPACK_NUGET_<compName>_PACKAGE_LICENSEURL — deprecated since version 3.20: use a local license file (CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME) or a SPDX license identifier (CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION) instead. A URL for the package's license, often shown in UI displays as well as on nuget.org (https://www.nuget.org).
    • Mandatory — No
    • Default — None
    • Supported — NuGet 4.9.0 and above
  • CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME, CPACK_NUGET_<compName>_PACKAGE_LICENSE_FILE_NAME — added in version 3.20. the package's license file, in .txt or .md format. Careful bestie: if CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME is specified, CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION is ignored.
    • Mandatory — No
    • Default — None
    • Supported — NuGet 4.9.0 and above
  • CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION, CPACK_NUGET_<compName>_PACKAGE_LICENSE_EXPRESSION — added in version 3.20. a Software Package Data Exchange SPDX license identifier (spec lives at https://spdx.org/licenses) such as MIT, BSD-3-Clause, or LGPL-3.0-or-later. If you've got a choice of licenses or something more complex, compound license expressions can be formed using boolean operators — for example MIT OR BSD-3-Clause. See the SPDX specification (https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions) for guidance on forming those complex license expressions. It's giving lawyer but make it open source 📜.
    • If CPACK_NUGET_PACKAGE_LICENSE_FILE_NAME is specified, CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION is ignored.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_ICONURL, CPACK_NUGET_<compName>_PACKAGE_ICONURL — deprecated since version 3.20: use a local icon file (CPACK_NUGET_PACKAGE_ICON) instead. A URL for a 64x64 image with a transparency background, to use as the icon for the package in UI display.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_ICON, CPACK_NUGET_<compName>_PACKAGE_ICON — added in version 3.20. the filename of a 64x64 image with a transparency background, to use as the icon for the package in UI display. Yes, 64x64, they're serious about it 🎀.
    • Mandatory — No
    • Default — None
    • Supported — NuGet 5.3.0 and above
  • CPACK_NUGET_PACKAGE_README, CPACK_NUGET_<compName>_PACKAGE_README — added in version 3.30. the package path, relative to the root of the package, to a readme file. Supported file formats include only Markdown (*.md). No .txt, no .rst, don't even try it 🙈.
    • Mandatory — No
    • Default — None
    • Supported — NuGet 5.10.0 preview 2 and above
  • CPACK_NUGET_PACKAGE_REQUIRE_LICENSE_ACCEPTANCE — when set to a true value, the user will be prompted to accept the license before installing the package. Consent era ✨.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_DESCRIPTION_SUMMARY, CPACK_NUGET_<compName>_PACKAGE_DESCRIPTION_SUMMARY — deprecated since version 3.30: Summary is being deprecated. Use description (CPACK_NUGET_PACKAGE_DESCRIPTION) instead. A short description of the package for UI display. If it's omitted, a truncated version of the description gets used.
    • Mandatory — No
    • Default — CPACK_PACKAGE_DESCRIPTION_SUMMARY
  • CPACK_NUGET_PACKAGE_RELEASE_NOTES, CPACK_NUGET_<compName>_PACKAGE_RELEASE_NOTES — a description of the changes made in this release of the package, often used in UI like the Updates tab of the Visual Studio Package Manager in place of the package description. So it's got range 💅.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_COPYRIGHT, CPACK_NUGET_<compName>_PACKAGE_COPYRIGHT — copyright details for the package.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_LANGUAGE, CPACK_NUGET_<compName>_PACKAGE_LANGUAGE — added in version 3.20. locale specifier for the package — for example en_CA.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_TAGS, CPACK_NUGET_<compName>_PACKAGE_TAGS — a space-delimited list of tags and keywords that describe the package and help it get discovered through search and filtering. SEO era, honestly 🌸.
    • Mandatory — No
    • Default — None
  • CPACK_NUGET_PACKAGE_REPOSITORY_URL, CPACK_NUGET_<compName>_REPOSITORY_URL — added in version 3.30.

Repository metadata lets you map the *.nupkg to the repository that built it 💅 It should be a publicly available URL that can be invoked directly by a version control software. It should not be an HTML page, because this is meant for the computer, not for your eyeballs 👀

Mandatory No 🙅

Default None

Supported NuGet 4.0 and above

CPACK_NUGET_PACKAGE_REPOSITORY_TYPE

CPACK_NUGET_<compName>_REPOSITORY_TYPE

Added in version 3.30.

A type of the VCS repository. When you're uploading a package to nuget.org (https://www.nuget.org), the type is limited to 100 characters — so like, keep it short bestie ✂️

Mandatory Yes, if repository URL has been specified 👈 lowkey important

Default None

Supported NuGet 4.0 and above

CPACK_NUGET_PACKAGE_REPOSITORY_BRANCH

CPACK_NUGET_<compName>_REPOSITORY_BRANCH

Added in version 3.30.

A VSC branch name to build the package 🌿 (and yes, the original really does say "VSC" — I'm not touching it, it's canon 💀)

Mandatory No

Default None

Supported NuGet 4.6 and above

CPACK_NUGET_PACKAGE_REPOSITORY_COMMIT

CPACK_NUGET_<compName>_REPOSITORY_COMMIT

Added in version 3.30.

A SHA-1 hash of the commit to build the package 🔏

Mandatory No

Default None

Supported NuGet 4.6 and above

CPACK_NUGET_PACKAGE_TITLE

CPACK_NUGET_<compName>_PACKAGE_TITLE

A human-friendly title of the package — the kind of thing that shows up in UI displays, like on nuget.org (https://www.nuget.org) and in the Package Manager in Visual Studio ✨ If you don't specify it, the package ID is used. Slay by default, honestly.

Mandatory No

Default

  • CPACK_COMPONENT_<compName>_DISPLAY_NAME (see variable:CPACK_COMPONENT_<compName>_DISPLAY_NAME)
  • CPACK_COMPONENT_GROUP_<groupName>_DISPLAY_NAME

Dependencies specification 💖

CPACK_NUGET_PACKAGE_DEPENDENCIES

CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES

A list of default (not framework-specific) package dependencies 📦

Mandatory No

Default None

CPACK_NUGET_PACKAGE_DEPENDENCIES_<dependency>_VERSION

CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<dependency>_VERSION

A version specification (https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges) for the particular dependency, where <dependency> is an item of the dependency list (see above) 🎯

Mandatory No

Default None

CPACK_NUGET_PACKAGE_TFMS

CPACK_NUGET_<compName>_PACKAGE_TFMS

Added in version 3.30.

A list of Target Framework Monikers (TFMs) for the package, e.g. "net47;netcoreapp21" 🌈 For each of these TFMs a dependency group (https://learn.microsoft.com/en-us/nuget/reference/nuspec#dependency-groups) will be generated in the dependencies block of the NuGet package. Framework-specific dependencies can be added to these groups with the TFM dependency lists (see below).

This variable is particularly useful for fixing warnings NU5128 (https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu5128) — like, it's the whole reason it exists 🫶

Mandatory No

Default None

CPACK_NUGET_PACKAGE_DEPENDENCIES_<tfm>

CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<tfm>

Added in version 3.30.

A list of package dependencies that apply specifically to the <tfm> framework, where <tfm> is an item from the TFMs list (see above) 🎀

Mandatory No

Default None

CPACK_NUGET_PACKAGE_DEPENDENCIES_<tfm>_<dependency>_VERSION

CPACK_NUGET_<compName>_PACKAGE_DEPENDENCIES_<tfm>_<dependency>_VERSION

Added in version 3.30.

A version specification (https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges) for the particular framework-specific dependency, where <dependency> is an item of the <tfm>-specific dependency list (see above) 💅

Mandatory No

Default None

Example usage 👑

set(CPACK_GENERATOR NuGet)
# Set up package metadata
set(CPACK_PACKAGE_NAME SamplePackage)
set(CPACK_PACKAGE_VERSION "1.0.0")
set(CPACK_PACKAGE_VENDOR "Example Inc")
set(CPACK_NUGET_PACKAGE_AUTHORS "ExampleInc")
set(CPACK_PACKAGE_DESCRIPTION "A .NET wrapper around the foobar library for frobbling bratchens")
set(CPACK_PACKAGE_HOMEPAGE_URL "https://www.example.com")
set(CPACK_NUGET_PACKAGE_REPOSITORY_URL "https://github.com/example/libfoobar.git")
set(CPACK_NUGET_PACKAGE_REPOSITORY_TYPE git)
set(CPACK_NUGET_PACKAGE_LICENSE_EXPRESSION "MIT")
# Set up dependencies
set(CPACK_NUGET_PACKAGE_TFMS "net4;net6.0")
set(CPACK_NUGET_PACKAGE_DEPENDENCIES_net4 "Foo;Bar")
# NB: If a version number is omitted, the dependency will not be created
set(CPACK_NUGET_PACKAGE_DEPENDENCIES_net4_Foo_VERSION "1.23")
set(CPACK_NUGET_PACKAGE_DEPENDENCIES_net4_Bar_VERSION "4.3.2")
# NB: General dependencies (not framework-specific) go in this variable
set(CPACK_NUGET_PACKAGE_DEPENDENCIES "Baz")
set(CPACK_NUGET_PACKAGE_DEPENDENCIES_Baz_VERSION "9.8.6")
# NB: Since "net6.0" was listed but no dependencies have been specified, an empty group
# will be added to the nuspec file for this framework. This can be used to address warning NU5128.

include(CPack)

CPack PackageMaker Generator 💀

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 (see cpack_gen:CPack productbuild Generator) instead — it's the glow-up, fr fr.

CPack productbuild Generator 🍎

Added in version 3.7.

productbuild CPack generator (macOS) — the main character of macOS packaging ✨

Variables specific to CPack productbuild generator

The following variable is specific to installers built on Mac macOS using ProductBuild 🧚

CPACK_COMMAND_PRODUCTBUILD

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

CPACK_PRODUCTBUILD_IDENTIFIER

Added in version 3.23.

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.

CPACK_PRODUCTBUILD_IDENTITY_NAME

Added in version 3.8.

Adds a digital signature to the resulting package ✍️

CPACK_PRODUCTBUILD_KEYCHAIN_PATH

Added in version 3.8.

Specify a specific keychain to search for the signing identity 🔑

CPACK_COMMAND_PKGBUILD

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

CPACK_PKGBUILD_IDENTITY_NAME

Added in version 3.8.

Adds a digital signature to the resulting package ✍️ (yes, this one's for pkgbuild, keep up bestie 😌)

CPACK_PKGBUILD_KEYCHAIN_PATH

Added in version 3.8.

Specify a specific keychain to search for the signing identity 🔑

CPACK_PREFLIGHT_<COMP>_SCRIPT

Full path to a file that will be used as the preinstall script for the named <COMP> component's package, where <COMP> is the uppercased component name 🎬 No preinstall script is added if this variable is not defined for a given component — so it's opt-in only, no surprise scripts.

CPACK_POSTFLIGHT_<COMP>_SCRIPT

Full path to a file that will be used as the postinstall script for the named <COMP> component's package, where <COMP> is the uppercased component name 🎬 No postinstall script is added if this variable is not defined for a given component.

CPACK_PRODUCTBUILD_RESOURCES_DIR

Added in version 3.9.

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 (see variable:CPACK_RESOURCE_FILE_WELCOME), CPACK_RESOURCE_FILE_README (see variable:CPACK_RESOURCE_FILE_README), and CPACK_RESOURCE_FILE_LICENSE (see variable:CPACK_RESOURCE_FILE_LICENSE) files are copied. Order matters, iykyk 💅

CPACK_PRODUCTBUILD_DOMAINS

Added in version 3.23.

This option enables more granular control over where the product may be installed 🗺️ When it is set to true (see policy CMP0161, <#policy:CMP0161>), 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 🎛️

CPACK_PRODUCTBUILD_DOMAINS_ANYWHERE

Added in version 3.23.

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.

Heads up bestie: CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect. Otherwise it's just gonna sit there doing nothing 🙈

CPACK_PRODUCTBUILD_DOMAINS_USER

Added in version 3.23.

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:

  • The installer may not write outside the user's home directory 🚫
  • The install will be performed as the current user rather than as root. This may have ramifications for CPACK_PREFLIGHT_<COMP>_SCRIPT and CPACK_POSTFLIGHT_<COMP>_SCRIPT ⚠️
  • Administrative privileges will not be needed to perform the install 🙌
Again: CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect. No cap 💀
  • CPACK_PRODUCTBUILD_DOMAINS_ROOT — added in version 3.23. This one's here to override the enable_localSystem attribute inside the domains element of the Distribution XML. Set it to true and the product can be installed in the root directory. Bestie, you normally want this set to true unless the product should only be installed into the user's home directory. 🏠
Heads up: CPACK_PRODUCTBUILD_DOMAINS must be set to true for this variable to have any effect at all. No domains, no root, periodt. 💅

🎨 Background Image

Added in version 3.17.

This whole little group of variables controls the background image of the generated installer — yes, the aesthetic matters, this is the main character of your .pkg ✨

  • CPACK_PRODUCTBUILD_BACKGROUND — adds a background to the Distribution XML if you specify it. The value holds the path to the image in the Resources directory. 🖼️
  • CPACK_PRODUCTBUILD_BACKGROUND_ALIGNMENT — adds an alignment attribute to the background in the Distribution XML. Peep Apple's docs for the valid values, iykyk. 📐
  • CPACK_PRODUCTBUILD_BACKGROUND_SCALING — adds a scaling attribute to the background in the Distribution XML. Again, valid values live in Apple's documentation. 🔍
  • CPACK_PRODUCTBUILD_BACKGROUND_MIME_TYPE — adds a mime-type attribute to the background in the Distribution XML. The option contains the MIME type of the image. 🏷️
  • CPACK_PRODUCTBUILD_BACKGROUND_UTI — adds an uti attribute to the background in the Distribution XML. The option contains the UTI type of the image. 🔖
  • CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA — adds a background for the Dark Aqua theme to the Distribution XML if specified. The value contains the path to the image in the Resources directory. 🌙
  • CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_ALIGNMENT — does the same as CPACK_PRODUCTBUILD_BACKGROUND_ALIGNMENT, but for the dark theme. 🌚
  • CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_SCALING — does the same as CPACK_PRODUCTBUILD_BACKGROUND_SCALING, but for the dark theme. 🌚
  • CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_MIME_TYPE — does the same as CPACK_PRODUCTBUILD_BACKGROUND_MIME_TYPE, but for the dark theme. 🌚
  • CPACK_PRODUCTBUILD_BACKGROUND_DARKAQUA_UTI — does the same as CPACK_PRODUCTBUILD_BACKGROUND_UTI, but for the dark theme. 🌚

📜 Distribution XML Template

CPack uses a template file to generate the distribution.dist file that this package generator uses internally. Normally CMake hands you the template file, but projects can totally supply their own — just drop a file named CPack.distribution.dist.in into one of the directories listed in the CMAKE_MODULE_PATH variable and CPack will pick up your template instead of using its own. 🫶

The distribution.dist file gets generated by doing substitutions similar to what the configure_file() command does. Any variable that's set when CPack runs is available for substitution using the usual @...@ form. The following variables are also set internally and made available for substitution:

  • CPACK_RESOURCE_FILE_LICENSE_NOPATH — same as CPACK_RESOURCE_FILE_LICENSE except without the path. The named file will be available in the same directory as the generated distribution.dist file. 📄
  • CPACK_RESOURCE_FILE_README_NOPATH — same as CPACK_RESOURCE_FILE_README except without the path. The named file will be available in the same directory as the generated distribution.dist file. 📄
  • CPACK_RESOURCE_FILE_WELCOME_NOPATH — same as CPACK_RESOURCE_FILE_WELCOME except without the path. The named file will be available in the same directory as the generated distribution.dist file. 📄
  • CPACK_APPLE_PKG_INSTALLER_CONTENT — added in version 3.23. This one contains all the XML elements that specify installer-wide options (including domain details), default backgrounds and the choices outline. 👑
  • CPACK_PACKAGEMAKER_CHOICES — deprecated since version 3.23 💀. 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. Like, please, it's right there.

📦 CPack RPM Generator

The built in (binary) CPack RPM generator (Unix only, bestie — Unix only). 🐧

🛠️ Variables specific to CPack RPM generator

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: the <COMPONENT> part of variables is preferred to be in upper case (e.g. if the component is named foo then use the 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 — like a vintage find at the thrift store, no cap:

List of CPack RPM generator specific variables:

  • CPACK_RPM_COMPONENT_INSTALL — enable component packaging for the CPack RPM generator.
    • Mandatory: No
    • Default: OFF
    • If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated. 🎁
  • CPACK_RPM_PACKAGE_SUMMARY, CPACK_RPM_<component>_PACKAGE_SUMMARY — the RPM package summary.
    • Mandatory: Yes
    • Default: CPACK_PACKAGE_DESCRIPTION_SUMMARY
    • Added in version 3.2: per-component CPACK_RPM_<component>_PACKAGE_SUMMARY variables. ✨
  • CPACK_RPM_PACKAGE_NAME, CPACK_RPM_<component>_PACKAGE_NAME — the RPM package name.
    • Mandatory: Yes
    • Default: CPACK_PACKAGE_NAME
    • Added in version 3.5: per-component CPACK_RPM_<component>_PACKAGE_NAME variables. ✨
  • CPACK_RPM_FILE_NAME, CPACK_RPM_<component>_FILE_NAME — added in version 3.6. Package file name.
    • Mandatory: Yes
    • Default: <CPACK_PACKAGE_FILE_NAME>[-<component>].rpm with spaces replaced by -
    • This may be set to:
      • RPM-DEFAULT — tell rpmbuild to automatically generate the package file name. 🤖
      • <file-name>[.rpm] — use the given file name.
        • Changed in version 3.29: the .rpm suffix will be automatically added if missing. Previously the suffix was required. 🎀
Note: by using a user-provided spec file, rpm macro extensions such as for generating debuginfo packages, or by simply using multiple components, more than one rpm file may be generated — either from a single spec file or from multiple spec files (each component execution produces its own spec file). In such cases duplicate file names may occur as a result of this variable setting or spec file content structure. Duplicate files get overwritten and it is up to the packager to set the variables in a manner that will prevent such errors. ⚠️ Like, please don't let that be you.
  • CPACK_RPM_MAIN_COMPONENT — added in version 3.8. Main component that is packaged without component suffix.
    • Mandatory: No
    • Default: (empty)
    • This variable can be set to any component or group name so that the component or group rpm package is generated without a component suffix in the filename and package name. 👑
  • CPACK_RPM_PACKAGE_EPOCH — added in version 3.10. The RPM package epoch.
    • Mandatory: No
    • Default: (empty)
    • Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages. 🔢
  • CPACK_RPM_PACKAGE_VERSION — the RPM package version.
    • Mandatory: Yes
    • Default: CPACK_PACKAGE_VERSION
  • CPACK_RPM_PACKAGE_ARCHITECTURE, CPACK_RPM_<component>_PACKAGE_ARCHITECTURE — the RPM package architecture.
    • Mandatory: Yes
    • Default: native architecture output by uname -m
    • This may be set to noarch if you know you are building a noarch package. 🦋
    • Added in version 3.3: per-component CPACK_RPM_<component>_PACKAGE_ARCHITECTURE variables.
  • 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 a fancy Linux distro specific numbering here. 💅
Note: this is the string that goes into the RPM Release: field. Some distros (e.g. Fedora, CentOS) require 1%{?dist} format and not just a number. The %{?dist} part can be added by setting CPACK_RPM_PACKAGE_RELEASE_DIST. 📌
  • CPACK_RPM_PACKAGE_RELEASE_DIST — added in version 3.6. The dist tag that is added to the RPM Release: field. 🏷️

CPACK_RPM_PACKAGE_RELEASE_DIST</p> (the %{dist} one 👀)

Mandatory — No

Default — OFF

okay so this one is literally just the reported %{dist} tag from the current distribution, or an empty %{dist} if the RPM macro isn't set. And if you do set this variable, the RPM Release: field value gets set to:

${CPACK_RPM_PACKAGE_RELEASE}%{?dist}

slay, that's it, that's the whole vibe 💅

CPACK_RPM_PACKAGE_LICENSE</p>

The RPM package license policy. yes bestie, the legal bit 🎀

Mandatory — Yes

Default — "unknown"

CPACK_RPM_PACKAGE_GROUP</p>

CPACK_RPM_<component>_PACKAGE_GROUP</p>

The RPM package group. grouping is self-care fr fr 💜

Mandatory — Yes

Default — "unknown"

Added in version 3.5: Per-component CPACK_RPM_<component>_PACKAGE_GROUP variables. so you can group per-component too, iconic ✨

CPACK_RPM_PACKAGE_VENDOR</p>

The RPM package vendor. who's shipping this masterpiece 🔥

Mandatory — Yes

Default — CPACK_PACKAGE_VENDOR if set, or "unknown"

CPACK_RPM_PACKAGE_URL</p>

CPACK_RPM_<component>_PACKAGE_URL</p>

The project's URL. drop the link bestie 🌈

Mandatory — No

Default — CMAKE_PROJECT_HOMEPAGE_URL

Added in version 3.12: The CMAKE_PROJECT_HOMEPAGE_URL variable. she's new, she's cute 🦋

CPACK_RPM_PACKAGE_DESCRIPTION</p>

CPACK_RPM_<component>_PACKAGE_DESCRIPTION</p>

RPM package description. tell them what it is 💖

Mandatory — Yes

Default — literally a priority list, in this exact order:

  • CPACK_COMPONENT_<compName>_DESCRIPTION (component based installers only) if set,
  • CPACK_PACKAGE_DESCRIPTION_FILE if set, or
  • no package description available
Added in version 3.2: Per-component CPACK_RPM_<component>_PACKAGE_DESCRIPTION variables. per-component desc, we love to see it 🌸

CPACK_RPM_COMPRESSION_TYPE</p>

RPM compression type. the way your package gets squished 🫶

Mandatory — No

Default — (system default)

May be used to override the RPM compression type used to build the RPM. For example some Linux distributions default to xz or zstd. Using this, one can specify a specific compression type to be used.

Possible values are:

  • lzma — Lempel-Ziv-Markov chain algorithm
  • xz — XZ Utils LZMA2 (Lempel-Ziv-Markov chain algorithm, version 2) compression
  • bzip2 — bzip2 Burrows-Wheeler algorithm
  • gzip — GNU Gzip Deflate compression
  • zstd — Added in version 3.31. Zstandard compression

pick your fighter, they're all valid 💀

CPACK_RPM_PACKAGE_AUTOREQ</p>

CPACK_RPM_<component>_PACKAGE_AUTOREQ</p>

RPM spec autoreq field.

Mandatory — No

Default — (empty, no default value)

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

Note: By default automatic dependency detection is enabled by rpm generator. so if you don't touch it, it's already on, no cap 🔥

CPACK_RPM_PACKAGE_AUTOPROV</p>

CPACK_RPM_<component>_PACKAGE_AUTOPROV</p>

RPM spec autoprov field.

Mandatory — No

Default — (empty, no default value)

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 the provides list.

Note: By default automatic provides detection is enabled by rpm generator. again, already slaying on its own 💅

CPACK_RPM_PACKAGE_AUTOREQPROV</p>

CPACK_RPM_<component>_PACKAGE_AUTOREQPROV</p>

RPM spec autoreqprov field.

Mandatory — No

Default — (empty, no default value)

Variable enables/disables autoreq and autoprov at the same time. See CPACK_RPM_PACKAGE_AUTOREQ and CPACK_RPM_PACKAGE_AUTOPROV for more details. two birds, one variable, efficiency queen 👑

Note: By default automatic detection feature is enabled by rpm. periodt.

CPACK_RPM_PACKAGE_REQUIRES</p>

CPACK_RPM_<component>_PACKAGE_REQUIRES</p>

RPM spec requires field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM dependencies (requires). Note that you must enclose the entire value between quotes when setting this variable, 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

quote the whole thing or it will not work, i don't make the rules 😭

CPACK_RPM_PACKAGE_CONFLICTS</p>

CPACK_RPM_<component>_PACKAGE_CONFLICTS</p>

RPM spec conflicts field.

Mandatory — No

Default — (empty, no default value)

May be used to set negative RPM dependencies (conflicts). Note that you must enclose the entire value between quotes when setting this variable, 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

drama between packages, honestly 💀

CPACK_RPM_PACKAGE_REQUIRES_PRE</p>

CPACK_RPM_<component>_PACKAGE_REQUIRES_PRE</p>

Added in version 3.2.

RPM spec requires(pre) field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM preinstall dependencies (requires(pre)). Note that you must enclose the entire value between quotes when setting this variable, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")

needs it before the install, main character energy 🎀

CPACK_RPM_PACKAGE_REQUIRES_POST</p>

CPACK_RPM_<component>_PACKAGE_REQUIRES_POST</p>

Added in version 3.2.

RPM spec requires(post) field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM postinstall dependencies (requires(post)). Note that you must enclose the entire value between quotes when setting this variable, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_POST "shadow-utils, initscripts")

needs it after the install, lowkey clingy but valid ✨

CPACK_RPM_PACKAGE_REQUIRES_POSTUN</p>

CPACK_RPM_<component>_PACKAGE_REQUIRES_POSTUN</p>

Added in version 3.2.

RPM spec requires(postun) field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM postuninstall dependencies (requires(postun)). Note that you must enclose the entire value between quotes when setting this variable, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_POSTUN "shadow-utils, initscripts")

needed even on the way out, we love a loyal dependency 🫶

CPACK_RPM_PACKAGE_REQUIRES_PREUN</p>

CPACK_RPM_<component>_PACKAGE_REQUIRES_PREUN</p>

Added in version 3.2.

RPM spec requires(preun) field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM preuninstall dependencies (requires(preun)). Note that you must enclose the entire value between quotes when setting this variable, for example:

set(CPACK_RPM_PACKAGE_REQUIRES_PREUN "shadow-utils, initscripts")

last one of the four, and she ate 🌸

CPACK_RPM_PACKAGE_SUGGESTS</p>

CPACK_RPM_<component>_PACKAGE_SUGGESTS</p>

RPM spec suggests field.

Mandatory — No

Default — (empty, no default value)

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 entire value between quotes when setting this variable.

not a demand, just a suggestion bestie 🙈 and if rpmbuild can't handle it, warning + ignored, no drama

CPACK_RPM_PACKAGE_RECOMMENDS</p>

CPACK_RPM_<component>_PACKAGE_RECOMMENDS</p>

Added in version 4.1.

RPM spec recommends field.

Mandatory — No

Default — (empty, no default value)

May be used to set weak RPM dependencies (recommends). If rpmbuild doesn't support the Recommends tag, CPack will emit a warning and ignore this variable. Note that you must enclose the entire value between quotes when setting this variable.

a little stronger than a suggestion, still chill 💜

CPACK_RPM_PACKAGE_SUPPLEMENTS</p>

CPACK_RPM_<component>_PACKAGE_SUPPLEMENTS</p>

Added in version 4.1.

RPM spec supplements field.

Mandatory — No

Default — (empty, no default value)

May be used to set weak RPM dependencies (supplements). If rpmbuild doesn't support the Supplements tag, CPack will emit a warning and ignore this variable. Note that you must enclose the entire value between quotes when setting this variable.

reverse-flavored weak dep, it's giving "this package enriches that one" 🦋

CPACK_RPM_PACKAGE_ENHANCES</p>

CPACK_RPM_<component>_PACKAGE_ENHANCES</p>

Added in version 4.1.

RPM spec enhances field.

Mandatory — No

Default — (empty, no default value)

May be used to set weak RPM dependencies (enhances). If rpmbuild doesn't support the Enhances tag, CPack will emit a warning and ignore this variable. Note that you must enclose the entire value between quotes when setting this variable.

the fourth and final weak dep, all added in 4.1 like a little squad 🔥

CPACK_RPM_PACKAGE_PROVIDES</p>

CPACK_RPM_<component>_PACKAGE_PROVIDES</p>

RPM spec provides field.

Mandatory — No

Default — (empty, no default value)

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

this is the "what do i actually give you" list, be generous 💅

CPACK_RPM_PACKAGE_OBSOLETES</p>

CPACK_RPM_<component>_PACKAGE_OBSOLETES</p>

RPM spec obsoletes field.

Mandatory — No

Default — (empty, no default value)

May be used to set RPM packages that are obsoleted by this one. out with the old, in with the new, no hard feelings 💀✨

CPACK_RPM_PACKAGE_RELOCATABLE</p>

build a relocatable RPM. she can move wherever she wants 🧚

Mandatory — No

Default — CPACK_PACKAGE_RELOCATABLE

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

careful bestie 😭 — 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 a file installed with an absolute path you'll get unexpected behavior. no cap, that's the actual warning, read it twice.

CPACK_RPM_SPEC_INSTALL_POST</p>

Deprecated since version 2.8.12: Use CPACK_RPM_SPEC_MORE_DEFINE instead.

Mandatory — No

Default — (empty, no default value)

it's giving "old news, use the other one" 🎀 the deprecation is real and this variable knows it.

carry on, bestie — we're still deep in RPM land and honestly it's giving ✨ very detailed ✨ but every single line matters, so let's go 💅

  • CPACK_RPM_SPEC_INSTALL_POST (the continuation above) — 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. 🫶

CPACK_RPM_SPEC_MORE_DEFINE</p>

RPM extended spec definitions lines.

Mandatory

No.

Default

(empty — you set it, girl 💅)

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")
Added in version 4.4: If the variable is a list, its string elements will be concatenated using \n before being substituted into the spec template. Slay, list support 🎀

CPACK_RPM_PACKAGE_DEBUG</p>

Toggle CPack RPM generator debug output.

Mandatory

No.

Default

(empty)

May be set when invoking cpack in order to trace debug information during the 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</p>

CPACK_RPM_<componentName>_USER_BINARY_SPECFILE</p>

A user provided spec file.

Mandatory

No.

Default

(empty)

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

CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE</p>

Spec file template.

Mandatory

No.

Default

(empty)

If set, CPack will generate a template for a 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. (Yes, the original page says "is own" — I'm not fixing the manpage's typos, I'm just the messenger 🫶)

CPACK_RPM_PRE_INSTALL_SCRIPT_FILE</p>

CPACK_RPM_PRE_UNINSTALL_SCRIPT_FILE</p>

CPACK_RPM_PRE_TRANS_SCRIPT_FILE</p>

Path to file containing pre install/uninstall/transaction script.

Mandatory

No.

Default

(empty)

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
Added in version 3.18: The CPACK_RPM_PRE_TRANS_SCRIPT_FILE variable. ✨

CPACK_RPM_POST_INSTALL_SCRIPT_FILE</p>

CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE</p>

CPACK_RPM_POST_TRANS_SCRIPT_FILE</p>

Path to file containing post install/uninstall/transaction script.

Mandatory

No.

Default

(empty)

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
Added in version 3.18: The CPACK_RPM_POST_TRANS_SCRIPT_FILE variable. 💜

CPACK_RPM_USER_FILELIST</p>

CPACK_RPM_<COMPONENT>_USER_FILELIST</p>

Mandatory

No.

Default

(empty)

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

Added in version 3.8: You can have multiple directives per line, as in %attr(600,root,root) %config(noreplace). Periodt. 💅

CPACK_RPM_CHANGELOG_FILE</p>

RPM changelog file.

Mandatory

No.

Default

(empty)

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

CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST</p>

List of paths to be excluded.

Mandatory

No.

Default

The following paths are excluded by default:

  • /etc
  • /etc/init.d
  • /usr
  • /usr/bin
  • /usr/include
  • /usr/lib
  • /usr/libx32
  • /usr/lib64
  • /usr/share
  • /usr/share/aclocal
  • /usr/share/doc

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 (that's the manpage's wording, not mine, bestie 😭). If you want to add some path to the default list then you can use the CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.

Added in version 3.10: Added /usr/share/aclocal to the default list of excludes. 🌸

CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION</p>

Additional list of paths to be excluded.

Mandatory

No.

Default

(empty)

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

CPACK_RPM_RELOCATION_PATHS</p>

Added in version 3.2.

Packages relocation paths list.

Mandatory

No.

Default

(empty)

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

CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX</p>

Added in version 3.2.

Per component relocation path install prefix.

Mandatory

No.

Default

CPACK_PACKAGING_INSTALL_PREFIX

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

CPACK_RPM_NO_INSTALL_PREFIX_RELOCATION</p>

CPACK_RPM_NO_<COMPONENT>_INSTALL_PREFIX_RELOCATION</p>

Added in version 3.3.

Removal of default install prefix from relocation paths list.

Mandatory

No.

Default

CPACK_PACKAGING_INSTALL_PREFIX or CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX are treated as one of relocation paths.

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

CPACK_RPM_ADDITIONAL_MAN_DIRS</p>

Added in version 3.3.

Mandatory

No.

Default

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

  • /usr/man/man.*
  • /usr/man/.*/man.*
  • /usr/info.*
  • /usr/share/man/man.*
  • /usr/share/man/.*/man.*
  • /usr/share/info.*
  • /usr/kerberos/man.*
  • /usr/X11R6/man/man.*
  • /usr/lib/perl5/man/man.*
  • /usr/share/doc/.*/man/man.*
  • /usr/lib/.*/man/man.*

May be used to set additional man dirs that could potentially be compressed by the 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 the brp-compress RPM script and that the brp-compress script must be added to RPM configuration by the operating system. 🍓

CPACK_RPM_DEFAULT_USER</p>

CPACK_RPM_<compName>_DEFAULT_USER</p>

Added in version 3.6.

Default user ownership of RPM content.

Mandatory

No.

Default

root

Value should be the user name and not the UID, bestie 😭 like please do not put numbers there. And <compName> has to be in UPPER-CASE 💅.

  • CPACK_RPM_DEFAULT_GROUP
  • CPACK_RPM_<compName>_DEFAULT_GROUP — Added in version 3.6.

okay so this one is the default group ownership of your RPM content 🎀

  • Mandatory — No 🙅
  • Default — root 👑

Value should be the group name, not the GID — same deal as above, no numbers. And yeah, <compName> must be in upper-case.

  • CPACK_RPM_DEFAULT_FILE_PERMISSIONS
  • CPACK_RPM_<compName>_DEFAULT_FILE_PERMISSIONS — Added in version 3.6.

the default permissions used for packaged files 🔐

  • Mandatory — No
  • Default — (system default) 🌱

Accepted values are lists with PERMISSIONS. Valid permissions are literally these and only these:

  • OWNER_READ
  • OWNER_WRITE
  • OWNER_EXECUTE
  • GROUP_READ
  • GROUP_WRITE
  • GROUP_EXECUTE
  • WORLD_READ
  • WORLD_WRITE
  • WORLD_EXECUTE

And <compName> must be in upper-case, periodt.

  • CPACK_RPM_DEFAULT_DIR_PERMISSIONS
  • CPACK_RPM_<compName>_DEFAULT_DIR_PERMISSIONS — Added in version 3.6.

the default permissions used for packaged directories 📁 (yes it's a separate variable from files, don't @ me)

  • Mandatory — No
  • Default — (system default) 🌱

Accepted values are lists with PERMISSIONS, and the valid permissions are the same as for CPACK_RPM_DEFAULT_FILE_PERMISSIONS. Again: <compName> in upper-case, bestie 💅.

  • CPACK_RPM_INSTALL_WITH_EXEC — Added in version 3.11.

force execute permissions on programs and shared libraries ⚡

  • Mandatory — No
  • Default — (system default)

This forces owner, group and world execute permissions onto programs and shared libraries. The whole reason it exists is so you can create valid rpm packages on systems like Debian where shared libraries don't have execute permissions set 🫶 iconic of them honestly.

Note: Programs and shared libraries without execute permissions are ignored during separation of debug symbols from the binary for debuginfo packages 😭 so keep that in mind.

Added in version 3.3.

The CPack RPM generator supports packaging of symbolic links, slay 🔗💖

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 get shortened if possible) before being added to the package — or, if multiple relocation paths are detected, a post install symlink relocation script gets generated ✨.

Symbolic links may point to locations that are not packaged by the same package (whether that's a different component or literally not packaged at all), but those locations will be treated as if they were a part of the package while determining whether the symlink should be created or present in a post install script — depending on relocation paths, iykyk 🧚

Changed in version 3.6: symbolic links that point to locations outside the packaging path produce a warning and get treated as non relocatable permanent symbolic links. Previous versions of CMake produced an error in this case 💀.

Currently there are a few limitations though:

  • For component based packaging, component interdependency is not checked when processing symbolic links 🫠. Symbolic links pointing to content of a different component are treated the same way as if pointing to a location that will not be packaged.
  • Symbolic links pointing to a location through one or more intermediate symbolic links will not be handled differently — if the intermediate symlink(s) is also on a relocatable path, relocating it during package installation may cause the initial symbolic link to point to an invalid location 😭.

🌸 Packaging of debug information 🌸

Added in version 3.7.

Debuginfo packages contain debug symbols and sources for debugging packaged binaries 🔍✨

Debuginfo RPM packaging has its own set of variables, bestie:

  • CPACK_RPM_DEBUGINFO_PACKAGE
  • CPACK_RPM_<component>_DEBUGINFO_PACKAGE

Enable generation of debuginfo RPM package(s)</cornflower> 📦

  • Mandatory — No
  • Default — OFF
Note: Binaries must contain debug symbols before packaging, so use either Debug or RelWithDebInfo for the CMAKE_BUILD_TYPE <#variable:CMAKE_BUILD_TYPE> variable value 🫶
Additionally, if CPACK_STRIP_FILES <#variable:CPACK_STRIP_FILES> is set, the files will be stripped before they even get to the RPM generator — so they won't contain debug symbols and a debuginfo package will not get built. Do not use with CPACK_STRIP_FILES <#variable:CPACK_STRIP_FILES> 💀
Note: Packages generated from packages without binary files, with binary files but without execute permissions, or without debug symbols will cause packaging termination 😭 like it just stops.
  • CPACK_BUILD_SOURCE_DIRS

Provides locations of root directories of source files from which binaries were built 🏗️

  • Mandatory — Yes if CPACK_RPM_DEBUGINFO_PACKAGE is set
  • Default —
Note: For a CMake project, CPACK_BUILD_SOURCE_DIRS is set by default to point at the CMAKE_SOURCE_DIR <#variable:CMAKE_SOURCE_DIR> and CMAKE_BINARY_DIR <#variable:CMAKE_BINARY_DIR> paths 🎀
Note: Sources with path prefixes that do not fall under any location provided with CPACK_BUILD_SOURCE_DIRS will not be present in the debuginfo package 🙈
  • CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX
  • CPACK_RPM_<component>_BUILD_SOURCE_DIRS_PREFIX

Prefix of the location where sources will be placed during package installation 📍

  • Mandatory — Yes if CPACK_RPM_DEBUGINFO_PACKAGE is set
  • Default — /usr/src/debug/${CPACK_PACKAGE_FILE_NAME} and, for component packaging, /usr/src/debug/${CPACK_PACKAGE_FILE_NAME}-<component>
Note: Each source path prefix is additionally suffixed by src_<index> where index is the index of the path used from the CPACK_BUILD_SOURCE_DIRS variable 😮‍💨. This produces the ${CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX}/src_<index> replacement path. The limitation is that the replaced path part must be shorter or of equal length than the length of its replacement 💅. If that's not the case, either set CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX to a shorter path or place your source directories on a longer path 🫠
  • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS

Directories containing sources that should be excluded from debuginfo packages 🚫

  • Mandatory — No
  • Default —

The following paths are excluded by default:

  • /usr
  • /usr/src
  • /usr/src/debug

Listed paths are owned by other RPM packages and should therefore not be deleted on debuginfo package uninstallation 😭 (please, they're not yours)

  • CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS_ADDITION

Paths that should be appended to CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS for exclusion ➕

  • Mandatory — No
  • Default —
  • CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE — Added in version 3.8.

Create a single debuginfo package even if components packaging is set 👑✨

  • Mandatory — No
  • Default — OFF

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

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

Note: If none of the CPACK_RPM_<component>_DEBUGINFO_PACKAGE variables is set, then CPACK_RPM_DEBUGINFO_PACKAGE is automatically set to ON when CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE is set 🌈
  • CPACK_RPM_DEBUGINFO_FILE_NAME
  • CPACK_RPM_<component>_DEBUGINFO_FILE_NAME — Added in version 3.9.

Debuginfo package file name 🏷️

  • Mandatory — No
  • Default — rpmbuild tool generated package file name

If you provide an alternative debuginfo package file name it must end with the .rpm suffix and should differ from the file names of other generated packages 👀

The variable may contain the @cpack_component@ placeholder, which gets replaced by the 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: CPACK_RPM_FILE_NAME also supports the rpmbuild tool generated package file name — disabled by default, but it can be enabled by setting that variable to RPM-DEFAULT 🎀

🧚 Packaging of sources (SRPM) 🧚

Added in version 3.7.

SRPM packaging is enabled by setting the CPACK_RPM_PACKAGE_SOURCES variable while usually using the CPACK_INSTALLED_DIRECTORIES <#variable:CPACK_INSTALLED_DIRECTORIES> variable to provide the directory containing CMakeLists.txt and source files 🫶

For CMake projects an SRPM package would be produced by executing:

cpack -G RPM --config ./CPackSourceConfig.cmake
Note: The produced SRPM package is expected to be built with the cmake(1) <#manual:cmake(1)> executable and packaged with the cpack(1) <#manual:cpack(1)> executable — so CMakeLists.txt has to be located in the root source directory and must be able to generate binary rpm packages by executing the cpack -G <#cmdoption-cpack-G> command 😮‍💨. Both of those executables, plus rpmbuild, must also be present when generating binary rpm packages from the produced SRPM package 🎀

Once the SRPM package is generated it can be used to generate binary packages by creating a directory structure for rpm generation and executing the 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 the build_dir/RPMS directory or its sub directories 🎉✨

Note: SRPM packages internally use the CPack/RPM generator to generate binary packages, so CMakeScripts.txt can decide during the SRPM → binary rpm generation step what content the package(s) should have, and also how they should be packaged (monolithic or components). CMake can figure this out by, like, reading environment variables that the package manager sets before it starts generating binary rpm packages. That way a single SRPM package can produce different binary rpm packages on different platforms, depending on that platform's packaging rules. 💅

Source RPM packaging has its own little set of variables, bestie:

  • CPACK_RPM_PACKAGE_SOURCES — should the content be packaged as a source rpm? (default is binary rpm)
    • Mandatory: No
    • Default: OFF
Note: for cmake projects, the CPACK_RPM_PACKAGE_SOURCES variable is set to OFF in the generated CPackConfig.cmake file, and ON in the generated CPackSourceConfig.cmake file. 🫶
  • CPACK_RPM_SOURCE_PKG_BUILD_PARAMS — extra command-line parameters handed to the cmake(1) executable.
    • Mandatory: No
    • Default: (empty)
  • CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX — the packaging install prefix that gets put into the CPACK_PACKAGING_INSTALL_PREFIX variable when producing binary RPM packages.
    • Mandatory: Yes
    • Default: /
  • CPACK_RPM_BUILDREQUIRES — list of source rpm build dependencies.
    • Mandatory: No
    • Default: (empty)
    • May be used to set source RPM build dependencies (BuildRequires). Lowkey important: you must enclose the entire value between quotes when you set this variable, like so:
set(CPACK_RPM_BUILDREQUIRES "python >= 2.5.0, cmake >= 2.8")
  • CPACK_RPM_REQUIRES_EXCLUDE_FROM — added in version 3.22.
    • Mandatory: No
    • Default: (empty)
    • May be used to keep the dependency generator from scanning specific files or directories for dependencies. Ngl 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 🎀

Use the WiX Toolset (https://www.firegiant.com/wixtoolset/) to produce a Windows Installer .msi database. Obsessed, honestly.

Added in version 3.7: the CPACK_COMPONENT_<compName>_DISABLED variable is now supported. ✨

🦋 WiX Toolsets

CPack picks one of the following variants of the WiX Toolset based on the CPACK_WIX_VERSION variable:

  • WiX .NET Tools
  • WiX Toolset v3

💜 WiX .NET Tools

Packaging is performed using the following tools:

  • wix build — builds WiX source files directly into a Windows Installer .msi database.
    • Invocations may be customized using tool-specific variables:
      • CPACK_WIX_BUILD_EXTENSIONS
      • CPACK_WIX_BUILD_EXTRA_FLAGS

WiX extensions must be named with the form WixToolset.<Name>.wixext.

CPack expects the wix .NET tool to be available for command-line use with any required WiX extensions already installed. Be sure the wix version is compatible with CPACK_WIX_VERSION, and that WiX extension versions match the wix tool version. For example:

  1. Install the wix command-line tool using dotnet. To install wix globally for the current user:
dotnet tool install --global wix --version 4.0.4

This places wix.exe in %USERPROFILE%\.dotnet\tools and adds the directory to the current user's PATH environment variable.

Or, to install wix in a specific path, e.g., in c:\WiX:

dotnet tool install --tool-path c:\WiX wix --version 4.0.4

This places wix.exe in c:\WiX, but does not add it to the current user's PATH environment variable. The WIX environment variable may be set to tell CPack where to find the tool, e.g., set WIX=c:\WiX. 🫶

  1. Add the WiX UI extension, needed by CPack's default WiX template:
wix extension add --global WixToolset.UI.wixext/4.0.4

Extensions added globally are stored in %USERPROFILE%\.wix, or if the WIX_EXTENSIONS environment variable is set, in %WIX_EXTENSIONS%\.wix.

🌈 WiX Toolset v3

Packaging is performed using the following tools:

  • candle — compiles WiX source files into .wixobj files.
    • Invocations may be customized using tool-specific variables:
      • CPACK_WIX_CANDLE_EXTENSIONS
      • CPACK_WIX_CANDLE_EXTRA_FLAGS
  • light — links .wixobj files into a Windows Installer .msi database.
    • Invocations may be customized using tool-specific variables:
      • CPACK_WIX_LIGHT_EXTENSIONS
      • CPACK_WIX_LIGHT_EXTRA_FLAGS

CPack invokes both tools as needed. Intermediate .wixobj files are considered implementation details (so like, don't come for them 💀).

WiX extensions must be named with the form Wix<Name>Extension.

CPack expects the above tools to be available for command-line use via the PATH. Or, if the WIX environment variable is set, CPack looks for the tools in %WIX% and %WIX%\bin.

🌸 Variables specific to CPack WIX generator

The following variables are specific to the installers built on Windows using WiX. 👑

  • CPACK_WIX_VERSION — added in version 3.30. Specify the version of WiX Toolset for which the configuration is written. The value must be one of:
    • 4 — package using WiX .NET Tools.
    • 3 — package using WiX Toolset v3. This is the default.
  • CPACK_WIX_UPGRADE_GUID — Upgrade GUID (Product/@UpgradeCode).
    • Will be automatically generated unless explicitly provided.
    • It should be explicitly set to a constant generated globally unique identifier (GUID) to allow your installers to replace 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. (fr fr, don't do it 🙈)
    • 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 a .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.
  • CPACK_WIX_PRODUCT_ICON — the icon shown next to the program name in Add/Remove programs.
    • If set, this icon is used in place of the default icon.
  • CPACK_WIX_UI_REF — specify the WiX UI extension's dialog set:
    • With WiX .NET Tools, this is the Id of the <ui:WixUI> element in the default WiX template.
    • With WiX Toolset v3, this is the Id of the <UIRef> element in the default WiX template.
    • The default is WixUI_InstallDir in case no CPack components have been defined, and WixUI_FeatureTree otherwise.
  • CPACK_WIX_UI_BANNER — the bitmap will appear at the top of all installer pages other than the welcome and completion dialogs.
    • If set, this image will replace the default banner image.
    • This image must be 493 by 58 pixels.
  • CPACK_WIX_UI_DIALOG — background bitmap used on the welcome and completion dialogs.
    • If this variable is set, the installer will replace the default dialog image.
    • This image must be 493 by 312 pixels.
  • CPACK_WIX_PROGRAM_MENU_FOLDER — start menu folder name for launcher.
    • If this variable is not set, it will be initialized with CPACK_PACKAGE_NAME.
    • Added 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.
  • CPACK_WIX_CULTURES — language(s) of the installer.
    • Languages are compiled into the Wix UI 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://docs.firegiant.com/wix3/wixui/wixui_localization/
  • 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. The template contents will override the effect of most CPACK_WIX_ variables.
    • If this variable is not set, the default MSI template included with CMake will be used.
  • CPACK_WIX_PATCH_FILE — optional list of XML files with fragments to be inserted into generated WiX sources.
    • Added 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. 🧚

Added in version 3.3: the following extra special Ids are also fair game 🎀

  • #PRODUCT — for the <Product> element
  • #PRODUCTFEATURE — for the root <Feature> element

Added in version 3.7: you can also patch arbitrary <Feature> elements. Yes bestie, go off 💅

Added in version 3.9: setting additional attributes is allowed too ✨

Okay so here's an example that makes it all click. Say the WIX generator spits out this XML element:

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

Then this XML patch file right here would 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>

Iconic. Obsessed. 🦋

CPACK_WIX_EXTRA_SOURCES

Extra WiX source files 💖

This one gives you an optional list of extra WiX source files (.wxs) that should get compiled and linked. Heads up though: the paths must be absolute. No relative-path chaos, okay?

CPACK_WIX_EXTRA_OBJECTS

Extra WiX object files or libraries to use with WiX Toolset v3 ✨

This variable hands over an optional list of extra WiX object (.wixobj) and/or WiX library (.wixlib) files. And yes — again, the paths must be absolute 🫶

CPACK_WIX_EXTENSIONS

Lets you specify a list of additional extensions for WiX tools. Peep WiX Toolsets for the extension naming patterns 👑

CPACK_WIX_<TOOL>_EXTENSIONS

Specifies a list of additional extensions for one specific WiX tool. Check WiX Toolsets for the possible <TOOL> names 🎀

CPACK_WIX_<TOOL>_EXTRA_FLAGS

Specifies a list of additional command-line flags for one specific WiX tool. Again, WiX Toolsets has the possible <TOOL> names 💅

Use it at your own risk, fr fr. Future versions of CPack might generate flags that conflict with your own flags — and then it's giving chaos 😭

CPACK_WIX_CMAKE_PACKAGE_REGISTRY

If you set this variable, the generated installer will create an entry in this Windows registry key:

HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<PackageName>

The value for <PackageName> is provided by this very variable 🌸

So assuming you also install a CMake configuration file, this lets other CMake projects find your package with the find_package() command. Networking, but for builds 🫶

CPACK_WIX_PROPERTY_<PROPERTY>

Added in version 3.1 ⭐

This variable lets you provide a value for the Windows Installer property <PROPERTY>.

Here's a lil list of example properties you can use to customize the info under "Programs and Features" (also known as "Add or Remove Programs"):

  • ARPCOMMENTS — Comments
  • ARPHELPLINK — Help and support information URL
  • ARPURLINFOABOUT — General information URL
  • ARPURLUPDATEINFO — Update information URL
  • ARPHELPTELEPHONE — Help and support telephone number
  • ARPSIZE — Size (in kilobytes) of the application

CPACK_WIX_ROOT_FEATURE_TITLE

Added in version 3.7 💜

Sets the name of the root install feature in the WIX installer. Same energy as CPACK_COMPONENT_<compName>_DISPLAY_NAME, but for components. Glow-up, but make it features ✨

CPACK_WIX_ROOT_FEATURE_DESCRIPTION

Added in version 3.7 💜

Sets the description of the root install feature in the WIX installer. Same as CPACK_COMPONENT_<compName>_DESCRIPTION for components. Matching set, we love to see it 🎀

CPACK_WIX_SKIP_PROGRAM_FOLDER

Added in version 3.7 🦋

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

Note: installers created with this feature do not take differences between the system on which the installer is created and the system on which the installer might be used into account. 😭 Which means it's totally possible that the installer, like, might try to install onto a drive that's unavailable or unintended, or onto a path that doesn't follow the localization or convention of the system where the installation is actually performed. Main character energy but make it risky 💀

CPACK_WIX_ROOT_FOLDER_ID

Added in version 3.9 🌈

This variable lets you specify 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 expands to empty, while in 64-bit builds it expands to 64 ⭐

When it's unset, generated installers will install to LocalAppDataFolder if CPACK_WIX_INSTALL_SCOPE is perUser, and to ProgramFiles<64>Folder otherwise 🫶

CPACK_WIX_ROOT

You can optionally set this to the root directory of a custom WiX Toolset installation.

When it's unspecified, CPack will try to locate a WiX Toolset installation via the WIX environment variable instead. Detective mode 👑🔍

CPACK_WIX_CUSTOM_XMLNS

Added in version 3.19 💖

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 lives here: https://docs.firegiant.com/wix3/xsd/ ✨

CPACK_WIX_SKIP_WIX_UI_EXTENSION

Added in version 3.23 🎀

If you set this to true, the default inclusion of the WiX UI extension gets skipped — meaning the -ext WixUIExtension or -ext WixToolset.UI.wixext flag is not passed to the WiX tools. Bye bestie 👋

CPACK_WIX_ARCHITECTURE

Added in version 3.24 🦋

You can optionally set this to specify the target architecture of the installer. It might, for example, be set to x64 or arm64.

When unspecified, CPack defaults to x64 or x86. Slay 💅

CPACK_WIX_INSTALL_SCOPE

Added in version 3.29 🔥

You can optionally set this to specify the InstallScope of the installer (see https://docs.firegiant.com/wix3/xsd/wix/package/):

  • perMachine — creates an installer that installs for all users and requires administrative privileges. Start menu entries created by the installer are visible to all users. This is the default. See policy CMP0172.
  • perUser — creates an installer that installs only for the current user and does not require administrative privileges. Start menu entries created by the installer are visible only to the current user. To enable per-user installation, the installer has to generate some additional registry entries to serve as "key paths" for installed components (see https://learn.microsoft.com/en-us/windows/win32/msi/ice38). These registry entries are created under HKEY_CURRENT_USER, using the path specified by the CPACK_WIX_COMPONENT_KEYS_REGISTRY_PATH variable.
Changed in version 4.3: before CMake 4.3, this value was reserved for future use and not supported 🙈
  • NONE — creates an installer without any InstallScope attribute. This is supported only if CPACK_WIX_VERSION is not set, or is set to 3.
Deprecated since version 3.29: this value exists only for compatibility with the inconsistent behavior used by CPack 3.28 and older. The resulting installer requires administrative privileges and installs into the system-wide ProgramFiles directory, but the start menu entry and uninstaller registration are created only for the current user. 💀
Warning: installations performed by installers created with different InstallScope values cannot be cleanly updated or replaced by each other. For example, to transition a project's installers from NONE to perMachine, or from perMachine to perUser, the latter installer should be distributed with instructions to first manually uninstall any older version. No cap, read this twice 😭🫶

CPACK_WIX_COMPONENT_KEYS_REGISTRY_PATH

Added in version 4.3 🌸

This variable determines the registry path under HKEY_CURRENT_USER where the installer will create registry entries to serve as "key paths" for components — but only if CPACK_WIX_INSTALL_SCOPE is set to perUser.

Use forward slashes (/) as path separators to avoid issues with escapes; the WIX generator will convert them to backslashes (\) for you. Teamwork 💅

The default value is Software/<Vendor>/<PackageName>/Components, where <Vendor> is taken from CPACK_PACKAGE_VENDOR, and <PackageName> is taken from CPACK_PACKAGE_NAME.

Example: Software/MyCompany/MyProduct/Components ⭐

CPACK_WIX_CAB_PER_COMPONENT

Added in version 4.2 🎀

If you set this to true, one .cab file per component gets created. The default is to create a single .cab file for all files in the installer.

WiX creates .cab files in parallel, so multiple .cab files may be desirable for faster packaging. Speed, but make it cab ✨🔥

2000-2026 Kitware, Inc. and Contributors — protect the icons, bestie 👑

And that's a wrap on CPACK-GENERATORS(7)! This page is from source CPack-Generators(7) at version 4.4.5, dated Oct 28, 2026. Go forth and package, you gorgeous genius 🫶💖🌸

📦 where this page comes from