3 ms·
I love makefiles as well and do something similar to OP: for every repo I contribute to, especially if it's not one of mine, I'll create an uncommitted makefile
by staticshock 2y ago
I love makefiles as well and do something similar to OP: for every repo I contribute to, especially if it's not one of mine, I'll create an uncommitted makefile to track all the shell commands that add up to my workflow within that codebase.
The ability to create dependencies between targets is the cherry on top, but the main value is just the ability to create a cheat sheet of shell snippets accessible via `make <target>` from the root of the repo.
Such a makefile is always (1) version controlled as a secret github gist (though, as personal rule, i never hardcode secrets into it), (2) committed & pushed on `make` (3) git ignored via `.git/info/exclude`. This has worked quite well for me.
One downside with this approach is that the best syntax for passing parameters down to the target from the shell is to use environment variables, which is a little awkward. `NAME=value make target` is less pleasant than `make target --name=value` would have been.
- Izkata 2y agoTake out the dashes and that's a supported syntax for overriding variables: NAME := foo test: echo "name is $(NAME)" $ make test echo name is foo name is foo $ make test NAME=bar echo name is bar name is bar