Hacker News new | comments | show | ask | jobs | submit login

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
            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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact