このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」(http://d.hatena.ne.jp/m-hiyama-memo/)のデータを移行・保存したものであり、今後(2019年1月以降)更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

しょうもない実力者の正体:アルゴリズム

公式マニュアルを見てもどこを探してもmakeが使っているアルゴリズムの記述が見つからない。誰もマトモに解説しようとしない。実験と予測の結果をメモしておく。

結局、実行すべきレシピ列(並列実行ならレシピツリー)を、与えられたゴールとルールセットと“ワーキングメモリであるファイルシステム”から決定し実行するソフトウェアである。実行によりワーキングメモリであるファイルシステムは書き換えられる(ことが多い)。実行中のファイルシステムの変更は各レシピの実行環境に影響するが、レシピ列の構築(=実行計画の作成)は終わっているので、レシピ列の構造には影響を与えない。

与えられたゴールノードをルート(ビルドフローの向きからは吸い込みノード)とするDAGを、ゴールから逆向きに作成し、実行は上流(ゴールから遠い所)から始める。直列実行なら、スタックによる呼び出し系列と考えてもよい。

DAGの作成アルゴリズム
  1. gを与えられたゴールとする。gは単なる名前。
  2. gと文字列マッチするターゲットを持つルールをルールベースから探す。
  3. まず、明示ターゲット(具体的な名前)とのマッチが試みられる。
  4. マッチする明示的なターゲットがないときは、パターンターゲットを探す。
  5. パターンターゲットにもマッチしないときは、ソースと解釈してファイルシステムで存在確認。
  6. すべてのマッチが失敗すればエラー終了
  7. ファイルシステムで存在するが、ルールを持たない(ターゲットではない)場合はそれをソースとしてマークする。ソースは当然に前提を持たない。
  8. マッチしたルールの前提を展開する。
  9. 前提のそれぞれを新しいゴールとして同じ手順を適用する。
  10. 展開すべき前提がなくなるまで繰り返す。
  11. エラーでないときは、DAGが出来上がる。
  12. DAGのノードはターゲット(タスクかも知れない)またはソース(実在するリソース)としてマークされている。DAGのターゲットノードには、対応するレシピが割り当てられる。レシピが存在しなくても空であってもエラーではない。
要処理かどうかの判断アルゴリズム
  1. ソースノードはターゲットではないので、要処理はあり得ない。
  2. ターゲットノードが.PHONYで登録されたタスクノードなら問答無用に要処理とマークする。
  3. ターゲットノードがファイルシステムに存在しなければ要処理とマークする(タスク扱い)
  4. ターゲットノードの前提ノードのなかに、ターゲットノードより新しいものが1つでもあれば要処理。
  5. 要処理とマークされたノードの下流(依存したノード)はすべて要処理とマークする。
DAGの実行アルゴリズム

※「警告」とは「Nothing to be done for ゴール」のこと

  1. DAGがソースノードのみなら警告して終了
  2. DAGのターゲットが要処理であるかをファイルシステムと照合してマークする。(マークのアルゴリズムは前述。)
  3. 要処理とマークされたノードを、上流に近いほうから直列または並列に実行する。
  4. レシピがエラーを返したときはそこで中断する。
警告メッセージ:

ターゲットにレシピがあるかどうかは問題にしない。

  • 最初に指定されたゴールにレシピがないときは警告する。上流のレシピは警告の対象にはならない。指定されたゴールの上流がすべてレシピなしでも警告はしない。
エラーの判定:
  • ソースノード(ターゲットにならないが前提となるノード)だけがリソースとしての存在を要求される。与えられたゴールから作ったDAGのソースノードが非存在のときだけDAG生成時のエラーとする。注意:.PHONY指定された名前はソースノードとは解釈しない。

書いていてイヤになる。腐っている。しかし、うまく動く。そして代替がない。悲劇だ。