Makeの問題点を詳しくかつ具体的に指摘した記事を読んだ。

What’s Wrong With GNU make? - Conifer Systems
http://www.conifersystems.com/whitepapers/gnu-make/
via yendot

暇があったら抄訳したいくらい面白い。以下目次。

  • Language Design
    • Recursive Make
    • The Parser
    • Uninitialized Variables and Environment Variables
    • Conditional Syntax
    • Two Types of Variables
    • Pattern Rules and Search Paths
    • Other Missing Language Features
  • Reliability
    • Missing Dependencies
    • Last-Modified Timestamps
    • Command Line Dependencies
    • Environment Variable Inheritance and Dependencies
    • Multiple Concurrent Sessions
    • Editing Files During a Build
    • Cleaning Up Old Files
    • Path Canonicalization
    • After a Failed or Cancelled Build
  • Performance
    • Incremental Build Performance
    • Recursive Make and Performance
    • Parallel Make
    • Automatic Dependency Generation with Microsoft Visual C++
    • Builtin Rules
  • Miscellaneous
    • Silence is Golden
    • Multi-Target Rules
    • Warnings That Should Be Errors
    • Creating Output Directories
  • Conclusion

いちいちもっとも。自分もmake -C dirで文脈を捨てて再帰的にビルドしているこ とがあったので反省。すぐにSConsやOMakeに移行するわけにいかないので、しば らくはmake、それもGNU Makeを使い続けるだろうけど、理解した上で使わないと いけない。

関連して、いまやクラシックな1998のPeter Miller, “Recursive Make Considered Harmful”を読んでみた。

Recursive Make Considered Harmful
http://miller.emu.id.au/pmiller/books/rmch/

要するに文脈情報が失われるような分断をしちゃだめってこと。

第8章が興味深い。なぜこのような悪い慣習が延々と続けられているのかを考察 している。

8. Literature Survey
…
It is interesting that the problems of recursive make are rarely mentioned in the very books Unix programmers rely on for accurate, practical advice.

  • オリジナルのmakeの論文（1978）では再帰makeには触れていない。

  • GNU makeのマニュアル（1993）では、数箇所で再帰makeに触れている。しかしそ の問題点については書かれていない。

  • Nutshell book（1991）では、再帰makeを全プロジェクトmakeよりも推奨してい る。でもその2段落後の文章では、すべてのファイルを単一のディレクトリに収 めることが良いと述べている。ディレクトリを分けることとMakefileを分ける ことを混同しているようにも読める。

  • BSD makeのチュートリアル（1988）は再帰makeには触れていないけれど、 MakefileとDAGの関係には触れている。

同じようなことを自分もやりかねないので耳と心が痛い。読み手からのフィード バックがすぐに書き手に伝わって、楽に直せる仕組みがあればいいのに。

Other Articles