Tired of make. Anyone interested in a guile-based replacement?

[Rob Browning <rlb@cs.utexas.edu>]

I really don't have the time to tackle this by myself, but I'd
*really* like to implement a scheme-based make replacement.  I was
just curious about whether or not there were others interested in the
same thing?

I have some ideas about what I'd like (I'd like to borrow some clever
tricks from "cons"), but I could only tackle this if I had some others
willing to help with the code.  The biggest stumbling block I can see
is getting a workable pattern based dependency chain builder
algorithm. i.e. given a set of rules like this (the english words are
just for illustration, not how I'd define the syntax):

  ("(.*)\.h$" "(.*)\.cc$")

  can produce ((string-append (dependency-match 1) ".o"))

  via (lambda (dependencies targets)
       (shell-sequence
        (string-append "gcc -o " (car targets) " "
                       (string-join dependencies))))

find a chain of rules (if one exists) that will produce a given target
from the available inputs (very prologesque...) 

Anyway, here's what I said when I was discussing this with Donovan
(of RScheme):

"cons" is much better than make in some respects.  First off, your
build scripts are just perl scripts.  While I'm not a huge fan of
perl, as compared to make it's still a real language, and you get
functions, closures (sort-of), and everything else.  No more
ifdef/endef no-argument macro nonsense like you have in make.

The problem is that cons just punts entirely on the whole pattern
based rules issue.  It hard codes a couple and provides no way to
extend them.  On the other hand it does do a lot of other *really* cool
things like using md5sums instead of timestamps on file info which
inludes the command and args used to build the file, making it
virtually impossible to fool it.  It also does clever things like
automatic directory remapping so you can have a build directory that's
independent of the source directory with one command.  Then make clean
is a simple rm -rf build.  It automagically hard-links the source
files into the build directory (whenever that's possible) for the
compiles, and it notices if your editor does anything to kill the
hard-link and re-links it at build time if needed.  It's also been
clocked at well over 50% faster than make for large projects.

If you think you'd be interested in working on a scheme based build
manager, I would too, though I don't know if either of us really has
the time.  I have a good name for it, though: "summon" (either that
or "conjure") :>

Once you have the dependency rule finder/builder written, the rest
should be simple if you design the architecture right.  Most of the
core code should just be infrastructure that calls the right "thunks"
at the right time, and then add-on's should define those thunks
(objects) for different build actions/target types, etc.

Further, you could get rid of that $< nonsense since your action
callbacks would just be lambdas that take the targets and the inputs
as list arguments...

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930