コンピュータ今昔物語22～make職人のお仕事（80年代の開発環境）

2026年6月24日 08:28

今は昔、コンピュータが計算機と呼ばれていたころの物語
前回：教育用言語Pascalの正体
次回：80年代の情報処理技術者試験(ないしょ話)

80年代の開発環境

今は昔、統合開発環境が存在せず、個々のツールを組み合わせて開発環境を構築していた頃、大きな役目を果たしていたmakeを見ていきます。

UNIXの開発ツール群

1980年代はUNIXにまだ統合開発環境(Integrated Development Environment, IDE)が存在せず、個々の開発ツールを組み合わせて開発環境を構築していました。以下に主な開発ツールを挙げていきます。

cc - Cコンパイラ
link - リンカ
lint - Cソースコード解析
make - ビルダ
dbx - デバッガ
dtrace - トレーサ
sh - シェル
vi - テキストエディタ
ed - ラインエディタ（置換/検索用）
cat - テキスト表示
patch - パッチ当て
diff - 差分抽出
touch - ファイルのタイムスタンプ更新
# 既に廃れてしまったツールもあることに注意してください

（参考）Emacsによる統合開発環境の構築

「Emacs対vi (UNIXミニコン VAX-11)」でも少し触れましたが、Emacsのバッファ（編集エリア）上で、開発コマンド群の制御プログラムをEmacs Lispで作って開発環境を構築していました。

Emacs派のエンジニアはこの開発環境を作っていました。しかしEmacs派が少なく、Emacs Lispを使いこなす人はさらに少なく、このEmacsによる統合開発環境派は、残念ながら少数派でした。

make職人のお仕事

UNIXのビルドツール make はプログラムをビルド（メイク）するためのツールです。しかしmake職人によってmakeは統合開発環境を構築できる能力を発揮することになります。

ビルドツール make

ビルドツール make 自体は単純な機能しか持たないツールで、以下のような形式で記載しているMakefileファイルを作ってmakeを実行します。

target: source
command

makeはsourceファイルとtargetファイルのタイムスタンプを比較して、sourceのタイムスタンプが新しければ(sourceが更新されていれば）、commandを実行します。なおsourceは複数のファイルが指定できます。
これをプログラム風に書けば「if (date(target) < date(source)) command;」になります。

このようにmake自体は非常に単純な機能しかありません。つまりmakeはファイルの依存関係を記述することで、複雑なビルドを効率よく実行するツールです。

例えば
test.o: test.c
cc -c test.c
でmakeを実行すれば、test.cが更新されていれば(test.oよりも新しければ)、cc（コンパイル）します。そしてこれが本来のmakeの使い方です。

makeは単純だからこそ万能

上記にあるようにmakeは単純なツールです。本来はビルド（メイク）するためだけのツールです。

プログラム風に考えれば「if (date(target) < date(source)) comamnd;」の羅列だけでプログラミングするようなものです。これはどんなシェル(sh、csh)よりも低機能で、ファイルのタイムスタンプを比較する機能がデフォルトで用意されているだけです。

しかしmakeではtouchコマンドが有用です。touchコマンドではファイルのタイムスタンプを最新に更新します。そこでsourceファイルにtouchすると、targetよりも新しくなりますので、commandを強制的に実行するようになります。

つまりcommandの中で別のsourceファイルにtouchすると、それに依存しているtargetファイルに対するcommandが実行されることを利用して、複雑な制御が行えます。まるで裏技です。

makeのテクニックはこれだけです。これ以上のTipsはありません。しかしこれだけで万能です。何でもできます（きっぱりと宣言）。チューリング完全です（これは嘘かもしれません）。

make職人の華麗なるお仕事

1980年代には「make職人」と呼ばれる人がいました。make職人は100行を超えるMakefileを複数作り、makeの梯子をしながら、複雑怪奇な自動制御をしていました。

例えば、あるmake職人は「エラーが出ても継続する夜間連続テスト」のMakefileを作り、あるmake職人は「テストをしてエラーが出れば自動的にデバッグする」Makefileを作っていました。
# もちろんエラーは想定しているエラー対応であり、デバッグは想定しているデバッグルーチンを入れ替えるものです。

make職人いわく「単純な仕掛けだからこそ腕の見せ所」だそうです。感心しました（色々な意味で）。

make職人の苦悩

make職人はいま滅亡しています。複雑怪奇なmakeはロストテクノロジーになりました。
# もし現役のmake職人の方がご健在であれば、古典芸能の継承者として人間国宝を目指せます。

(1) 読解性
make職人が滅亡した理由を探るまでもないかもしれません。makeでは「if (date(target) < date(source)) comamnd;」で作るMakefileは読解性は最悪で、作った本人でさえ3日過ぎればわからなくなります（とEmacs派の筆者が言っています）。

(2) 効率
makeはファイル単位で制御するので、ファイルアクセスが必要になり、実行速度は遅くなります。このため細かな制御をするmakeは効率の面から適しません。本来のビルドであれば、ccやlinkではどのみちファイルアクセスをするので問題はありませんが、メモリアクセス中心のコマンドでは実行効率が問題になります。

make職人の功績

前節のようにmake職人は苦悩していましたが、彼らが残した功績もあります。

(1) 自動化
make職人による功績はビルドだけに留まらず、各方面の「自動化」です。make職人いわく「自動化するためなら、どんな苦労も厭わない」。これこそがmake職人の誇りであり、make職人が残した功績です。つまりmake職人は手動を徹底的に廃して自動化を進めることが重要なmake職人の指針になり、その指針を他のエンジニアにも身を持って布教したことがmake職人の功績になります。

(2) CUIの再評価
make以降の統合開発環境では、ビルド構築はマウスなどでGUI（グラフィックユーザインタフェース）で行うのが一般的になってきました。一方、make職人はCUI（キャラクタユーザインタフェース）でビルドを記述します。
CUIではMakefileの再利用は容易ですが、GUIでビルド環境の再利用は面倒です。make職人が滅亡した後でも、make職人が訴え続けてきたCUIの有効性を人々に啓蒙しているのが功績になります。

(3) 依存関係の整理
ビルドするときのファイルの依存関係が複雑になりすぎ、やがて依存関係が巡回してしまう事故も起こります。このようにならないように、ビルド時の依存関係の整理を押し進めたのはmake職人でした。これが彼らの本来の功績です。ってこれは当たり前なのですが。

あとがき

今回は1980年代のUNIXの開発環境を見てきました。私自身はEmacs派だったのですが、当時はmakeによる開発環境を構築しているのが主流派でした。当時生まれたのが「make職人」と呼ばれる人たちです。複雑なMakefileを作り、ビルド（メイク）だけでなく、各種の自動化を行っていた人たちでした。今回はIDEの登場で今はいなくなったmake職人への慕情の思いを書きました。さらばmake職人よ、その功績はいつまでも。

（参考）参考文献