CMakeは依然として自分の役割をわかっていない。
(dorinlazar.ro)CMakeは、C++に対する悪い解決策だとますます感じられる。C++開発者の要求に応えられていないだけでなく、一貫性のない言語で、非常に不明瞭かつ構造化されていない形でmakefileを構築する暗黒時代にとどまらせている。
問題
C++のビルドの世界には、2種類の問題がある。
- 既存プロジェクトが自ら作り出した問題（すでに存在する巨大なプロジェクトをビルドする問題）
- C++で新しいプロジェクトを始めるときに直面する問題
CMakeは1つ目の問題を解決しようとしているが、2つ目の問題はまったく解決していない。しかし、こうした問題を解決しようとしないために、より有用性の低いツールになっている。
CMakeは、プロジェクト定義をビルドシステムへ翻訳する翻訳者になりたがっているが、この点でひどく失敗している。プロジェクト定義言語として質が低く、一貫性がなく、直感的でもない。
C++コミュニティの誰もが今ではRustのツールについて語っている。Cargoが、ほとんどの開発者が必要だと考えることを実際にやってくれるからだ。Cargoはインターネットから依存関係をダウンロードして隔離されたツールキットを作り（悪い考えだが）、静的リンクされたライブラリを提供する（これも悪い考えだ）。人々は、驚異的な速度でセキュリティホールを追加するツールを必要としているわけではないが（筆者は、Cargoがインターネットから自動的にコードを取得してリンクする方式は、サプライチェーン攻撃のような脆弱性につながると主張している。詳細は I Hate Rust を参照）、Cargoが実際に提供しているものは必要とされている:
- 非常に厳格なプロジェクト構造
- ライブラリがどこにあるかという問題を解決するために外部サーバーに依存する、非常に単純な構成システム
- ただ1つ のツールセット。
人々には、実際の作業に集中できるよう、より小さな自由が必要であり、コンパイラを最も完璧な方法で呼び出すことに長けているわけではない。
解決策
まだ解決策はない。余暇に klb を書いているが、今のところは解決策ではない。（時間とお金が必要だ。）
しかし、人々が何を必要としているのかは明らかだ。より多くの選択肢ではなく、より少ない選択肢である。選択肢が少ないということは、プロジェクトのコンパイルを台無しにできる方法が少ないことを意味する。
CMakeは今でもC++の世界で最良の選択肢だが、この20年間でC++に起きた最悪の出来事でもある。ほかのすべては改善しているのに、ビルドシステムだけが悪化し続けている。
10件のコメント
文法はちょっと汚いですが、CMakeに匹敵するものはなかったですね。
M4みたいなものを非POSIX環境で回そうとすると頭が痛くなります。
そもそもビルド環境にあれこれぶら下がるのが好きではないので、mesonやsconeのようなものには手が伸びず、premakeもどこか少し詰めが甘く見えるので、結局CMakeでただひたすらできるだけシンプルにコード定義だけして使うようになります。
長いこと文句を言いながらCMakeを使ってきましたが、いざとなるとCMakeほどのものはやはりありません。bazelは本当に地獄……。新しくプロジェクトを始めるなら、mesonを検討してみると思います。
MesonやBazelはどうですか？
私はどちらも使ったことがないので、よく分かりませんね…
個人的には、小さなプロジェクトには gprbuild が気に入っていて使っています。
CMake以外の方法も複雑なのは同じです。
クロスプラットフォームという点ではまだましですが……
だからVisual Studioが人気なのだと思います。すぐにコーディングを始められますから。
これも細かく掘り下げていけばきりがありませんが。
CMakeを見るだけで吐き気がします……
CMakeは make の代替ではなく、autotools（automake）の代替だと考えればよいと思います。
それでも、ただのMakefileよりはまだましな気もします。
先月、シェルスクリプトとPerl、OS環境変数、あちこちに絡み合った複数のMakefileで構成されたビルド環境を分析することがあったのですが、本当に気が狂いそうでした。
細かくいろいろやろうとすると、ウサギの穴に入り込んでしまいます……