I recently spent a week replacing all Makefiles in a reasonably complex embedded arm project I maintain with apenwarr's redo [1] (revamping our cobbled-together CI).. Which allows recursive make structured .do files, without tbe downsides - global dependencies and build state is cached across invocations in a throw-away .redo directory. It's an absolute joy to be able to stamp things that aren't files (eg docker containers) and just use one syntax (script of your choice) to orchestrate builds.
Cross-compiled kernel, bootloader, custom packages, full distro rootfs to final sdcard image without a single Makefile. I owe that man a beer.
[1] https://github.com/apenwarr/redo
In Recursive Make Considered Harmful (1997) [pdf]apenwarr
redo
Python2010–2023
apenwarr / redo
redo
Smaller, easier, more powerful, and more reliable than make. An implementation of djb's redo.
33Distinct people
42Mentions
0Explicit recommenders
1.9KGitHub stars
What to know before exploring
What it is
Smaller, easier, more powerful, and more reliable than make. An implementation of djb's redo.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year42 dated mentions
Observed mentions: 2010-12-14 12:59:14 UTC to 2023-04-25 13:22:40 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
redo - a recursive build system
Smaller, easier, more powerful, and more reliable than make.
This is an implementation of Daniel J. Bernstein's redo
build system. He never released his
version, so other people have implemented different variants based on his
published specification.
This version, sometimes called apenwarr/redo, is probably the most advanced
one, including parallel builds, improved logging, extensive automated tests,
and helpful debugging features.
To build and test redo, run:
./do -j10 test
To install it, run something like this:
DESTDIR= PREFIX=/usr/local ./do -j10 install
View the documentation via readthedocs.org
Visit the source code on github
Discussions and support via the
mailing list (archives).
You can subscribe by sending any email message to
redo-list+subscribe@googlegroups.com (note the plus sign). You can
send questions or feedback (with or without subscribing) by sending
messages to redo-list@googlegroups.com.
Read the full README on GitHubWhat Hacker News says
6 sourcesapenwarr's implementation of djb redo[1] contains a minimal, shell implementation of redo in its `minimal/` subdirectory.
It seems like the downside to using redo would be that there are .do files sitting throughout the source tree. It'd be nice if there was a way to consolidate several .do files into a single Redofile, similar to a Makefile or Sakefile.
Like the non-minimal redo, sake is also implemented in Python. I wonder how they compare, performance-wise.
[1] https://github.com/apenwarr/redo
In Sake: like make, but with shell scriptsIf you're interested in a make replacement, check out redo (designed by djb):
http://cr.yp.to/redo.html
https://github.com/apenwarr/redo
In Memoize – a replacement for make relying on straceAnyone interested in build systems should have a look at Redo (implementation here: https://github.com/apenwarr/redo )
In Ekam Build SystemThis article claims that redo suffers from several security issues at the very end. But can anyone explain to me how a userspace program that is run directly by the user can have any security issues at all? Also, apart from the PATH issue, all those "security holes" seem to require changing files, making them useless.
Besides, the author is wrong about the reasoning of apenwarr to implement #! processing[0]: it's done primarily to avoid having to make .do files executable. execlp() even executes /bin/sh all by itself if no header could be recognized[1]:
"If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)"
[0] https://github.com/apenwarr/redo#
Read the rest
> I build a _very_ paranoid Makefile that recompiles everything if it feels like anything changes.
Do you have some kind of way to verify that your makefile dependencies conform to your source dependencies? Is clang/gcc tracking sufficient for your use case? What about upgrading the compiler itself, does your makefile depend on that? If so, how?
Have you considered tup[0]? Or djb-redo[1]? Both seem infinitely better than Make if you are paranoid. tup even claims to work on Windows, although I have no idea how they do that (or what the slowdown is like). Personally, I'm in the old Unix camp of many-small-executables, non of which goes over 1M statically linked (modern "small"), so it's rarely more than 3 secs to rebuild an executable from scratch.
> (deterministic mode for ar)
Why do you care about ar determinism? Shouldn't it be ld deter
Read the rest
minism you are worried about?
[0] http://gittup.org/tup/
[1] https://github.com/apenwarr/redo