Hacker News new | ask | show | jobs
by shadowgovt 1256 days ago
It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job.

(I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).

6 comments

I generally find shell/npm scripts work until you get to the few cases that actually benefit from the dependency management and then you wish you'd just given in to .PHONY, no matter how inelegant it may be.
All of my dependency management issues are handled by npm.

The main problem `make` solved was not wasting work rebuilding dependencies that hadn't changed, but in 2023 on modern computers I don't notice the CPU cycles burned on that kind of thing.

(... if I do start to notice them, I reach for a tool like bazel, because it can handle spaces in filenames).

In our case we have most of the processes that are run by make tee their output into a project log directory. Then the make rules can use the log file itself as the dependency for the target. Works great in a lot of cases, and, you get the added benefit of being able to easily go back and observe previous process output and compare it across projects.
Oh wow, I can’t believe I’ve never thought of that. Simple and useful and a bit more elegant than having a phone output file that I manually `touch`.
The [Just] task runner can be what you want: it's simpler than Make, with less magic, but it allows to declare task dependencies.

[Just]: https://github.com/casey/just

I think .PHONY is mostly fine, but as soon as you have any sort of runtime arguments or interactive stdin/stdout you are definitely using the wrong tool.
I think the reason for the .PHONY is just so people don't have to ./

I generally reach for a shell script with "case" instead, though. Can always invoke make from the shell script.