On Mon, Apr 13, 2009 at 3:22 PM, Laurent PETIT <laurent.pe...@gmail.com>wrote:
> Hi, > > 2009/4/14 bradford cross <bradford.n.cr...@gmail.com> > >> >> >> On Mon, Apr 13, 2009 at 2:31 PM, Stephen C. Gilardi <squee...@mac.com>wrote: >> >>> 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.) >> >> >> Yes, I have had nasty issues with this in the past. IMO, explicitly >> declaring deps and not relying on transitive resolution is the only way to >> go. >> > > I don't understand, the example given by Stuart does not rely on any > transitive resolution mechanism, but rather plain explicit dependency > declaration. So I think that transitive resolution is not the problem here. > The problem is that the compilation of A had a side effect left that the > compilation of E benefited from. > Right, let me restate it a different way. The goal is to enforce explicit deps so that you cannot rely on side effects that transitively resolve a dependency. My point is there are a couple ways to deal with this: 1) each unit (project or whatever you want to call it) builds in a different process 2) static analysis or dynamic analysis is injected into the build pipeline and causes failure (or gives warnings) if you are relying on a transitive resolution. > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
