> "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 p

> "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.