It's written on Raku and could be extendable by a lot of plugins - http://repo.westus.cloudapp.azure.com/hub/
run:
for name in a b c ; do \
some-command $$name \
done
run:
sh path/to/script.sh $(SOME) $(ARGS)
abc = a b c
.PHONY: run $(abc)
run : $(abc)
$(abc) :
some-command $@
make -j runthere is little point in using make if you're not taking advantage of its ability to understand dependencies of file driven workflows
an even more extreme build tool in the spirit of make is tup: http://gittup.org/tup/
tup instruments filesystem access to monitor what your build rules do while tup is executing a build. this means that tup can detect if a build rule reads from or writes to a file that isn't captured as a dependency in the tupfile (makefile equivalent). tup regards this as an error-- you're meant to update the tupfile to capture all the file dependencies so that tup-driven builds can be even faster and even more accurate.
I once spent too much time thinking about build systems, and tried to express the computation of executing an automated test suite for a monorepo python codebase with tup. The goal was incremental test: so that if you updated file a the build system would detect that libraries b, c and e had transitive dependencies on a and would run the corresponding subset of tests for a, b, c, e instead of running the full set of tests. If you rig a test runner to produce a test report file, you can regard testing as a function that maps an input test program to an output test report file, which can be modelled by make and tup. So far so good. Things start to get complicated as the behaviour of running a python script depends on all the other python files and libraries it dynamically imports at runtime, so for accurate incremental test you would need to map out all those runtime dependencies on other files and tell them to the build tool. It also got a bit more perverse with tup as by default the python interpreter generates pyc bytecode files and craps them all over the filesystem when executing scripts, and tup's reaction to that is "you promised me in your tupfile that running this build rule would only output a test report, but look, it also produced a pyc file! You liar! Build error." - so then it turns into an exercise in how to configure python and wrap various python tools so they fit more into the regime of deterministic functions that consume files and write files.