結局のところ
- makeはリソースが生成されるかどうかに一切関与しない。それはレシピが勝手にやること。
- なので当然に、makeはリソースが生成されたことをまったく確認なんてしない。関係ネー！
- ターゲットがリソースである必要はない。
- とはいえ、ターゲットが実在リソースであるかどうかのチェックはする。なければタスクと再解釈。これが諸悪の根源。
- 存在しないモノのタイムスタンプは、左辺では-∞、右辺では+∞で計算する。存在／非存在の条件ごとに分けて考えもいいけど。タイムスタンプの全順序構造だけではたぶん合理化できない。たぶんだけど。
- ほんとにリソースとしての存在を要求するのは（グラフ上の）ソースノードだけ。
- ソースノードは、ターゲット（ゴールも含めて）ではなくて、かつ、前提であるノード。ターゲットではないのでタスクでもない。つまり、ルールにより定義はされてない。
- ソースノード以外でリソースとして存在しないものは、すべてタスク扱いする。
- タスクの本体（レシピ）がないことは問題ではない。
誤解の源はミスリーディング（ミスディレクション）な用語法と不十分な説明：
- リソースではないターゲットも「ファイル」と呼ぶことがある。最悪。
- ターゲットとゴールを区別してない。
- レシピの実行を生成／ビルド／更新とか再生成／再ビルド／再更新とか呼んでいる。これでは誤解される。
- 生成なんて関係ネー！ 単に実行するだけ。実行される内容も関係ネー！
- 構文的なルールの分解と集約がちゃんと説明されてない。
- 組み込みルールの挙動が分かりにくい。組み込みルールはなくすべきだと思う。
2016年1月4日（2016-01-04 - 檜山正幸のキマイラ飼育記 メモ編）から今日１月６日まで、makeについて調べたが、感想は「酷い」「なんってこったい」。
空レシピに関する奇妙な仕様は結局は謎のまま。想像だが、過去になんらかの現実的な問題があり、対症療法的に変な仕様を入れたのだろう。互換性からそれが維持され、合理的な説明ができないまま残される。そのせいで他の部分の整合性にも影響する。
一貫性がない状態でさらに機能拡張するが、もとが不整合なモノに継ぎ足しをしても整合性が回復するわけもなく、よくて過去の不整合のまま、たいていはより悪化して説明不能となる。そうこうしているうちに、不整合を導入する根拠だった事情も忘れ去られ、謎のままに腐る。
インターネット上の情報はもちろんのこと、市販書籍にも嘘があり（「レッドヘリング」参照）信用出来ない。実験するか、ソースコードを読むしかない。まー、最終的な確認手段があるだけマシだけど。
歴史あるソフトウェアによくある現象だが、不適切な言葉や曖昧な言葉がそのまま使われ続ける。
- ターゲット（多義語過ぎる）
- 暗黙ルール（曖昧）
- 擬似ターゲット（単なる「みなし」かPHONYされてるか不明）
- ゴール（役に立つ概念だが、ちゃんと使われてない）
それでいて説明に効果的な概念・言葉は使われない。
- ソース（非ターゲット前提ノードで実在するリソース）
- ルールの分解（分割）と集約。これは極めて重要。
- リテラルターゲットとパターンターゲット
- タスクとリソースの区別
- みなしタスク（PHONYされてない気持ちの上でのタスク）
- 実行計画グラフ（ゴールから逆方向に伸びるDAG、末端は前提なしターゲットか実在するソース・リソース）
正確な理解を与える説明がない（公式マニュアルでさえ）ということは、多くの人が正確に理解しないで使い続けているのだろう。それでも十分に役立つのは凄いが。
