"I think that djb redo will turn out to be the Git of build systems."

http://pozorvlak.livejournal.com/159126.html

by jerf • 16 years ago

147 49 16 years ago

pozorvlak.livejournal.com

epistasis2• 16 years ago

Reading the title, I thought djb had implemented a build system and I was extremely excited. Still quite interested, but it doesn't have nearly as much allure.

bkudria• 16 years ago

He didn't implement it, but he designed it in quite some detail, as far as I understand.

ehsanul• 16 years ago

I urge you to look at the link to djb redo posted in the beginning of the article. It's quite a teaser: http://apenwarr.ca/log/?m=201012#14

jerf• 16 years ago

Yes, there's code. I had to choose between linking this or following further down the chain and thought this actually did add something, in that while I could have gone to apenwarr's post directly or linked the the design doc it would have sunk without a trace.

epistasis2• 16 years ago

Yes, and I thank you for linking the way you did! I was mostly commenting on djb's reputation for creating extremely robust software, and that it's difficult to refer to this without implying that djb implemented it. However, I'm sure that apenwarr is also an excellent programmer, and as a regular abuser of Make, I'm going to give his redo implementation a shot, especially since djb's design fits my use case much better.

regularfry• 16 years ago

Interesting that git and redo share the problem of providing POSIX utilities on Windows. Interesting also that nobody seems to have suggested a merge between the two. If redo is that small, would it not be feasible to package it as git-redo and not solve the same problem twice?

uxp• 16 years ago

git and redo have nothing in common, except for being a utility developers may use.

If nothing else, they should never be merged because they are trying to provide a POSIX utility, which should always be: "Do one thing and do it well"

bryanlarsen• 16 years ago

Interesting thought, except the article specifically says that git does NOT have this problem.

krakensden• 16 years ago

That's because there is nothing about git that requires you to implement it with sh, that was just the way it was written. `redo' has you literally writing shell scripts to describe the construction process, which means you either need sh, or you need to write entirely new scripts for running on Windows

coliveira• 16 years ago

redo has the same problem of git because both are supposed to be used in as a small part of the UNIX environment. In this regard, it is not different from make.

justinsb6• 16 years ago

I agree with the blog, in that it seems disappointing that it doesn't integrate fabricate.py/memoize.py automatic-dependency-detection via strace. Those projects seem to advance the state of the art a lot more as a make-replacement. The git analogy is great though; while in general I think there should be a very high bar for throwing away working systems like make, in this case there's a potentially worthwhile set of different ideas: hashing for change detection, strace for dependency detection, and using scripts/whatever instead of a make-specific DSL.

unshift3• 16 years ago

how does automatic dependency detection using strace work?

pyre• 16 years ago

Maybe you get strace output from a running program and it uses that to evaluate what dependencies/versions you need?

justinsb6• 16 years ago

http://benno.id.au/blog/2008/06/06/memoize-build-framework

Peaker• 16 years ago

Does the strace approach allow parallelizing the build?

justinsb6• 16 years ago

I suspect you'd have to repeat a task if you discovered that it was dependent on another task's output. You would still discover this though, so your final output would still be correct.

erickt2• 16 years ago

I agree, I feel like redo isn't going far enough. I'm not sure if I'm missing something, but semantically this is very similar to make, even though it looks like it is a better syntax.

Of course, I'm completely biased :) I have my own build system called fbuild (http://github.com/erickt/fbuild) that's conceptually similar to fabricate/memoize. There's also mem (http://srp.github.com/mem/getting-started.html) and wonderbuild (http://retropaganda.info/~bohan/work/sf/psycle/branches/boha... -- although that link appears to be broken at the moment) if you're interested in some other projects that have similar roots.

I believe the key insight that we all independently made is that we can use the procedural execution stack for the dependency tree, and cache the function arguments and results to avoid work duplication. I believe this helps someone reason about what's going on in the build system compared to the declarative make systems because you can easily trace the inputs and outputs of some dependency.

Furthermore, you can do some pretty interesting things with this model if you push this idea. It's pretty simple to do integrated configuration and building. For instance in fbuild, I can do (fbuild uses python3 for it's host language):

    import fbuild.builders.c
    import fbuild.config.c.linux

    def build(ctx):
        # make a c compiler.
        builder = fbuild.builders.c.guess_static(ctx)

        # check if the system supports epoll
        if fbuild.config.c.linux.sys_epoll_h(builder).header:
            use_epoll = True
        else:
            use_epoll = False

        builder.build_exe('foo', ['foo.c'],
            defines=['USE_EPOLL' if use_epoll else 'USE_SELECT'])

I don't think many of the new build systems have looked into the configuration issue yet, which is a shame. I'd love to get some more ideas out there.

abdulla• 16 years ago

