私はMakefileが好き

• 私はMakefileが好きだ。使い始めてからもう10年以上になる。当時ですら古い技術のように見えた。時が経つにつれて新しいビルドツールが現れては消えていったが、Makefileはいまでも使われ続けていた。プロジェクトに参加する中で慣れ親しみ、気づけば好きになっていた。今では新しいプロジェクトを始めるとき、最初に使う自動化ツールになっている。

• Makefileが好きな理由は、同じコマンドセットを実装するための非公式な慣習に従っているからだ。新しいプロジェクトに触れたとき、Makefile ファイルがあれば make または make build を実行し、その後 make install を実行すれば、プロジェクトがビルドされ設定される。あるいは、追加の手順に関する情報を得ることもできる。

• 自分のプロジェクトでも同じ慣習を適用しようとしている。古いプロジェクトのフォルダを開いて make dev を実行すれば、必要なすべての手順をこなしてプロジェクトをビルドし、開発サーバーを起動してくれる。さまざまな技術を使ってきたため、技術ごとにコマンドは異なっていた。Makefileを使えば、数か月あるいは数年触っていないプロジェクトでも簡単に管理できる。

• Makefileはシンプルだ。条件分岐、フラグ、その他の複雑な機能は使わない。ほとんどの作業は1つ以上のシェルコマンドで構成される。いくつかの関数を持つbashスクリプトを書くこともできるが、Makefileのほうが簡単かつ素早く書ける。

• たいていの個人プロジェクトには、次のような一般的な作業が含まれる:

  • dev: 開発サーバーを起動
  • build: プロジェクトをビルド（ビルド工程が必要な場合）
  • deploy: プロジェクトをデプロイ／公開

• このブログには、単一のターゲットを持つシンプルなMakefileがある:

  dev:  
    npm run dev  
  

• より複雑なプロジェクトでは、次のようなMakefileを使っている:

  # 開発サーバーを実行  
  dev:  
    bundle exec jekyll serve --unpublished -w --config _config.yml,_config-dev.yml --livereload  
  
  # アセットをビルド  
  build:  
    npm run gulp build  
  
  # 特定のフォルダを監視してアセットを処理  
  watch:  
    npm run gulp watch -- --wip  
  
  # ローカルでウェブサイトをビルドし、暗号化してNetlifyサーバーにデプロイ  
  deploy:  
    JEKYLL_ENV=production bundle exec jekyll build; \  
    make encrypt; \  
    netlify deploy --prod  
  
  # "_site" フォルダを暗号化  
  encrypt:  
    npx staticrypt _site/*.html -r -d _site  
  

• 上の例では、phonyターゲットの存在を無視している。dev、build、watch、deploy、encrypt という名前のファイルがある場合、Makefileは期待どおりに動作しない可能性がある。

• GNU Makeは非常に広く普及している。Linuxではすでにインストールされている可能性が高い。MacBookでも明示的にインストールした記憶はない。ほかのツールと一緒にインストールされたのだろう。Makeはシンプルで、ほかのビルドツールより追加の依存関係が少ない。制約のある環境では役立つことがある。Makeはすでに存在している可能性が高い。そうでなければ、Makefileのコマンドをシェルで手動実行することもできる。

• 私は他のビルドツールに反対しているわけではない。新しいビルドツールを見つけると興味深いと思う。それでも、さまざまなツールを管理するために今なおMakeを使っている。

---

GN⁺の要約

• Makefileは、さまざまなプロジェクトで一貫したコマンドセットを提供し、管理を容易にする。
• シンプルな構文と少ない依存関係により、制約のある環境でも有用に使える。
• さまざまなビルドツールと組み合わせて使えるため、柔軟性が高い。
• 類似の機能を持つツールとしては、CMake、Ninja、Gradle などがある。

[kayws426]

依存関係を定義していない makefile は、justfile に置き換えるとより良い使い勝手が得られます。

[GN⁺]

Hacker Newsの意見

• Make の使用を勧める声

  • Make をうまく使えていないといって落ち込む必要はないという意見
  • Make の強みはシンプルさであり、小さなプロジェクトでは大きな問題にならない
  • ほとんどの場合、正しいやり方を気にする必要はなく、必要な分だけ複雑さが加わる

• Makefile の問題点

  • Makefile は他のビルドシステムよりはましだが、それでも問題は多い
  • ビルドシステムの主な問題点:
    • 基本的すぎる: 複雑なプロジェクトでは混乱が生じる
    • 複雑すぎる: 初期知識と管理に過剰な負担がかかる
    • 標準ライブラリ不足: すべてを自分で定義しなければならない
    • 制約が強すぎる: 要件が変わると別のシステムへ移行しなければならない
    • 魔法が多すぎる: 設計の悪いシステムの特徴
    • 暗号的または一貫性のない文法

• Make の利点

  • Make を好む人の意見
  • Make はファイルを変換するコマンド群のための単純な DSL
  • Bash や他のシェルでも可能だが、Make のほうが簡単

• PHONY ターゲットの使用

  • mtime ベースの依存関係追跡は使わない
  • ターゲットは PHONY として定義する必要がある
  • 最近では just と justfiles に移行し、よりシンプルに使っている

• Make をめぐる熱い議論

  • Make は vi-vs-emacs 戦争のような論争を引き起こす
  • Makefile を最上位のビルドシステムドライバとして使うのは賢い
  • 他のビルドツールを使っていても、Makefile で標準化できる

• Make のさまざまな活用

  • Make をさまざまな作業の自動化に使っている
  • 個人ウェブサイトのビルドとデプロイに Makefile を使用
  • Git push と Git hook を通じて Make を呼び出す
  • PDF ファイルのアップロードと管理に Makefile を使用

• Make の限界と代替案

  • Make はタスクランナーとしては悪くないが、より良い代替案がある
  • Make/Makefiles は標準化されていない
  • 依存関係の解決はできず、configure スクリプトが必要
  • mtime を使って入力が最新かどうかを確認するが、問題が起こることがある
  • Unix 哲学に従って設計されているが、現代のビルドシステムには限界がある

• Justfiles への移行

  • Justfiles に移行して Makefile の複雑さを避けている

• Makefile のシンプルな使い方

  • Makefile のシンプルな使い方を支持する意見
  • すべてを完璧に学ばなくても共有できる
  • GitLab CI パイプラインが Makefile を置き換えた経験の共有