CMake

CMake 4.3がC/C++依存管理に共通言語——CPS正式化の意味

25年越しの問いに、ようやく答えが出た。CMakeが長年抱えてきた「パッケージ記述」の問題が、具体的な形で動き始めている。

情報の灯台

2026年4月13日

25年越しの問いに、ようやく答えが出た。CMakeが長年抱えてきた「パッケージ記述」の問題が、具体的な形で動き始めている。

「ライブラリとは何か」を機械に教える試み

C++でライブラリを使うとき、何が必要か。ヘッダーファイル、インクルードパス、リンカーフラグ、そして依存するさらなるライブラリ——これらの情報を、ツール間で共有する「共通言語」が、30年近くの間、存在しなかった。

CMakeはこの問題を独自の設定ファイル形式で回避してきた。ただしそれはCMake専用の解決策であり、ConanやSpackなど他のパッケージマネージャーとの橋渡しにはなれなかった。

そこに登場したのがCPS（Common Package Specification）だ。

「実験的」から「安定版」へ

CMake 4.3のリリースで、CPSはついて実験的（experimental）フラグが外れ、正式機能として組み込まれた。

CPSはJSONベースのフォーマットで、パッケージのコンポーネント、設定、バージョン互換性、依存関係を記述する。特徴的なのは、CMake以外のツールでも読み書きできるように設計されている点だ。CMakeが長年築いてきた「エクスポートターゲット」の概念を、プログラムとして実行できるCMakeスクリプトから切り離し、誰でも読み書きできる宣言的な形式に置き換えた——それがCPSの本質だ。

CPS（Common Package Specification）正式化までの道のり

CMake 3.31

2024年11月

実験的

CPS へのエクスポート機能が実験的に追加。CPSファイルの出力が初めて可能に

CMake 4.0

2025年3月

実験的

CPSからのインポート機能が実験的に追加。読み込みと書き出しが両方可能に

Kitware公式ブログ

2026年3月19日

「Common Package Specification is Out the Gate」を公開。CPS正式化を宣言

CMake 4.3

2026年3月17日リリース

正式機能

CPSのインポート・エクスポートが正式機能に昇格。find_package() でCPSファイルを自動検索、install(PACKAGE_INFO) でCPS生成が可能に

CPSはビルドシステム間、そしてパッケージマネージャー間で、パッケージに関する情報を共有するための共通言語となることを目指している。（Kitware公式ブログより）

使い方はシンプルだ。従来通り find_package() を呼ぶだけでCPSファイルを自動で検索・インポートできる。プロバイダー側は install(PACKAGE_INFO) を追加するだけで、CPSファイルの生成が始まる。既存のワークフローを大きく変えずに移行できるよう、CMakeスクリプト形式との共存も前提に設計されている。

解決される「推移的依存」の地雷

開発者を長年悩ませてきた問題の一つが、推移的依存（transitive dependencies）の管理だ。ライブラリAがライブラリBに依存していて、さらにBがCに依存している——この連鎖をビルドシステムが正しく追跡できないと、謎のリンクエラーが発生する。

CMakeスクリプト形式 vs CPS：主な違い

	CMakeスクリプト形式	CPS（新方式）
フォーマット	CMakeスクリプト（チューリング完全言語）	JSON
他ツール対応	CMakeのみ	Conan / Spack など
推移的依存	実験段階（CMake 3.29〜、制約あり）	最初から組み込み済み
バージョン互換	メジャー or メジャー+マイナーのみ	「互換バージョン」で任意の粒度を表現
名前空間	任意（衝突リスクあり）	パッケージ名で強制
既存との共存	両方を同時に生成・配布可。古いCMakeとの後方互換を維持しながら移行できる

出典：Kitware「Common Package Specification is Out the Gate」（2026年3月）/ CMake 4.3公式リリースノート

