Greetings! Some of the redo build system implementations (goredo, baredo) were already presented in this mailing list. I'd like to propose yet another redo - https://github.com/AndreyDobrovolskyOdessa/redo-c.
It implements the brilliant idea by Daniel J. Bernstein - http://cr.yp.to/redo.html. It is the fork of https://github.com/leahneukirchen/redo-c and follows its guidelines - portable C implementation with zero external dependencies - adding some features and extending functionality which may be of interest. What makes redo different from other build systems is an absolute decentralization. Such an approach leaves in the past problems with nested makefiles and grants extreme flexibility and reusability of redo-driven projects. However all known to me redo implementations try to be make-like and even make-compatible. They use the traditional and bullet-proof concept of the job server for parallel builds. In my opinion this concept is well suited for centralized systems but falls in contradiction with the redo decentralized nature. Independent redo instances can operate together over the same project tree if they are not locking on the busy target but visiting it later. Each instance is a single thread, never spawning another redo instance, spawning only recipes if necessary. Instances may be supplied with a traditional list of targets or with the roadmap dynamic data structure describing the whole project tree topology. Running redo instances in parallel is performed in the recipe layer. Project topology may be logged during the build process in the form of a Lua table, containing all the necessary information structured properly during sequential and parallel builds. Recipes' stdout and stderr may be included in such a log in the form of valid Lua multiline comments, if one of the standard output files was selected for logging. Loop dependencies are tracked unconditionally during sequential and parallel builds, including distributed build systems. Implementation details: - under-the-hood files use ".do.." prefix and share the same directory with targets - rules have names like ".x.y.z.do" instead of traditional "default.x.y.z.do" make it possible to use this redo implementation side by side with other redo implementations without any interference. Utility is UNIX-style - one task, text interfaces, no unnecessary output. Written with hope to be useful and emphasizing the clarity and perfection of D.J.Bernstein's design. Best regards, -- Andrew
