Tup – A file-based build system for Linux, OS X, and Windows

For clean, there is a solution if you are using git; tup can generate a .gitignore for all the output files, and there is a git command to remove all ignored files. I'm with you on "clean" being something that is both easy to implement and useful in tup.

The author's stance on phony and install isn't that they are unnecessary, but rather that they are orthogonal to the problem Tup is trying to solve. install and phony targets are handled by an external script. I will have either a Makefile or a shell script that perform the tup invocation as part of the process.

The thing that tup does well is prevent you from making certain mistakes in your build system. If you have a missing dependency, it will error out; I have actually found bugs in makefiles that I converted to tup.

First of all, I cannot express how much more I like it than make. If Tup is an option, I will use it.

What it does well:

1) It prevents you from making dependency mistakes: it hooks into the FS layer using fuse and tracks all input and output files that are inside your build directory. If you make any mistakes that could cause a future incremental build to be improper, it errors out rather than continuing.

2) It is opinionated about how your project should be structured. This has some negatives if you are trying to duplicate a particular structure from Make, but all in all does guide you in the right direction.

3) There isn't a lot of syntax to learn. This is good because the syntax is very different from anything else I've used.

#1 is really the killer feature for me; the amount of time I want to spend debugging makefiles is just slightly less than zero.

What it doesn't do, but I'm not bothered by:

Tup literally only manages commands that have 1 or more inputs and one or more outputs, and which must be run IFF the inputs have changed or the outputs do not exist; the outputs must be within the hierarchy of the project.

1) Configuration must be done before Tup is launched

2) Anything you might use a .PHONY for in make needs to be done outside of tup

3) Install commands must be done outside of tup. This means that configuring, installing &c. must be done outside of tup.

I find that having a make file that handles the above 3 steps works fine; others using tup tend to use a shell script.

What it doesn't do that I wish it did:

1) No clean command; I currently work around this by having it generate .gitignore file and git clean -X; still it's annoying that this isn't possible.

2) It does not handle paths with spaces. This is actually safe as it enforces relative paths, so if it works on your system it should work everywhere even if the project is unpacked to a path with spaces.

The apenwarr implementation includes a full Python implementation as well as a minimal version in I used the full redo implementation for some data processing tasks once, with mixed results. It was a situation where I couldn't declare the dependency graph up front. With redo, each target declares its dependencies locally when it builds, and redo assembles and tracks the dynamic dependency graph. It's pretty neat, but become difficult to reason about and debug. Could be that I never got comfortable with the new paradigm, or could be that essential tooling was missing, not sure. I still think redo is promising.

Anyway after a decade of messing with shiny new build tools, I finally learned to stop worrying and love the bomb (make). It's weird and warty but surprisingly capable. Worth the learning investment. Oh and jgrahamc's "GNU Make Book" is great. [2]

[0] https://github.com/apenwarr/redo

[1] https://groups.google.com/forum/#!forum/redo-list

[2] https://www.nostarch.com/gnumake