CPSはこの問題を仕様の中心に据えた。依存関係の情報を明示的に保持し、パッケージ提供者が宣言すれば消費者側は追加作業なしに依存の連鎖を辿れる。CMakeスクリプト形式での自動推移的依存サポートがいまだ実験段階にあるのと対照的に、CPSではこれが最初から組み込みの前提になっている。

バージョン互換性の表現も改善された。従来の「メジャー番号が同じならOK」という粗い判定に加え、「このバージョン以降は後方互換」を任意の粒度で表現できる「互換バージョン」の概念が導入されている。

CMake 4.3のその他の新機能

CPS以外にも、4.3では目を引く変化がある。

cmake-instrumentation は、ビルドプロセス全体のタイミングデータやCPU・メモリ使用量を収集するフレームワークだ。設定フェーズから、ビルド、テスト、インストールまで、各ステップの実行時間を詳細に記録し、Google Trace Eventフォーマットで出力してPerfettoなどのビジュアライザーで可視化できる。ビルドに時間がかかっている本当の原因が、やっと見えるようになる。

一つ前のバージョン、4.2の変化も見逃せない。ゲームエンジン開発コミュニティで人気の高いFastBuildが新しいジェネレーターとして追加された。分散ビルドとキャッシュをネイティブにサポートするツールで、Ninjaと同等の単体ビルド速度を持ちながら、複数マシンへの分散時に大きく差がつく。

C++ 20 Named Modulesの正式サポートはCMake 3.28（2023年）で実現した。C++の長年の課題だったコンパイル順序の依存管理を、CMake側でスキャンステップを設けることで解決した形だ。

CMake 4.3 主要新機能一覧

機能	ステータス	概要
CPS Common Package Specification	正式機能	JSONベースのパッケージ記述形式。find_package() での自動検索、install(PACKAGE_INFO) での生成に対応
Instrumentation cmake-instrumentation(7)	新規追加	設定・生成・ビルド・テスト・インストール全フェーズのタイミングデータとシステム診断情報を収集。Google Trace Eventフォーマットでの出力に対応
C++ 20 Named Modules （参考：CMake 3.28）	正式機能（3.28〜）	コンパイル順序の依存管理を自動化。Ninja / Visual Studio ジェネレーター対応（MSVC・Clang 16+・GCC 14+）
FASTBuild （参考：CMake 4.2）	新規追加（4.2〜）	分散ビルド・キャッシュをネイティブサポートするジェネレーター。ゲーム開発コミュニティで人気
プリセットスキーマ v11	更新	テストプリセットの jobs フィールドで空文字列をサポート

出典：CMake 4.3公式リリースノート（cmake.org）

CPS自体はまだ「プレリリース」段階（バージョン0.14.1）であり、ジェネレーター式のサポートや外部パッケージマネージャーとの連携など、残された課題は少なくない。Kitwareはロードマップを公開しており、作業は継続中だ。

「CMakeはパッケージマネージャーではない」という壁

KitwareのCTO、ビル・ホフマン氏はHPSF 2026での講演で、次のステップについて率直に語った。

CMakeを使う開発者が最も苦労することの一つは、依存するライブラリを手に入れること自体だ。FetchContentなどで回避する方法はあるが、根本的な解決にはなっていない。ホフマン氏が提案するのは「CMake provisonステップ」——ビルド設定（cmake configure）の前に、お好みのパッケージマネージャーを呼び出す専用フェーズを設けるという構想だ。SpackやConan、あるいはFetchContentを、統一されたインターフェースで使えるようになる可能性がある。

これはまだ構想段階だが、CPSという共通言語の整備と組み合わさったとき、「ビルドシステムとパッケージマネージャーの壁をなくす」という方向性が現実味を帯びてくる。

C++の依存管理はずっと、「なんとなく動く」状態で運用されてきた。CPSが提示するのは、その「なんとなく」を丁寧に定義し直す作業だ。25年かかって、ようやくここまで来た。

参照元