cmakelists.txtとMakefileの違いを徹底解説｜初心者でもわかる選び方と使い分け

---

はじめに：cmakelists.txtとMakefileの違いをざっくり把握する

ソフトウェアのビルドを学ぶとき、まず出てくるのが cmakelists.txt と Makefile という言葉です。どちらもビルドを自動化する道具ですが、役割や使い方、適した場面がかなり違います。Makefile は「今ここにある手順を直接記述する」タイプのファイルで、make コマンドがその内容をそのまま解釈してビルドします。対して cmakelists.txt は「ビルドの設計図」を書くためのファイル群で、CMake がそれを読み取り、実行環境に合わせた具体的なビルドファイルを自動で作ってくれます。

この違いを理解することは、将来の保守性と移植性を確保する第一歩です。跨るプラットフォームに対応する設計思想の差、外部ライブラリの取り扱い方、ビルドの生成先の違いなど、現場で直面する具体的な問題に直結します。

本記事は、初めて触る人にも理解できるよう、言葉の意味から具体的な使い分け、実務での注意点までを順に解説します。

この段落では、見出しの役割と全体の構成を説明します。

まず第一に、仕組みの違いを理解することが前提です。次に、書き方の違いと学習のコツを学びます。その後、使い分けの現実的な目安と、実務での注意点を順番に見ていきます。最後に、比較表を用意して視覚的にも理解を深めます。

情報を整理しておくと、後から復習するときの効率が高まります。

1. 仕組みの違いを比べる

Makefile は「今このプロジェクトで使われているルールを直接記述する」仕組みです。つまり、誰かが作成したMakefileを手元で開いて、依存関係やコンパイルの順番、リンクの仕方などを書き換えれば、そのままビルドの挙動が変わります。場合によってはOSの差やコンパイラのオプションの差を自分で吸収する必要があります。対してCMakeは「ビルドの指示を抽象的な言語（cmake言語）で記述する」設計思想です。CMakeLists.txtに書くのは、ビルド対象の追加、ライブラリの結合、ファイルの探し方、外部依存関係の宣言などの“方針”であり、実際にどう動くかは後で自動生成される具体的なファイル（MakefileやNinjaファイルなど）が決定します。

この違いの結果として、同じプロジェクトが異なる環境でも同じようにビルドできるかどうかという観点が生まれ、クロスプラットフォームの対応力が変わってきます。さらに、CMakeは複数のビルドツールを統合する可能性を広く持っており、後からビルドツールを切り替えたり、異なるコンパイラを使ったビルド設定を共通の記述で管理したりすることが可能です。これが現代の多くのC++プロジェクトでCMakeが好まれる理由の一つです。

要点としては、Makefileが「具体的な手順の記述」であり、CMakeが「方針と抽象化の記述」であるという点です。

2. 書き方の違いとコツ

MakefileとCMakeLists.txtでは、書き方の基本的な形式がまったく異なります。Makefileではターゲットと呼ばれる名前を作業の単位として設定し、依存関係とレシピ（コマンドの集まり）を記述します。インデントはタブで統一する必要があり、慣れるまでは空白とタブの混在を避けることがコツです。

例えば、「main.cppをビルドして実行ファイルaを作る」という一連の手順を、ファイル名、依存ファイル、使用するコンパイラオプション、リンクするライブラリなどを一行ずつ書く形になります。対してCMakeLists.txtはcmakeコマンドを使った“宣言的”スタイルで書きます。

代表的な命令として、add_executableやadd_library、target_link_libraries、find_packageなどがあり、これらを組み合わせることで、実行ファイルを作る、ライブラリを結合する、外部の依存を探すといった意図を表現できます。初心者は最初から完璧に書く必要はなく、公式のサンプルを真似して“設計図”を作るところから始めるとよいでしょう。

また、CMakeを使うと、後から別のビルドツールへ切り替える際の影響を最小化できます。そのため、いわゆる“プロジェクトの未来を見据えた設計”を意識する人ほど、CMakeを選ぶ傾向があります。

3. 使い分けの現実的な目安

実務では、小さなツールやスクリプトのように単純なものを素早くビルドしたい場合はMakefileの良さが生きます。

ただし、クロスプラットフォームを前提にしたり、複数の外部ライブラリに依存したり、ビルドのオプションを柔軟に切り替えたい場合には、CMakeの方が長い目で見て扱いやすいです。新しいプロジェクトを始める場合は、原則としてCMakeを採用しておくのが無難です。既存の大規模プロジェクトがMakefileベースであっても、後からCMakeへ移行することで、メンテナンス性を高められることがよくあります。ただし移行には手間とリスクが伴い、依存関係の再設定やビルドの再現性の確認が必要です。

現場では、開発チームのスキル、プロジェクトの配布形態、CI/CDの仕組み、OSの多様性などを総合的に勘案して判断します。結局は、最終的なビルド結果が同じで、管理が楽になる道を選ぶのが現実的です。

4. 学習・実務での注意点

両者を使い分けるには、まず「どの環境でどうビルドするのか」を明確にすることが大切です。

学習の段階では、まずMakefileの基本的な書き方と、CMakeLists.txtの基本的な構造を別々に練習してから、実務に入るのがよいでしょう。

学習のコツとしては、公式ドキュメントのサンプルを手元で実際に動かしてみて、ファイル名とオプションがどう影響するかを体感することです。実務では、CIでの自動ビルドやテストの観点から、CMakeを中心に据えると良い場合が多いです。外部ライブラリの見つけ方、サードパーティのロックファイルの活用、ビルドの分離（out-of-source build）などのテクニックを覚えると、長期的な保守性が格段に上がります。

最後に、チームでの運用ルールも大事です。共通のビルド設定を持つこと、バージョン管理との連携を意識すること、ドキュメントを整備することなどを守ると、誰が手を動かしてもビルドが再現しやすくなります。

5. 表でひと目で分かる比較ポイント

この表は前述の説明を補足するためのものです。表の各項目には、現場で直面する具体的な差異を短い事例とともに列挙しています。表を読めば、どちらを選ぶべきかの判断材料がつかめます。なお、表は読みやすさのための要約ツールとして用意しており、実務の細かな差異は本文を参照してください。

以下の表は、学習用の目安として頭に入れておくと良いポイントを整理したものです。

特徴	cmakeLists.txt	Makefile
目的	ビルドの生成を指示する抽象的な指示を記述	実際のビルド手順を直接記述
クロスプラットフォーム	高い。生成時に対応ツールを選択	低い。OS依存が出やすい
学習コスト	中～高。cmake言語の習熟が必要	低。基本的な書き方を覚えればすぐ使える
保守性	高い。設計が分離され、再利用性が高い	低い。手順の追加入力が増えると混乱しやすい
主な出力	Makefile、Ninjaファイル、Visual Studioのプロジェクトファイルなど、状況に応じて生成	OSとツールに依存した直接的なファイル

ピックアップ解説

Makefileという言葉を深く掘り下げる小話を雑談形式でお届けします。放課後、友だちとノートを開いて“今日はどんな手順でビルドする？”と話し合う場面を想像してください。Makefileは手作業のレシピ帳のようなもので、ファイルの依存関係が増えると一行ずつ書く作業量が増え、間違い箇所を見つけるのが大変になることがあります。だからこそ、長い目で見ればCMakeのような設計図が役立つのです。Makefileを深く理解するほど、依存関係の管理や再現性の確保、そしてツール選択の判断力が鍛えられます。要は、手順を直接書くのが得意なMakefileと、設計図を用いて後で生成してくれるCMakeの違いを、雑談を通じて納得することが大切という話です。

---