

An implementation of djb's 'redo' make replacement - asb
http://apenwarr.ca/log/?m=201012#14

======
asb
The project README provides much more information:
<https://github.com/apenwarr/redo/blob/master/README.md>

------
wccrawford
Seems to me this is proof that you can lose an idea by telling someone about
it. I hear a lot here that you shouldn't worry about telling people your ideas
because ideas are worthless. I've never agreed with that.

Here we have someone who had a really great idea, did part of the work, and
then told people about it. Then he sat on it and didn't release. Someone else
came along, loved the idea, and wrote it from scratch in a month.

Does the original author care? Probably not. He's probably happy to see it be
used. But if it had been a money-making idea, he'd be a lot less happy.

Software development is a very fast-moving field, and if you sit on your ideas
at all, someone will do them instead. That's worth remembering.

~~~
tptacek
The original author is Daniel J. Bernstein, a mathematics professor at UIC,
who wrote an entire Sendmail replacement and an entire BIND replacement and
released them both to the public domain. Monetizing ideas is not what he does.

~~~
asb
Does anyone actually know of a commercial build system that's had any success?
I know commercial support is available for CMake and I expect some of the Java
build systems, but they're still all under a free software license.

------
beagle3
Yes, it is awesome; I remember reading about redo years ago and thinking "this
IS going to be awesome when released". I was trying to think of things that
make, with all its legacy, does better.

The only thing I could come up with so far is when one input has multiple
outputs (e.g. yacc; not quite dead, unfortunately). In gmake at least, you can
do:

%.h %.c: %.y yacc ....

In redo, you'd have to have to have specific blah.h.do and blah.c.do for each
blah.y file you have

The other thing is multiple ways to generate the same file; as far as I know,
make can do that but then the result is ambiguous - it's actually better than
redo doesn't try.

~~~
apenwarr
There are relatively painless workarounds for both situations.

For multiple outputs, you can just make sure that anybody who depends on %.c
also depends on %.h. This is pretty easy in the case of yacc. Then the rule
can just be one for creating the %.h and you'll still never be missing a build
rule.

For the problem of multiple ways to generate the same file (eg. generating a
.o from either a .c or a .cpp), you can solve that by simply putting the
decision logic into the .do file. This is actually better than making it
implicit, because you explicitly get to say exactly which priority order to
use in case both .c and .cpp exist. Make would silently pick one or the other
(after also wasting time evaluating a bunch of other irrelevant rules, like
ones for .pas files), which is no fun when you're debugging.

~~~
beagle3
Thanks (both for the reply and for redo! oh, and for bup and sshuttle!)

The multiple-output solution is not very painful, but is kind of error prone,
which stands out as redo is otherwise extremely clean, simple and robust.
Perhaps something like "yytab.h_and_yytab.c.do" in the filename could work?

Quoting myself: > it's actually better than redo doesn't try.

This was a type. I mean tot say "actually better _that_ redo doesn't try",
which is what you were saying too.

