> You're using make to run a bunch of tasks, including where tasks may depend on other tasks having been run before.

And the cool thing is....it works for both!

It can represent an actual file (e.g. a compiled binary) or abstract result (e.g., a successful test).

Even for a Makefile, "start", "test", "install" are likely to be phony (and not literally refer to files with those names).

The execution of a "start" task defers the role of "has it already been done" to other places.

One way of describing "task runner" is "nicer UX for .phony targets".

I hear you, but you're running the other script unconditionally. If it downloads something, it will download it every time you run the first script.

In this simple case, make runs the other script conditionally, so it need not run every time.

There are at least two ways that this problem can be addressed. One is to support out-of-tree builds, one side directory per configuration. Builds based on the autotools do this by default.

The other is to use a separate build directory per configuration within the build. My current project uses local in-tree directories named .host-release, .host-debug (including asan), .host-tsan, .cross-release, and .cross-debug. All of them are built in parallel with a single invocation of Make, and I use target-scoped variables to control the various toolchain options.

The engineer's incremental work factor to add another build configuration isn't quite constant time, since each top-level target needs to opt into each build configuration that is relevant for that target.

> I hit the multiple outputs problem

I wouldn't really classify that as a problem in GNU Make, as long as you can specify the rule as a pattern rule.

I hear you on the testing problem. Make certainly behaves as if the Makefile's correctness isn't decidable. Even if you levied the requirement that a Makefile's decidability was predicated on the recipes being well-behaved, I'm not sure that the correctness is decidable.

Says who? Make is just as good at calling arbitrary code as Cargo. Including code that reaches out over the network. Have you audited every single makefile to ensure that isn't the case?

If you change a build flag, how aren't all the files affected?

>

> Best you can do is to run make -n target to probe, but it's possible to write Makefiles that run code even though -n is used, which will defeat such probes at distribution scale. It quickly becomes an exercise in heuristics and output parsing.

To be fair, I'm still yet to see a document clarifying how to use patterns with make.

What's built wrong is make itself. Because the signal it uses for "this dependency has changed" is the mtime, any change which does not move the mtime forwards will be ignored. Switching between concurrent git branches, for instance.

> Usually it means you've tried to manually re-create the inherent Make rules and have gotten it wrong somewhere.

And pray tell how do you "manually re-create the implicit make rules" when such rules don't exist? GNU Make has implicit rules for C, C++, Pascal, Fortran, Raftor, Modula-2, and assembly. That is, frankly, not much. And mostly outdated.

Make is so static that there was a Lisp interpreter written in make. Oh wait...

There are several mechanisms in make to have your rules dynamically adapt to your codebase, e.g. $(shell ...), $(wildcard ...), and pattern rules (and that's not all of them).

You just need to put a little effort to actually read the documentation, not just stop at finishing one of the plethora tutorials that stop after showing variables usage.

> We can do much better than Make.

You mean, "we can do much better than my `make' knowledge". Of course we can.

Makefile is for make, which “makes files”.

You don’t “task files”

*file in general is wrong. Of course it’s a file

That's exactly right, but notice that you are not actually using make at all any more at this point, except as a vehicle to run

check_query.sh && doaction

which is doing all work.

Make does have a lot of warts, but this isn’t one of them any more. Grouped targets were added in the most recent release of GNU Make, and they address exactly this problem.

Re: your other points, many of them boil down to “the syntax is weird”. I agree 100%, and also it’s not so tough once you get used to it. I use GNU Make for tons of things, and I like it a lot.

That's true, nothing stops you, though it is worth noting that no one actually does this, and there's a reason for that. So suppose you did this; how are you going to use that in a makefile?

> However, for the sentinel file pattern, the magic variable $(@D), which refers to the directory the target should go in, and $@, which refers to the target, are common enough that you quickly learn to recognize what they mean:

So, avoid using the magic variables, but actually you should use them because they're useful and common. Got it.

> The BUILD file abstraction is something like "I am declaring a C library with these sources and headers."

This is wrong. Even ninja has generic rules. Here's an example of a minimal makefile:

  OBJ = src/a.o src/b.o src/c.o
  libfoo.so: $(OBJ)
          $(CC) -shared -o libfoo.so $(OBJ)

There's no reason this shouldn't be possible with make; it just hasn't been implemented so. Do bazel/buck/please actually do this? As far as I know tup is the only tool that actually verifies inputs/outputs of rules, and it needs FUSE to do so.

> For example, unless you implement your own header scanning (or manually list your header dependencies) "make" won't know to rebuild a source file when a header changes.

At least with GNU make, it's very easy:

  CFLAGS += -MMD
  -include $(patsubst %.o,%.d,$(OBJ))

Make has problems, but the ones you listed aren't they.

Can you point to some documentation for this? I haven't been able to find anything.

I had always, perhaps erroneously, thought that the very first goal in the file was the default one.