> "make install" for example is specifically something Tup can't do. This is trivially solved by having "install.sh".

`make` is different things to different people. What you describe, `make` as a tool to compute optimal strategies for recursive file-based build operations, is indeed its original purpose.

On the other hand, I tend to use `make` more as a standardized format for script collections. Whenever I open a new repository, and it has a Makefile in it, I'm very thankful because it's a useful jumping-off point for how to build and use the software contained in the repository. Therefore I do the same in my own projects. Even if the project is in a single language with established conventions, I tend to include a Makefile regardless as a way of documenting.

For example, if I have a Go project, I could rely on other people looking into it to know how Go is compiled, or I can just put in a little Makefile like:

  PREFIX = /usr
  
  build/foo:
    go build -ldflags '-s -w' -o $@ ./cmd/foo
  
  install: build/foo
    install -D -m 0755 build/foo "$(DESTDIR)$(PREFIX)/bin/foo"
  
  .PHONY: build/foo install

Which will make it entirely obvious to everyone, including non-Go-developers, how to build and install the software.