I love the make reimagination in plan 9: mk. In my experience ok is easier and slightly saner than make. On unix like systems you can get it from plan9port, along with other gems, such as acme.
From what I see it is almost* strictly less useful than BSD make, which (IMO) is strictly less useful than Solaris make, all of which are strictly less useful than GNU make. It only might be more useful than SysV make.
* Regex support is unique, but you know what they say about solving problems with regexes, and you can usually do any useful think with `subst` and `word`. The `Pcmp -s` at first seems unique, but can easily be replaced by some stamp/dep file logic, with much better performance.
Don't get confused by the fact that `automake` chooses to maintain compatibility with versions of `make` more than 4 decades old.
I haven’t tried every version of make there is, but a few things about mk off the top of my head:
- Readability: $target, $prereq, $stem is much easier to read than Make’s $@, $<. Any white space can be used to indent.
- Flags after the target to do useful thing such as autodelete target om error (no more confusion on about partial files), and controlling verbosity, and specifying virtualness.
- Stricter when dealing with overlapping targets.
- Has a flag for printing why each target is being generated.
- Regex in targets is sometimes really useful! Taken together with the strictness towards overlapping targets this leads to less confusion overall.
This was going through my head, too. Though I am somewhat doubtful whether it would be a win on Linux. Mk's ergonomics come from leveraging the cohesiveness of Plan 9 as a system, IMHO.
That said, the automatic variables ($target, $stem, etc.) are more descriptive than those of make ($@, $*, etc) since the former are just normal shell variables passed in at rule runtime I think.
Do you pull the entire toolchain inside the makefile if it doesn't exist in the host? Or you're just using it as a glorified alias over the (rather arcane) podman container run/docker run calls?
Also, how do you solve the problem of actually bootstrapping over different versions of docker/podman/make? Do you have some sort of ./makew like how Maven uses to bootstrap itself?
You certainly can have Make pull in dependencies... But I would usually just have Make look for the dependencies and ask the user to install them.
You would want to mark the dependencies anyway, since when you update your compiler, IMHO, that invalidates the objects compiled with that compiler, so the compiler is a dependency of the object.
That said, I don't distribute much software. What works for personal software and small team software may not be effective for widely distributed software that needs to build in many environments.
I do the same except I use shell scripts. script/fmt, script/lint etc are consistent across projects even though the implementation details differ. I only use make for actually making files. It’s great for that, but it’s a pretty crappy replacement for a shell script.
In my projects, whether the language is Go, Rust, Python, typescript, or even Android, there are standard make commands, if applicable, always work
Once might migrate from one build system eg pipenv to poetry to uv, but the high level `make format` commands doesn't change.