Goredo 1.0.0 release, an implementation of redo build system proposed by Daniel Bernstein

The first major release of goredo, an implementation of the redo build system, proposed by Daniel Bernstein (DJB) as a replacement for Make. Goredo is written in Go and is distributed under the GPLv3 license.

Redo addresses fundamental problems and fixes Make flaws such as:

  • no atomic assembly of targets out of the box;
  • practical failure (at least when parallelizing assemblies) when using recursive Make ( Recursive Make Considered Harmful (by Peter Miller) ) calls due to lack of locks or global state;
  • potential inoperability determining the obsolescence of a dependency when using mmap, NFS, FUSE, VCS technologies due to the use of mtime;
  • inability to dynamically set dependencies;
  • no automatic dependency on the build rule, difficulty in creating dependencies on environment variables;
  • not being able to have targets with spaces in their names.

Compared to other build systems, redo:

  • has a minimum entry threshold: no need to learn a new language, syntax or dialect: for most projects, it is enough to know and use exactly one additional redo-ifchange command. A full description of redo might fit on one screen page ;
  • is completely independent of the programming language and target language used: by default they are written in the POSIX shell, but they can be in anything else, including binary executable compiled programs;
  • can set dependencies on non-existent targets (redo-ifcreate);
  • very easy to implement: can be implemented in 100 SLoC on POSIX shell or 1kLoC in pure C, with the possibility of parallelization and the continuation of assemblies, including the full implementation of the SHA256 hash;
  • may not require the installation of any additional software (as on BSD systems you have to install GNU Make) for the end user: pure POSIX shell apenwarr / minimal / do implementation takes up 1/3 of the GPLv3 license and can simply be included inside the tarball of the program.

Where goredo differs from other redo implementations is:

  • various user-friendly sanity / safety checks for incorrect target behavior;
  • ability to write stderr output of targets to disk, with TAI64N timestamps;
  • parallelizing assemblies, optionally without limiting the number of tasks;
  • umask-friendly;
  • high speed, especially compared to the popular apenwarr / redo implementation;
  • assembly state is saved in human readable and machine friendly recfile -ax;
  • passing functional tests from apenwarr / redo and redo.sh implementations.
/Media reports.