The issues 2-5 in the "only make" section are non-issues

[ghost]

• Changes to the Makefile do not implicitly trigger rebuilds

It takes couple of lines of make to add this though:

%.c: Makefile
	touch -- $@

• Dependencies on directories is not really possible

Also just a few of lines of make:

.PHONY: dir
dir/whatever:
	touch -- $@
dir:
	mkdir -p -- $@

Another way you could do this is this:

dir/whatever:
	mkdir -p -- dir
	touch -- $@

• Lots of output by default

It's often useful to know what is being done. If you don't like this then use -s.

If you want to make your Makefile silent by default then add:

.SILENT:

Note that you probably should have some condition where this won't be done so that you can get the output in case you need it.

• Rules with multiple output files are not really possible

Sure they are, again only couple of lines of make:

file1 file2:
	touch file1
	touch file2

[qznc]

Adding Makefile as a dependency is an ugly hack. It is too conservative for example. It rebuilds on any change to the Makefile. More intelligent build systems can figure out which rules exactly have changed.

For directory dependencies, there are lots of proposed solutions. It is not clear to me which is best, which means the problem is not solved yet.

For silence, the best behavior in my eyes is to show the output for failed goals only. Your suggestions do not provide that.

Finally, the multiple output issue. You ran right into the trap. Your snippet is equivalent to the following and I'm pretty sure that was not your intention.

file1:
    touch file1
    touch file2
file2:
    touch file1
    touch file2

In summary, I'm not convinced. The first two are borderline. Personally, I can live with the workarounds. Make has advantages like being available everywhere in return for these minor annoyances. They are still annoying.

[ghost]

Adding Makefile as a dependency is an ugly hack. It is too conservative for example. It rebuilds on any change to the Makefile. More intelligent build systems can figure out which rules exactly have changed.

You can achieve this by separating targets into separate makefiles and make only those targets' dependencies depend on that makefile.

For directory dependencies, there are lots of proposed solutions. It is not clear to me which is best, which means the problem is not solved yet.

Just because there are multiple solutions doens't mean it's not solved. It means it has been solved multiple times in different ways.

For silence, the best behavior in my eyes is to show the output for failed goals only. Your suggestions do not provide that.

.SILENT at least reports failed targets. What exactly is the problem here?

Finally, the multiple output issue. You ran right into the trap. Your snippet is equivalent to the following and I'm pretty sure that was not your intention.

This is true, this solution sort of breaks with parallelism, though this can be solved with .NOTPARALLEL.

[ghost]

Uses a POSIX/bash shell, which hurts portability

This is also wrong. You can change the SHELL to whatever language or binary that supports taking instructions from standard input. You can even change the SHELL per rule if you feel like it.

all: hello world

hello:
	@echo hello

world: SHELL := /usr/bin/python
world:
	@print "world"

[pfalcon]

These are hilarious "non-issue" nitpicks, dear ghost (now ghost). Everyone understands that the purpose of this repo is to c.r.a.p on as many build systems as possible, and that's very honorable goal! So, even non-issues are issues. In that regard, if you have a pet favorite, the right way to make it look better is to c.r.a.p more on all other systems ;-). And please concentrate on CMake - it's a c.r.a.p as hell, actually rampaging thru the ecosystem ;-).