On Tue, Jun 29, 2010 at 11:31 PM, Robert Goldman rpgoldman@sift.infowrote:
On 6/29/10 Jun 29 -3:13 PM, Vsevolod Dyomkin wrote:
Robert,
That's why I've started developing this topic of improving version support in ASDF (and not elsewhere), because if versions need to stay there, they preferably should be only there to adhere to the DRY principle, and if they are only there, they need to be supported well :)
Yet, I agree with Faré, that it's much easier to perform dependency management separately, and, if we go further along this line, completely take it out of ASDF and leave ASDF just as a build tool. Although that is highly unlikely to happen :)
Here I think I disagree with Fare. I think a build tool needs to "know" when dependencies are broken, and having it try to blindly load systems that are named the same, but that are of the wrong version, seems deeply undesirable to me.
To be honest, I don't think it's particularly helpful to think of ASDF as a "build tool." I think that, given CL's nature as a dynamic language, it's more productive to think of ASDF as a tool for loading software *and maintaining consistency of the lisp image*.
That's what I had also had in mind, when figuring out how to solve dependency conflicts.
ASDF must react to changing states of systems within a long-term running lisp session, which is very different from the much simpler task that must be performed by make.
Even taking that into account, I think that it's possible that having make be only a simple build tool may not be ideal. I'm sure we've all had one of those experiences where we thrashed about and lost a bunch of time because of version skew when building a system through make. For that matter, configure is essentially an expert system that tries to guess, based on various probes, whether version dependencies are satisfied...
best, r