On Apr 13, 2009, at 4:58 PM, bradford cross wrote: I have written up my journeys so far: http://bradfordcross.blogspot.com/2009/04/clojure-build-and-dependency-management.html
Thanks very much for the write-up!Given the recent discussions and interest in dependency management I thought I'd mention an idea in that area that I think is a good one.
At ILC '09, Francois-Rene Rideau made a presentation about "xcvb": http://common-lisp.net/project/xcvb/which is intended to be a successor to Common Lisp's ASDF with some nice features.
One of the issues it addresses is the possibly problematic behavior of a "same world" compiler as we have in Clojure AOT: build dependencies which are intended to be explicit and correct can be incorrect, but accidentally work.
Here's an example:
A depends on B and C
E depends on A, B, and D, but only declares A and D
Compile A
Compile E
works
Now change A so it no longer depends on B.
Now compiling E "breaks". (And in the general case, the guy who made
the change to A knows nothing about E.)
In xcvb, the strategy they use to avoid that and make sure all dependencies are correctly specified is to make the compilation of each file start with the compiler's "image" in a known, minimal state. They break the build into a dependency discovery phase and a make-like minimal rebuild phase (which may actually use "make" itself) to accomplish this. The tradeoff in overall "system" compilation time is the reloading of compiled code every time it's needed rather than just once.
For us, the corresponding strategy would be that the compilation of each namespace should start with only clojure.core loaded.
We could adopt this strategy in a given Clojure build system without any changes to how Clojure works (by launching a new instance of Clojure for each compilation) which makes it particularly easy to experiment with.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
