6 ms·
Conventions are great, but that doesn't look like anything specific to make, a shell wrapper could do that: #!/bin/sh case $1 in init)
by txutxu 4y ago
Conventions are great, but that doesn't look like anything specific to make, a shell wrapper could do that:
#!/bin/sh
case $1 in
init)
... do whatever for each project init
;;
start)
... do whatever for each project start
;;
test)
... do whatever for each project tests
;;
*)
echo "Usage: $0 init|start|test" >&2
exit 1
;;
esac
In my home/personal projects I use a similar convention (clean, deploy, update, start, stop, test...), I call those little sh scripts in the root of the repo "runme".
The advantage could be, maybe, no need to install make if not present, and no need to learn make stuff if you don't know it.
Sometimes they don't match the usual words (deploy, start, stop, etc) but then I know that if I don't remember them, I just type ./runme and get the help.
For my scenario, it's perfect because of it's simplicity.
- dymk 4y agoA shell wrapper could do that, but Makefiles are a DSL to do exactly that with less boilerplate.
- marcosdumay 4y agoAnd have a nice inbuilt graph runner if you decide one task depends on another...
- tom_ 4y agoComplete with automatic parallelization if you ask for it! And automatic KEY=VALUE command line parsing, default echoing of commands (easily silenced), default barf on subprocess failure (easily bypassed). The variable system also interacts reasonably sensibly with the environment. I've never rated Make for building C programs, but it's pretty good as a convenient cross-platform shell-agnostic task runner. There are also several minimal-dependency builds for Windows, that mean you can just add the exe to your repo and forget about it.
- marcosdumay 4y agoTo tell the truth, make sucks incredibly for building modern C programs. There are just too many targets. It's why all of them generate their makefile with some abomination. But it is still a great task runner.
- natrys 4y agoTbf, that particularity is easily achieved in shell scripts too: task1() { echo hello } task2() { task1() echo world } "$@"
- garblegarble 4y agoBut now update it to not re-run tasks unnecessarily - it's already wordier than a shell script right now. Meanwhile, in Make that's task1: echo hello task2: task1 echo world
- natrys 4y agoTrue, that's where Make shines. Though given the popularity of so many Make alternatives (the strictly subset of command runner variety, like just[1]) who keep its syntax but not this mechanism, I wonder if for command runner unnecessarily re-running dependencies is really a big deal. Because quite often the tasks are simple and idempotent anyway, and then it's a bit of a hassle to artificially back the target by a dummy file in Make (which your example doesn't do here e.g.). [1] https://github.com/casey/just https://github.com/casey/just
- Izkata 4y ago> I wonder if for command runner unnecessarily re-running dependencies is really a big deal. I've used in in the past with python/django roughly like so (untested from memory, there may be a "last modified" bug in here that still makes something run unnecessarily): .PHONY: runserver environ: python -m venv $@ environ/lib: requirements | environ . environ/bin/activate && pip install -r $< touch $@ runserver: | environ/lib . environ/bin/activate && python manage.py runserver [foo] Setting up these prerequisites takes a while and doing every time you start the dev server would be a pain, but not doing it and forgetting when requirements were updated is also a pain. This would handle both.
- datashaman 4y ago
- whateveracct 4y agomake gives you autocomplete more easily for free. One reason I use it always.
- nrclark 4y ago+1 for this, free autocomplete is the reason that I love using Make as the top-level tool, even if the actual heavy lifting is done by CMake or something.
- kazinator 4y agoYou can make "make init" work on Windows and Unix if you work at it, out of the same Makefile. The above won't.