You might be interested in tup (http://gittup.org/tup) in that case. It finds dependencies by preloading a library that tracks all the file accesses that a program makes. IMHO I think this is a nicer approach than scanning strace output.

justinsb6• 16 years ago

Thanks - great link. Certainly much faster than strace!

wnoise3• 16 years ago

That can be handled entirely as a separate process that creates the dependencies that redo then uses. Separation of concerns argues that here's no need to tie them together.

In fact, they have an example of using gcc to generate header-file dependencies for C. A command-line tool that ran a command and spat out what files it accessed (via strace, dynamic library imposition, or even crazier methods like interpreting the binary) would hook into this system fairly seamlessly.

acon• 16 years ago

I really like the idea of strace for dependency detection. Unfortunately some people still use Windows which means I have to build on Windows. Does anyone know of an equivalent to strace one could use for dependency detection?

julian37• 16 years ago

Here is a link to the actual project:

https://github.com/apenwarr/redo#readme

DanielRibeiro• 16 years ago

Bernstein's work is really understated. On his site you can see a better glimpse in what he's worked on: http://cr.yp.to/djb.html

aidenn0• 16 years ago

I've always found something about djb a bit offputting. On the otherhand I have huge respect for the fact that when he sees something that he thinks is crap, he doesn't just bitch and moan, he makes an alternative (he bitches and moans as well of course).

bioh42_2• 16 years ago

Anyone know how redo compares to SCons/CMake/Ant?

beagle3• 16 years ago

- hundreds of times simpler (literally, if you count source code lines) - much easier to use in the sense that if you know the compile command you need to use (or the shell command or whatever), you already know how to use redo. - strictly a build system (CMake and SCons also do autoconf stuff)

njharman• 16 years ago

> just learned the basics because nontrivial version-control tasks just got so complex, so fast, it was usually quicker to go outside the system or even redo your work. Even thinking about what was going on was hard.

Is that really true? If so, that's pathetic and my respect for my fellow developers as largely competent professionals is misplaced.

mbreese• 16 years ago

In the old days (CVS), in some circumstances it was easier to avoid CVS than actually use it. CVS had a lot of warts that people generally just worked around.

spyne-02139• 16 years ago

It's called humility. You might look it up in the dictionary. While you're at it, check narcissism.

defen• 16 years ago

I guess you never tried renaming a file in CVS?

jonhohle• 16 years ago

I was enjoying the README and then I hit the part about using hashes to determine staleness, which is a good idea, but in the Python implementation those hashes are stored in a sqlite database. That seems a little excessive for a lightweight build system.

This is something that seems like it could be handled by the file system:

> $ cat .redo/artifact-source/src/path/to/file.c > f572d396fae9206628714fb2ce00f72e94f2258f

Or the reverse (hash to source path).

wnoise3• 16 years ago

This essentially turns "make" inside out. The makefile lists the dependencies and then has minimal glue to run the build command based on the dependencies. Instead, redo has the build commands invoke helper-tools to specify the dependencies.

Overall, I quite like it. One downside of the current design that I see as being somewhat hard to fix is that it doesn't handle build commands with multiple outputs. There are klugey workarounds, but they require either lying to redo about the true dependencies (which always fills me with dread), or making parallel build unreliable.

palish• 16 years ago

Those downsides sound massively important to fix.

wnoise3• 16 years ago

I've been agitating on the mailing list. True cases of this seem to be fairly rare, and I have come up with a slightly more effective (but ridiculous) workaround: have the multiple target command create an archive of its output, and then each actual target depends on the archive and extracts itself from the archive.

btipling• 16 years ago

The .do files are not even remotely readable. Try scons. At least you can understand what it's doing even if you know little about it with just a glance. None of this a.c.c.c.c,$1 gibberish.

dirtyaura• 16 years ago

IMO, build system for daily work has two very important properties: correctness and speed. Scons seems to get correctness right, but fails to be fast enough (see e.g. http://gamesfromwithin.com/bad-news-for-scons-fans)

Now, there is a third important property, which is clarity. But clarity for a new-comer is less important than a clarity for a person that uses build system daily.

I investigated several alternatives to make for our C++ game framework and settled to Waf. It's quite complex and side-effect of that has caused that we haven't integrated many of our tools to build system, just because doing so requires deep understanding of Waf model. Which I haven't acquired, well, mainly because of laziness.

Thus, clarity can affect both correctness and speed in practical situations of lazy people like myself.

What I like about redo is the simplicity. Based on my initial experiences, it seems that aside multiple output files problem, it doesn't get in to your way.

wybo• 16 years ago

As for the problem of cross-platform portability with new make-tools, and the complaint about having to learn a new language with make-replacements (two complaints raised in the posts comments), it might be possible to have a simple shell-script build the build-system, which then builds your code.

I made such a thing for C++ years ago. It adds a header and a footer to your pure C++ build-script, compiles it, and then runs it (compiling your program). It also included extension libraries that did some more advanced things, such as detect local dependencies, but still was very toy-like and unpolished. I never advertised it widely, especially after I started to use Ruby instead of C++ for the project it was related to.

Still, the basic idea of including the build-system in source-form with ones code might be interesting to some people... at least makes it easy to fix, deliver, and extend.

http://sourceforge.net/project/shownotes.php?release_id=3730... (unix / linux only)

"I think that djb redo will turn out to be the Git of build systems."

Related Stories