タスクランナーとしてのMakefile
#linux #make
そもそも巷で使われているところの「タスクランナー」が「項書き換え」、もっと卑近に言えば「エイリアス」でなかったことのほうが少ないのではないか
本当に欲しかったのはMakeじゃなくてエイリアスを集合的に管理するツールなのでは？
文脈1 職場のプロジェクトに必ず配置しちゃうMakefileの話
Makefileにタスクを書いてタスクランナーとして利用している。
Makefileのコメントを拾ってドキュメンテーションを生成するようにした。
その仕組みをエンジニアリングした。
windymelt.icon
百も承知だろうが、Makefileはそういう用途に使うものではない。
その方向でドキュメンテーションのためのエンジニアリングを行うのは完全に筋が悪い。
文脈2 Makefileを便利コマンドメモとして使うことに対する違和感 | takeokunn's blog
文脈1に対する批判
ドキュメントはMakefileではなくREADMEに書くべきである
npmなどが持っているスクリプトランナー機能を使うべきである
正規表現はメンテナンス性が低い
windymelt.iconこれはごもっとも
windymelt.icon
そもそもMakeってコケるとたいして親切でもないエラーを吐いて止まるので、初心者向けタスクランナー？としてもそんなに向いてないと思うんですよね
オメーんとこじゃどうしてんだよ
windymelt.icon社の自分のチームでは
環境構築はDockerで統一している
エンジニアもデザイナも同じ環境が立つ
Makeは本当にmakeしているときには当然使う
ファイルを作るためにコマンドが必要で、それぞれに依存関係がある
本当にmakeしたいのはエンジニアだけ
そうでないときはpnpm runで書いている
自分が今見ているプロジェクトはNext + TS ときどき Python で開発している
node_modulesに入っているコマンドを実行したいならpnpm runを使うのが一番手っ取り速い
簡単な内容ならシェルスクリプトで、条件分岐しはじめたらすぐにTypeScriptに移行する
tsxによる実行をする
提案
direnvでやる
direnvではエイリアスはいじれないが・・・
PATHはいじれる
PATHで特定のプロジェクト内のディレクトリにパスを通す
中身はただのsymlinkになっている
symlink先は同一のスクリプト
スクリプトは$0を読んで自分が誰として振る舞うべきなのかを理解する
busybox方式
スクリプトは設定ファイルをもとに別のコマンドを実行する
なぜ
Makefileのデバッグは困難である