CPack
2025-05-16
CMakeは、ソースコードからプログラムをビルドするための設定（MakefileやVisual Studioのプロジェクトファイルなど）を生成するツールですが、CPackはその次の段階、つまりビルドされたプログラムを配布可能な状態にする役割を担います。
CPackの主な機能と特徴
-
CMakeとの統合: CPackはCMakeプロジェクトに組み込まれており、
CMakeLists.txtファイル内で設定を行うことができます。通常、include(CPack)コマンドをCMakeLists.txtに追加し、必要な変数（プロジェクト名、バージョン、説明など）を設定するだけで、基本的なパッケージを作成できるようになります。 -
ソースコードとバイナリの配布: ビルド済みのバイナリだけでなく、ソースコードをパッケージとして配布することも可能です。
CPackの使用例（簡単な流れ）
-
CMakeLists.txtの編集: プロジェクトの
CMakeLists.txtファイルに、CPackを有効にするための設定を追加します。最低限、以下のような行を追加します。# CPackを有効にする include(CPack) # プロジェクト名とバージョンを設定（CPackが利用します） project(MySoftware VERSION 1.0.0) # インストール対象のファイルを指定 install(TARGETS my_executable DESTINATION bin) install(FILES my_library.dll DESTINATION lib)さらに、
CPACK_PACKAGE_NAME、CPACK_PACKAGE_VERSION、CPACK_GENERATORなどの変数を設定することで、パッケージの詳細や生成するパッケージ形式を制御できます。 -
ビルド: 通常通りCMakeを使ってプロジェクトをビルドします。
cmake -S . -B build cmake --build build -
CPackの実行: ビルドが成功したら、CPackを実行してパッケージを作成します。
cpack --config build/CPackConfig.cmake # または、ビルドシステム経由でパッケージターゲットをビルド cmake --build build --target packageこれにより、指定された形式のパッケージファイルが生成されます。
なぜCPackを使うのか？
- 自動化: ビルドプロセスにパッケージ作成を組み込むことで、手動でのパッケージング作業を省き、エラーを減らすことができます。
- インストールの容易さ: ユーザーが特別な知識なしにソフトウェアをインストールできるようになります。
- クロスプラットフォームな配布: 異なるOS向けに、それぞれ適切な形式でパッケージを作成できるため、配布プロセスが効率化されます。
CPackは非常に便利ですが、設定が複雑になることもあり、エラーに遭遇することも少なくありません。ここでは、よくある問題とその解決策をいくつかご紹介します。
パッケージが生成されない、または期待する形式で生成されない
エラー症状:
- 指定したはずのRPMやDEBなどの形式のファイルが生成されず、代わりにZIPやTGZなど汎用的なアーカイブが生成される。
cpackコマンドを実行しても、何もファイルが生成されない。
原因:
install()コマンドの欠落: CPackは、install()コマンドで指定されたファイルやターゲットをパッケージングします。install()コマンドが正しく記述されていない、または欠落している場合、パッケージする内容がないため、何も生成されません。- 必要なツールがインストールされていない: RPMやDEBなどの特定のパッケージ形式を生成するには、システムにそれらの形式を扱うためのツール（例:
rpmbuild、dpkg-deb）がインストールされている必要があります。 - ジェネレータの未指定または誤指定: CPackは、どの形式のパッケージを生成するかを「ジェネレータ」で指定します。これが正しく設定されていない場合、パッケージが生成されなかったり、デフォルトのジェネレータ（通常はTGZやZIP）が使用されたりします。
トラブルシューティング:
install()コマンドの確認:CMakeLists.txtに、パッケージに含めたいファイルや実行可能ファイルをinstall()コマンドで指定しているか確認します。install(TARGETS my_executable DESTINATION bin) install(FILES "${CMAKE_CURRENT_SOURCE_DIR}/config.ini" DESTINATION share/my_app)- 必要なツールのインストール: 該当するパッケージ形式に対応するツールをシステムにインストールします（例:
sudo apt install rpm、sudo apt install dpkg-dev）。 - ログ出力の確認:
cpackコマンドを冗長モードで実行し、詳細なログを確認します。
ログに「Generator not found」や「Tool not found」のようなメッセージがないか確認します。cpack --verbose CPACK_GENERATOR変数の確認:CMakeLists.txtまたはcpackコマンドラインで、CPACK_GENERATORが正しく設定されているか確認します。set(CPACK_GENERATOR "DEB;RPM") # 複数のジェネレータを指定することも可能cpack -G <GENERATOR_NAME>で指定します。
CPackの設定が見つからない
エラー症状:
cpack --config build/CPackConfig.cmakeを実行すると、「CPackConfig.cmake not found」のようなエラーが出る。
原因:
include(CPack)の欠落:CMakeLists.txtにinclude(CPack)がない場合、CPack関連のファイルは生成されません。- CMakeの実行忘れ:
CPackConfig.cmakeファイルは、cmakeコマンドを実行した際に生成されます。cmakeを一度も実行していないか、実行してもビルドディレクトリが間違っている可能性があります。
トラブルシューティング:
include(CPack)の追加:CMakeLists.txtの適切な場所にinclude(CPack)を追加します。通常は、project()コマンドの後、かつinstall()コマンドの前に記述します。- CMakeの再実行: ビルドディレクトリ（例:
build）でcmake -S . -B buildのように、CMakeを再実行します。
パッケージのインストール後にファイルが見つからない、またはパスが誤っている
エラー症状:
- 実行可能ファイルがライブラリを見つけられない、設定ファイルを読み込めないなど、パスに関する問題が発生する。
- 生成されたインストーラーでソフトウェアをインストールしたが、期待する場所にファイルが配置されていない。
原因:
- 相対パスと絶対パスの混同: CPackやインストーラーが期待するパス形式と、プログラムが実行時に参照するパス形式が異なる。
install()コマンドのDESTINATIONの誤設定:install()コマンドのDESTINATION引数が、インストール先のディレクトリ構造と一致していない。
トラブルシューティング:
CPACK_INSTALL_PREFIXの理解: CPackは、インストーラーのデフォルトのインストールパスをCPACK_INSTALL_PREFIXで設定します。ユーザーがインストーラーでインストールパスを変更しない限り、install()のDESTINATIONは、このプレフィックスの相対パスとして解釈されます。- パスの動的な解決: プログラム内で、設定ファイルやリソースへのパスをハードコードするのではなく、実行時のパス（例:
argv[0]から取得）に基づいて動的に解決するようにします。 install()コマンドのDESTINATIONの確認: インストール後のディレクトリ構造をよく考慮し、DESTINATIONを正しく設定します。- 実行可能ファイル:
DESTINATION bin(例:/usr/local/binやC:\Program Files\MyApp\bin) - ライブラリ:
DESTINATION lib(例:/usr/local/libやC:\Program Files\MyApp\lib) - 設定ファイル:
DESTINATION share/my_app(例:/usr/local/share/my_appやC:\Program Files\MyApp\share\my_app)
- 実行可能ファイル:
特定のジェネレータ（NSIS, WiXなど）でエラーが発生する
エラー症状:
- WindowsでNSISやWiXジェネレータを使用すると、ビルドが失敗したり、警告がたくさん出たりする。
原因:
- MSVC環境での依存関係: Visual Studioでビルドしたプロジェクトの場合、ランタイムライブラリの再配布が正しく設定されていない可能性があります。
- NSIS/WiXツールの未インストールまたはパスが通っていない: これらのジェネレータを利用するには、対応するツールキット（NSISの場合はNullsoft Scriptable Install System、WiXの場合はWiX Toolset）がインストールされており、かつ環境変数
PATHが通っている必要があります。
トラブルシューティング:
- Visual Studioのランタイム再配布:
CPACK_NSIS_INSTALL_LIBSやCPACK_WIX_PRODUCT_GUID、CPACK_WIX_UPGRADE_GUIDなど、各ジェネレータに特有の変数を確認し、必要に応じて設定します。特にMSVCでビルドしたアプリケーションの場合、ランタイムライブラリ（VCRUNTIME*.dllなど）をパッケージに含めるか、静的にリンクするかを考慮する必要があります。 CPACK_NSIS_EXECUTABLES/CPACK_WIX_ROOTの設定: ツールキットのパスをCMakeLists.txtで明示的に指定することもできます。set(CPACK_NSIS_EXECUTABLES "C:/Program Files (x86)/NSIS/makensis.exe") set(CPACK_WIX_ROOT "C:/Program Files (x86)/WiX Toolset vX.Y/bin")- ツールキットのインストールとPATH設定: NSISまたはWiX Toolsetの公式サイトからダウンロード・インストールし、インストーラーの指示に従って
PATHを設定します。
CPACK_PACKAGE_VERSIONなどの変数が反映されない
エラー症状:
- パッケージの名前やバージョンが、
CMakeLists.txtで設定した値と異なる。
原因:
project()コマンドとの連携: CPackは、project()コマンドで設定されたPROJECT_NAMEやPROJECT_VERSIONをデフォルト値として使用します。- 変数の設定順序: CPackは、
include(CPack)コマンドが実行される時点での変数の値を使用します。include(CPack)の後に変数を設定しても、反映されないことがあります。
トラブルシューティング:
project()コマンドの利用:project(MySoftware VERSION 1.0.0)のようにVERSIONを指定するだけで、CPackが自動的にこれらの情報を使用するため、個別にCPACK_PACKAGE_NAMEやCPACK_PACKAGE_VERSIONを設定する必要がなくなる場合があります。- 変数の設定順序の確認:
CPACK_PACKAGE_NAMEやCPACK_PACKAGE_VERSIONなどは、include(CPack)の前に設定するようにします。project(MySoftware VERSION 1.0.0) # これでもCPackはバージョンを取得します set(CPACK_PACKAGE_NAME "My Awesome Software") set(CPACK_PACKAGE_VERSION "1.0.0-beta") include(CPack) # この時点でCPackは上記の変数を読み込みます
全般的なトラブルシューティングのヒント
- CMake GUIでの確認: CMake GUIを使用している場合、
CPACK_...で始まるキャッシュ変数の値を確認し、必要に応じて変更することができます。 --verboseオプションを使う:cpack --verboseは、デバッグに非常に役立ちます。何が問題なのか、どのようなファイルを探しているのか、どのツールを呼び出そうとしているのかなどの情報が得られます。- シンプルなプロジェクトで試す: 問題が発生した場合は、ごくシンプルな
CMakeLists.txtと最小限の実行可能ファイルでCPackの設定を試してみてください。問題が切り分けやすくなります。
プロジェクト構成
.
├── CMakeLists.txt
├── main.cpp
└── README.txt
main.cpp (簡単なC++ソースコード)
#include <iostream>
#include <string>
int main(int argc, char* argv[]) {
std::cout << "Hello from My Awesome App!" << std::endl;
std::cout << "Version: 1.0.0" << std::endl;
std::cout << "Installed at: " << (argc > 0 ? argv[0] : "unknown_path") << std::endl;
// README.txtの内容を読み込んで表示する（例）
std::string readme_path = "README.txt"; // インストール後の相対パスを想定
// ここでは単純化のため、ファイルが見つからない可能性は考慮しません
std::cout << "\n--- README.txt ---\n";
std::string line;
std::ifstream readme_file(readme_path);
if (readme_file.is_open()) {
while (getline(readme_file, line)) {
std::cout << line << std::endl;
}
readme_file.close();
} else {
std::cout << "README.txt not found at " << readme_path << std::endl;
}
std::cout << "------------------\n";
return 0;
}
注意: 上記のmain.cppには#include <fstream>が不足しています。実際には#include <fstream>を追加してください。また、README.txtのパス解決はインストール先によって変わるため、より堅牢なパス解決が必要になる場合があります。
README.txt (パッケージに含めるファイル)
This is My Awesome App.
Thank you for installing!
Version: 1.0.0
Author: Your Name
CMakeLists.txt (CPack設定を含む)
これがCPackを使用する上での中心となるファイルです。
# CMakeの最低バージョンを指定
cmake_minimum_required(VERSION 3.10)
# プロジェクト名とバージョンを設定。CPackがこれらの情報を使用します。
project(MyAwesomeApp
VERSION 1.0.0
DESCRIPTION "A simple example application packaged with CPack."
HOMEPAGE_URL "https://example.com/myawesomeapp"
)
# 実行可能ファイルを作成
add_executable(${PROJECT_NAME} main.cpp)
# 実行可能ファイルをインストール先に配置するルールを定義
# DESTINATIONは、インストーラーのインストールルートからの相対パスです。
# 例: Windowsでは C:\Program Files\MyAwesomeApp\bin\MyAwesomeApp.exe
# 例: Linuxでは /usr/local/bin/MyAwesomeApp
install(TARGETS ${PROJECT_NAME} DESTINATION bin)
# README.txtをインストール先に配置するルールを定義
# 例: Windowsでは C:\Program Files\MyAwesomeApp\share\doc\MyAwesomeApp\README.txt
# 例: Linuxでは /usr/local/share/doc/MyAwesomeApp/README.txt
install(FILES README.txt DESTINATION share/doc/${PROJECT_NAME})
# CPackを有効にする
# このコマンドは、CPackがパッケージングに必要な設定ファイル (CPackConfig.cmake) を生成するために必要です。
# CPack関連の変数は、通常この `include(CPack)` の前に設定します。
include(CPack)
# ここからCPackのカスタマイズ設定
# パッケージのベンダー（開発元/配布元）
set(CPACK_PACKAGE_VENDOR "My Company Inc.")
# パッケージの名前 (デフォルトはPROJECT_NAME)
# set(CPACK_PACKAGE_NAME "${PROJECT_NAME}")
# パッケージのバージョン (デフォルトはPROJECT_VERSION)
# set(CPACK_PACKAGE_VERSION "${PROJECT_VERSION}")
# パッケージのタイトル（インストーラーの表示名など）
set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "${PROJECT_NAME} ${PROJECT_VERSION}")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "${PROJECT_DESCRIPTION}")
set(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/README.txt") # 説明ファイル
# 生成するパッケージ形式を指定（セミコロン区切り）
# 主要な形式の例:
# Windows: NSIS, WIX
# Linux: DEB, RPM, TGZ
# macOS: DMG, PKG
# 環境に合わせて、利用可能なジェネレータを指定してください。
set(CPACK_GENERATOR "NSIS;DEB;RPM;TGZ")
# インストール後のルートパス（ユーザーが変更可能）
# デフォルトでは、Windowsは "Program Files"、Linuxは "/usr/local" になります。
# set(CPACK_INSTALL_PREFIX "/opt/${PROJECT_NAME}") # 例: 固定のインストールパスを指定する場合
# パッケージの圧縮レベル
# set(CPACK_TGZ_COMPRESSION_LEVEL 9)
# NSISジェネレータ固有の設定（Windowsのみ）
if(WIN32)
# NSISのアイコンファイル (.ico)
# set(CPACK_NSIS_MUI_ICON "${CMAKE_CURRENT_SOURCE_DIR}/my_app_icon.ico")
# set(CPACK_NSIS_MUI_FINISHPAGE_RUN "${PROJECT_NAME}.exe") # インストール完了後に実行するプログラム
# set(CPACK_NSIS_DISPLAY_NAME "${PROJECT_NAME} Installer")
endif()
# DEBジェネレータ固有の設定 (Linux Debian/Ubuntu系のみ)
if(UNIX AND NOT APPLE)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Your Name <[email protected]>")
set(CPACK_DEBIAN_PACKAGE_SECTION "utils")
set(CPACK_DEBIAN_PACKAGE_PRIORITY "optional")
# 依存関係（例: libc6）
# set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.15)")
# パッケージのファイル名にバージョンを明示的に含める
# string(REPLACE " " "-" _pkg_name_hyphen "${PROJECT_NAME}")
# set(CPACK_DEBIAN_FILE_NAME "${_pkg_name_hyphen}_${PROJECT_VERSION}_${CMAKE_SYSTEM_PROCESSOR}.deb")
endif()
# RPMジェネレータ固有の設定 (Linux Red Hat/Fedora系のみ)
if(UNIX AND NOT APPLE)
set(CPACK_RPM_PACKAGE_REQUIRES "libc >= 2.15") # 依存関係
# RPMのプレインストールスクリプト、ポストインストールスクリプトなど
# set(CPACK_RPM_PRE_INSTALL_SCRIPT_FILE "${CMAKE_CURRENT_SOURCE_DIR}/rpm_preinst.sh")
endif()
パッケージの生成手順
-
ビルドディレクトリの作成とCMakeの実行:
mkdir build cd build cmake ..これで
buildディレクトリ内にCPackConfig.cmakeなどのファイルが生成されます。 -
プロジェクトのビルド:
cmake --build .これで実行可能ファイル（例:
build/MyAwesomeAppまたはbuild/Release/MyAwesomeApp.exe）が生成されます。 -
CPackによるパッケージの生成:
cpack --config CPackConfig.cmakeまたは、ビルドシステムに統合されたCPackターゲットを呼び出す場合:
cmake --build . --target packageこれにより、
buildディレクトリ内の_CPack_Packagesサブディレクトリに、設定したジェネレータに対応するパッケージファイルが作成されます。例えば、MyAwesomeApp-1.0.0-win64.exe(NSIS) やmyawesomeapp_1.0.0-1_amd64.deb(DEB) などです。
各CPack変数の簡単な説明
CPACK_RPM_PACKAGE_REQUIRES: RPMパッケージの依存関係。CPACK_DEBIAN_PACKAGE_MAINTAINER: DEBパッケージのメンテナー情報。CPACK_NSIS_MUI_ICON: NSISインストーラーで使用するアイコンファイル。CPACK_GENERATOR: どの形式のパッケージを生成するかをセミコロン区切りのリストで指定します。例えば、"NSIS;DEB;RPM"とすると、NSISインストーラー、DEBパッケージ、RPMパッケージがすべて生成されます。CPACK_PACKAGE_DESCRIPTION_FILE: パッケージの詳細な説明を含むファイルのパス。このファイルの内容がインストーラーの「情報」セクションなどに表示されることがあります。CPACK_PACKAGE_DESCRIPTION_SUMMARY: パッケージの短い説明。CPACK_PACKAGE_VERSION: 生成されるパッケージのバージョン。デフォルトはPROJECT_VERSIONです。CPACK_PACKAGE_NAME: 生成されるパッケージの名前。デフォルトはPROJECT_NAMEです。CPACK_PACKAGE_VENDOR: パッケージのベンダー（提供元）名を設定します。インストーラーの表示やパッケージのメタデータに使用されます。include(CPack): CPackモジュールをインクルードし、CPack関連の処理を有効にします。この行より前に、CPackのカスタマイズ変数を設定することが推奨されます。install(FILES ...): 特定のファイル（ドキュメント、設定ファイルなど）をインストール先に配置します。install(TARGETS ...): 作成したターゲット（実行可能ファイル、ライブラリなど）を、インストール時にどこに配置するかを指定します。DESTINATIONはインストーラーのルートからの相対パスです。add_executable(...): 実行可能ファイルを作成します。project(...): プロジェクトの基本的な情報（名前、バージョン、説明など）を定義します。CPackはこれらの情報をデフォルト値として利用します。
CPackの代替方法は、大きく分けて以下のカテゴリに分類できます。
- 各OSネイティブのパッケージングツールを直接使用する
- クロスプラットフォームなインストーラー/パッケージングツールを使用する
- より高レベルなビルドシステムやパッケージマネージャーの機能を利用する
- スクリプトを記述して手動でパッケージングする
それぞれについて詳しく見ていきましょう。
各OSネイティブのパッケージングツールを直接使用する
CPackは内部的にこれらのツールを呼び出していることが多いですが、CPackを使わずに直接これらのツールを使う方法です。より細かい制御や、CPackがサポートしていない特定の機能が必要な場合に有効です。
- macOS:
- ProductBuild (.pkg): macOSネイティブのインストーラーパッケージを作成します。以前のPackageMakerの代替として使われます。
- Disk Image (.dmg): ドラッグ＆ドロップでアプリケーションをインストールする形式。シンプルなアプリケーションの配布によく使われます。
- Homebrew Formula / MacPorts Portfile: パッケージマネージャーを介して配布する場合に、それぞれに対応する定義ファイルを作成します。
- Windows:
- NSIS (Nullsoft Scriptable Install System): スクリプトベースのインストーラー作成ツール。
.nsiスクリプトを直接記述して、カスタムUI、レジストリ操作、サービスインストールなど、詳細な制御が可能です。CPackのNSISジェネレータは、このNSISを内部で利用しています。 - WiX Toolset (Windows Installer XML): XMLベースでMSIインストーラーを作成するツール。企業の環境で多く使われるMSIパッケージを生成でき、グループポリシーによる配布など、高度な機能が利用できます。CPackのWiXジェネレータもこれを内部で利用しています。
- Inno Setup: NSISに似たスクリプトベースのインストーラー作成ツールで、使いやすさに定評があります。
- NSIS (Nullsoft Scriptable Install System): スクリプトベースのインストーラー作成ツール。
メリット:
- CPackの抽象化層による制約を受けないため、非常に細かいカスタマイズが可能。
- 各OSのパッケージングツールが持つ全ての機能を利用できる。
デメリット:
- CMakeとの統合が失われるため、ビルドプロセスとは別にパッケージングプロセスを管理する必要がある。
- クロスプラットフォームなプロジェクトでは、OSごとに異なるビルド/パッケージングスクリプトが必要になる。
- OSごとに異なるツールと設定を学ぶ必要がある。
クロスプラットフォームなインストーラー/パッケージングツールを使用する
CPackを使わずに、独立したクロスプラットフォーム対応のインストーラー作成ツールを使用する方法です。GUIを備えているものや、より高機能なものがあります。
- Electron Builder (ウェブ技術ベースのデスクトップアプリの場合): Electronベースのアプリケーションの場合、macOS (dmg, pkg), Windows (exe, msi), Linux (deb, rpm, AppImage) 向けのパッケージを簡単に作成できます。
- IzPack: Javaベースのオープンソースインストーラー作成ツール。
- InstallShield: 商用で高機能なWindowsインストーラー作成ツールですが、限定的なクロスプラットフォーム対応もあります。
- Qt Installer Framework (IFW): Qtが提供するインストーラー作成フレームワーク。クロスプラットフォームで統一されたGUIインストーラーを作成できます。モジュール形式でのインストールやアップデート機能も備えています。CPackのIFWジェネレータも存在します。
メリット:
- GUIや高度なインストーラー機能（カスタムページ、自動更新など）を簡単に実現できる。
- 単一のツールで複数のOS向けパッケージを作成できる。
デメリット:
- 多くの場合、CMakeのビルドプロセスから独立して実行する必要がある。
- 別のツールチェーンを導入し、そのツールの設定を学ぶ必要がある。
より高レベルなビルドシステムやパッケージマネージャーの機能を利用する
CMakeのビルド設定は生成しますが、その上で動作するパッケージングや配布の仕組みを利用する方法です。
- Bazel / Buck (ビルドシステム): GoogleのBazelやFacebookのBuckのような大規模ビルドシステムは、ビルドからテスト、パッケージングまでを一元的に管理することを目的としています。非常に大規模なモノリポジトリに適しており、きめ細かいビルド単位とキャッシュ機構により、高速なビルドと再利用性を実現します。
- Conan / vcpkg (C++パッケージマネージャー): これらは主に依存関係の管理に使われますが、自身でビルドしたライブラリやアプリケーションをパッケージ化して共有する機能も持っています。特に、企業内のプライベートなパッケージリポジトリでの利用に適しています。
- Conan: Pythonベースで、プロジェクトの依存関係をビルド・管理し、バイナリパッケージとして共有できます。独自のレシピ（
conanfile.py）を記述して、パッケージのビルド方法やインストール方法を定義します。 - vcpkg: Microsoftが開発したC++ライブラリマネージャー。主にオープンソースライブラリの取得・ビルドに使われますが、独自のポート（レシピ）を追加して、カスタムアプリケーションのビルドとパッケージングに利用することも可能です。
- Conan: Pythonベースで、プロジェクトの依存関係をビルド・管理し、バイナリパッケージとして共有できます。独自のレシピ（
メリット:
- 再現性のあるビルド環境と配布プロセスを構築しやすい。
- 依存関係管理からパッケージングまでの一元的なワークフロー。
デメリット:
- 特定のパッケージ形式（NSISインストーラーなど）の生成には向かない場合がある。
- 小規模なプロジェクトにはオーバーキルになる場合がある。
- 学習コストが高い。特にBazelのようなビルドシステムは、CMakeとは異なる概念を学ぶ必要がある。
スクリプトを記述して手動でパッケージングする
究極の代替手段として、シェルスクリプト（Bash、PowerShellなど）やPythonスクリプトを記述して、必要なファイルをコピーし、アーカイブを作成し、各OSのコマンドラインツールを呼び出してパッケージを生成する方法です。
メリット:
- 既存のツールやライブラリを自由に組み合わせられる。
- 完全に自由なカスタマイズが可能。
デメリット:
- CPackが提供する多くの便利機能（バージョン管理、インストールパスの自動解決など）を自分で実装する必要がある。
- クロスプラットフォーム対応が難しく、OSごとに異なるスクリプトを用意する必要がある。
- スクリプトの作成、デバッグ、メンテナンスに手間がかかる。
CPackは、CMakeプロジェクトにとって最も手軽で標準的なパッケージングソリューションです。多くのプロジェクトではCPackで十分な機能が提供されます。
しかし、以下のような場合には代替手段を検討すると良いでしょう。
- 非常にシンプルなアーカイブ配布で十分な場合や、特定の問題に対する一時的な回避策が必要な場合 (手動スクリプト)
- 極めて大規模なプロジェクトで、高速なビルドと厳密な依存関係管理が求められる場合 (Bazelなど)
- 依存関係管理と連携した、より包括的なパッケージング/配布ワークフローを構築したい場合 (Conan, vcpkgなど)
- CPackで実現できない特定の高度なインストーラー機能が必要な場合 (NSIS/WiXの直接利用、Qt Installer Frameworkなど)