Selling Points

Well, you can't buy Fix (since it’s free), but if you could these would be my selling points. (Stuff marked ‘NYI’ is planned, but Not Yet Implemented™).

From redo:

• Atomic builds – Target is written to a tempfile that is atomically renamed only if the build completed successfully; this means that if the target file exists, it is completely, and fully built (and never a partial, or half-updated file).
• Safe – Output from a failed build will not overwrite a previously successful build; also if you've manually modified a target file, 'fix' will notice this refuse to overwrite it (unless you explicitly –force this).
• Fast – Builds what is minimally required.
• Simple syntax – No new, specialized syntax to learn. All buildscripts are simple shell scripts.
• Reliable change detection – Fix looks only at the content of dependencies when determining whether they have been updated or not. (File timestamps or similar, are not used.)does not enter into the equation.)
• Funny filenames – You can use spaces, or whatever other characters you file like in your filenames.
• (NYI) Parallel builds.

From gup:

• (NYI) Reliable rebuilds – With fix you explicitly state whether a dependency is a source file (created by the user) or a target (build by fix itself). This allows fix to reliably rebuild stuff, even when build metadata have been lost. (Metadata still is needed for fast, partial rebuilds.)

From tup:

• (NYI) Fastest builds possible.
• (NYI) Exact builds – Never any need for clean builds. If you remove the build script for a target, then that target will automatically be deleted on next build. (Unless your target was manually modified, of course – see "Safe" above.)
• (NYI) Automatic builds – Fix can be used in automatic mode, wherein it uses inotify to detect source changes and automatically rebuild whenever something changes.

From git:

• Behavior – Fix is not dependent on a Makefile to reside in the current directory, but instead (in parallel to git) it expects that your current dir is inside a worktree. This similarity in behavior simplifies your work flow when you use both tools in your process.
• Config format – You might not need to use it, but if do, the config file format is the same as for git (i.e. a simple '.ini' type format). So if you want do define aliases, separate the build, source or target dir from the rest of your project, or other Advanced Stuff™ you'll feel right at home.
• Option names – Option names are intentionally the same as for git, whenever applicable.
• Environment variables – Where git uses a bunch of $GIT_* variables to keep track of stuff, fix has a bunch of variables starting with $FIX_*.

And beyond:

• Self-contained – Fix does not require any libraries or modules, its only requirement is Perl. Installation is dead simple; simply put the fix program somewhere where you can reach it. (To simplify it use you might want to put it in your project and make sure that it is in your $PATH, but that's really up to you.)
• (NYI) Separation – If you so desire, you can use separate dirs for buildscripts, source files and targets. This is useful to avoid having your project dir littered with .fix files, or if your source files all happen to reside on a read-only media.
• Configurability – Each build project can be configured separately. You can add project-specific paths to $PATH or configure fix aliases to simplify your workflow etc.