On Tue, Jun 29, 2010 at 11:31 PM, Robert Goldman
<rpgoldman@sift.info> wrote:
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