Experimental Clojure Support

[Daniel Spiewak <dj...@gmail.com>]

http://github.com/djspiewak/buildr/tree/clojure

I took an hour or so and whipped up a *really* rough prototype for Clojure
support in Buildr.  Note that this is a totally divergent branch from
interactive-shell, which also includes some Clojure-related stuff
(specifically: the REPL).  I'm not strongly pushing for this in 1.3.4 or
even 1.4.0, but I thought maybe someone might find it useful.

This support *does* use the AOT compiler added in the 12/17/08 release, so
you'll need at least that much if you want to try this.  I'm using an SVN
snapshot myself.  By default, namespaces to be compiled are inferred from
the directory structure and the .clj filename.  I don't bother looking for
the :gen-class attribute, though that might be a good idea.  It is also
possible to override this auto-detection using the :libs option:

compile.with :libs => ['clojure.contrib.extras']

The compiler symbol is :cljc.

After compilation, any .clj file that was *not* compiled will be copied to
target/classes.  This actually doesn't quite work with the auto-detection,
apparently because of a bug in Ruby 1.8.7 in the Array#include? method.  At
least, it *looks* and *behaves *like an interpreter bug; I'm really not
certain.  Anyway, the worst that happens is all of the .clj files get
copied, so it's not too horrible.

The source is all there.  You guys are free to decide what to do with it.

Incidentally, implementing this support did reveal what seems to be a
weakness in the framework: its required compilation detection.  Buildr seems
to assume that everything compiles in a Java-like way, with each .java file
producing at least one .class file of the same name.  This causes some
annoying issues in Scala (usually resulting in scads of unnecessary
rebuilds), but it can be ignored.  Clojure however does *not* produce class
files in this fashion.  In fact, the only file you can count on for
`test.clj` is `test__init.class`.  As far as I can see, there is no way to
represent this appropriately in the framework (since `specify` requires
e.g.  :target_ext => 'class').  This also limits future (more advanced)
detection possibilities like a port of SBT's Scala compiler plugin.  Am I
just missing something in the core framework?

Daniel