Skip to content

Instantly share code, notes, and snippets.

@azami

azami/memo.md

Created December 9, 2021 00:34
Show Gist options
  • Save azami/7e5dac50b6a981637f155f656c094622 to your computer and use it in GitHub Desktop.
Save azami/7e5dac50b6a981637f155f656c094622 to your computer and use it in GitHub Desktop.
Download ZIP
Makefileをタスクランナーとして使う場合のあれこれ
Raw
memo.md

Makefileをタスクランナーとして使う場合のあれこれ

休み中ずっと考えるのも嫌なので、書き殴って供養する

前提

  • 自分のローカル環境で動かすことについて記載している
  • これは個人の見解であり、異論反論は多々あると思う
  • Makefileをタスクランナーとして使うことへの異議はない。使いたい人は使えば良いし、そういうコードを排除する気持ちはない。

用途例

タスクランナーのタスクランナー

こういうケース

build:
  ./gradlew build
build:
  npm run build

なぜMakefileを使いたいのか

  • ドキュメントとして
    • 現代においてタスクランナーはさまざまあり、都度覚えて使いたくない。Makefileを見れば、何をするのかすぐに理解できる
  • 依存の解決
    • 実行前にコンパイルが必要な時など、動かしたい時に自動で依存する処理も行ってくれる

コマンド実行時Makefile経由で実行する

こういうケース

AWS_PROFILE := foo

deploy:
  npx cdk --profile $(AWS_PROFILE) deploy
run:
    docker-compose up -d

なぜMakefileを使いたいのか

  • ドキュメントとして
    • いちいちコマンドを都度覚えて使いたくない。Makefileを見れば、何をするのかすぐに理解できる
    • コマンドが変更されても、Makefileの実行方法は変わらないようにできるので、ユーザフレンドリー
  • 依存の解決
    • 実行前にコンパイルが必要な時など、動かしたい時に自動で依存する処理も行ってくれる
  • 煩わしいオプションを指定する手間が省けて、しかも必要に応じて変更可能

なぜわたしはMakefileをあまり使いたくないのか

あくまでも上記に書いてあるような使い方の場合の話に限る。 有用性はわかるので、なんどもかくけど、使いたい人は使ったらいいんじゃないかな。

  • 都度Makefileを確認しなければいけないのがめんどうくさい
    • タスクランナーのタスクランナーはタスクの二重管理になってしまっている。その中でどれがMakefile経由で実行できるのかみないとわからない。
    • Makefileのターゲットは自由記載なので、何かを実行するにしても、どれが実行したいターゲットなのかみないとわからない。慣れ親しんだコマンドやタスクランナーの場合は直で扱う方が確認コストがなく、わたしにはあっている。
    • Makefileのターゲット命名規則きめたらいい話では、になりそうだけど、それが守られている保証はないので、やっぱり都度Makefileを見る羽目になる。
  • 自由があまりない
    • 一時的にMakefileに書いてない処理を実行したいが、それをMakefileに書きたくない。 $(ARG) みたいなオプションとって自由に使えるモードがあったとしても、それをMakefileみて確認しながら使う方がだるい。

あんまやってほしくない

  • Makefileを通さないと動いてくれないように作ってある
    • 暗黙的な環境変数がないとエラーを吐いて死ぬ。つまりMakefileの何かに依存している状態。
      • 環境変数を事前に設定しとけよみたいな話だが、そもそもその依存本当に必要か？　ってことなんだよなぁ。
    • もっとも、動かすアプリケーションとしてそういう挙動が望ましい場合（例えばクレデンシャル情報を環境変数でわたす）や、コマンドの必須オプションについては、この限りではない

その他

デプロイ

Makefileを使ってデプロイするみたいな場合

  • パラメータが上書きされて本番環境が壊れたら困る！
    • そのパラメータはMakefileで上書きできる状態よりは固定値のほうがよくないか？
      • 一時的に変えたいとかなら、その時だけ変更できればいいのでは、みたいな気持ちはある。あるいは一時環境向けに本番で実行するターゲット自体わけるとか。
  • でいうと、そもそもローカル環境からのデプロイ、かなり好き勝手なことができるから、それ自体がリスクでは？

Makefile + Docker (+ Docker Compose)

本題とはずれるけど、Makefile + Dockerの合せ技があったりする。

わたし自身Dockerはそれなりに使うし、なんでDockerで動くようになってないんだよ、みたいなときはDocker対応したりする。 が、Docker使う使わないは、Makefileと同様、個人の裁量にまかせてほしいみたいな気持ちがある。 (もっともDocker環境でない場合のトラブルは自己責任でよい) Docker使うにしてもMakefileからの呼び出しを必須とすることの意味よ……。

  • Makefileで設定したパラメータをDockerfileに渡すみたいなことをしているケース

    • docker-compose使うと環境変数のデフォルト値設定できるから、それにしてくれや、みたいな気持ちがある。

  • dockerのビルドに必要な設定をMakefileでやっちゃっている

    • 最近はあんまりみない気がしているが、もしそれが必要でmake使え、とかなら、それはDockerfileでやってくれ

  • デプロイはMakefile+Dockerだと確実！　と思うじゃないですか

    • 上記にかいたように、デプロイに必要なパラメータが上書きできるとかだと、好き勝手できるので(略...
    • DockerでOS毎の差異がなくなるっていうのは幻想
      • いまはどうなのかしらないが、過去、同じDockerfileだけど、動く環境と動かない 環境みたいなのは何回か遭遇した
      • Docker on Mac はファイルシステムがクソノロ
    • Dockerを強要したい気持ちはわかる
      • が、そもそも個人のローカル環境から実行すること自体がリスクなのでは……にしか思わない
      • 本当にやるなら、デプロイ時に環境チェックして死ぬみたいな処理は入れた方が良い
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment