configure・CMakeの世界地図
インターネットで拾ってきたソースコード一式を自分でビルドしようとすると、多くの場合「./configure && make && make install」か「cmake -B build」のどちらかに出会います。これらはMakefileを手で書く代わりに、環境に合わせて自動生成してくれる仕組みです。ここではAutotoolsのconfigureとCMakeという2大流派の正体、out-of-sourceビルドの考え方、依存ライブラリの旗を教えてくれるpkg-configまでをまとめて見取り図にします。この回を終えると、世に出回っているたいていのC/C++プロジェクトを臆せずビルドできるようになります。
GitHubから面白そうなC/C++プロジェクトを拾ってきて、いざビルドしようとすると、多くの場合README には2種類の呪文のどちらかが書いてある。./configure && make && make install か、cmake -B build && cmake --build build のどちらかだ。
🗺️ 2つの流派——Autotools系とCMake系
歴史的に古くから使われてきたのがAutotools（GNU Autoconf/Automake）という仕組みで、その使用者側の窓口がconfigureスクリプトだ。より新しく、多くのプラットフォームで人気なのがCMakeで、CMakeLists.txtという設定ファイルを起点にする。
どちらも目指すゴールは同じで、「このマシンにはどんなコンパイラがあるか」「必要なライブラリは揃っているか」を調べたうえで、実際にビルドするためのMakefile（やそれに相当するもの）を作り出すことにある。
⚙️ configure——Autotoolsが調べて生成する
configureを実行すると、画面には「〜のヘッダを探しています... yes」のような検査ログが大量に流れる。これはコンパイラの種類、利用可能な関数、必要なライブラリの有無などを1つずつ調べているためだ。
🧊 CMake——CMakeLists.txtから多様なビルド系を生成
CMakeはconfigureよりも新しい設計で、Makefileだけでなく、環境によってはNinjaというビルドツール向けのファイルや、統合開発環境向けのプロジェクトファイルまで生成できる、いわば「メタビルドツール」（cba-meta-build）だ。
📂 out-of-sourceビルド——buildディレクトリを分ける理由
上の例で気づいた通り、CMakeは生成物をソースコードと同じ場所ではなく、buildという別のディレクトリにまとめて作る。これをout-of-sourceビルド（cba-out-of-source）と呼ぶ。
🚩 pkg-configで依存ライブラリの旗を受け取る
自分のプログラムが外部ライブラリ（例えばOpenSSLやzlibなど）に依存しているとき、そのライブラリのヘッダがどこにあるか、リンクにどんなオプションが必要かを手で調べるのは面倒だ。この情報を教えてくれるのがpkg-configだ。
🌍 読めるようになると、世界のOSSが手元でビルドできる
ここまで見てきたconfigure・CMake・pkg-configは、それぞれ単体では小さな道具だが、組み合わさることで「環境の違いを吸収して、誰の手元でも同じようにビルドできる」という大きな仕組みを実現している。
最初は呪文にしか見えなかった./configure && make や cmake -B build も、正体が分かれば「環境を調べてMakefileを作り、それを実行しているだけ」だと分かる。今までMakefileを手で書いてきた経験が、そのままこの理解の土台になっている。この見取り図を持てば、世の中のC/C++プロジェクトのREADMEに書かれたビルド手順がどちらの流派で何をしているコマンドなのか、読み解けるようになっているはずだ。