Looks like a version of make optimized for running commands instead of builds.
Note that I have recently switched to Just (https://github.com/casey/just). While not technically the exact feature set as make, it covers all of the ground for what I typically do. It gets the benefit of history and discards a lot of make cruft to make a more predictable experience.
You're using make to run a bunch of tasks, including where tasks may depend on other tasks having been run before.
A task-runner tool like `just` is better suited to this task. https://github.com/casey/just
`just` has some nice UX improvements over `make`. (e.g. doesn't require soft tabs, can list recipes out of the box, recipes can take command line arguments, supports .env files, can be run from any subdirectory).
The Just command runner [1] is good, but is not as ubiquitous.
I think the main/only reason to go out of your way to use `make` as a task runner is its ubiquity.
However, if you're already using nix, it's probably not much of an issue to use a better task runner.
I'd recommend 'just' instead https://github.com/casey/just -- It has a nicer UX, with a few significant quality-of-life improvements out-of-the-box compared to `make`. e.g.
- you can get a list of tasks, and select one using `fzf` with `just --choose`.
- can inline use of bash, or python, etc.
- `just` automatically searches up a directory tree for a `justfile`.
Make has quite a few flaws, but it is near universal and a good location to centralize all required project work. Even if the entire task is defined in a shell script elsewhere. That being said, I have being looking longingly at just[0] which is not just concerned with compiling C, but has task automation builtin from the beginning.
C++ : C :: Just : Make
More sensible defaults, fewer footguns, just as expressive (pardon the pun), but still nearly the same syntax and paradigms so you don't have to learn a completely new scripting language.
The biggest downside, however, is that it's not installed by default on many systems and it's not in the official repos of some major distros. If that's a dealbreaker, stick with Make.
PHONY: comment
comment:
TEXT=“yes, I also wonder why people don’t use simple makefiles” $(MAKE) publish
publish:
echo “$(TEXT)”
Some “simple” things like passing arguments to a task become incredibly complex.I’ve been playing around with https://github.com/casey/just and so far it’s been very pleasant.
Just is a task runner (with full shell integration) that calls our turborepo tasks.
We define all of our tasks in one justfile (things like repo setup, syncing env vars, and compiling dependencies) and then link them to turbo processes which cache the result.
Massively reduced our cognitive load working with our monorepo, and is lightning fast.
If we ever want to change it will be simple to remove both, so we're not tied to the ecosystem.
[Just]: https://github.com/casey/just
The installation section has no direct body, but there are subheaders with the actual instructions.
just (at a glance) is like a Makefile, but with some nice UX improvements that make it worth using. e.g. with `just --choose`, it runs fzf against the targets.
Where it really shines are in places like monorepos where you may have many inter-related setup scripts, build commands or helper utilities.
You define all of your commands in one file (or multiple if you want a hierarchy) and can run commands from any subdirectory.
eg. You have a monorepo with a web server, and also a react-native app in separate directories, you can call `just build-app` in the web directory, or call just `start-server` when your terminal's current directory is 7 diretories deep in the mobile directory.
The amount of time I have saved cd'ing around has honestly been amazing. It's worth it's weight in gold, especially on large projects.
I built randomneo.city since people didn't like my comment on the randomgeo.city post[0]. Clearly I don't take downvotes well.
That said, the code is powered by SvelteKit, SQLite and open source:
https://gitlab.com/mrman/randomneocity
I have to say, I'm really starting to like building everything with SvelteKit -- I'm a huge 3-tier architecture fan, and it just doesn't make sense these days to add an API repo for most small projects now. Node + TS + SvelteKit does most (to be fair, so would Nuxt or Next). It's been a fantastically productive stack for me.
Things I still need to do:
- Add automatic scraping of neocities' sites so the site can stay up to date
- Filter out sites which aren't done (they all have the same text)
- Add chat/social features (???)
This was also a great chance to try out Just[1] which strives to replace make[2] -- it's been nice!
In classic distracted style I use just[3], make with good defaults[4][5] and my usual flavor of makefile[6][7] in the repo.
[0]: https://news.ycombinator.com/item?id=32305300
[1]: https://github.com/casey/just
[2]: https://www.gnu.org/software/make/
[3]: https://gitlab.com/mrman/randomneocity/-/blob/main/Justfile
[4]: https://tech.davis-hansson.com/p/make/
[5]: https://gitlab.com/mrman/randomneocity/-/blob/main/infra/Mak...
[6]: https://vadosware.io/post/setting-up-mailtrain-on-k8s/#step-...
[7]: https://gitlab.com/mrman/randomneocity/-/blob/main/infra/kub...
That said, I'm more concerned about the guidance to not use .PHONY and instead do this:
# Tests - re-ran if any file under src has been changed since tmp/.tests-passed.sentinel was last touched
tmp/.tests-passed.sentinel: $(shell find src -type f)
> mkdir -p $(@D)
> node run test
> touch $@
The author is right, that does use make in a more more idiomatic way by relying on a real file, but I see 2 major problems:* That's a lot of logic for something that should just be super simple.
* When I say `make test` I want it to run the tests. I don't care if they've passed before and the files haven't changed.
Really though, make just isn't a great tool for build scripts. The syntax is horrific and it's hard to scale it into something readable.
If I started a new project I'd probably consider Just: https://github.com/casey/just (though I haven't had a chance to use it myself yet).