[asdf-devel] [Sbcl-devel] Logical pathnames vs ASDF & SBCL
rpgoldman at sift.info
Mon Jun 13 15:01:32 UTC 2011
On 6/13/11 Jun 13 -8:51 AM, Chun Tian (binghe) wrote:
> OK, people, please clam down ...
> I suggest we putting our efforts on solving real issues but arguing. Today I
> heard that Faré just bought his first Mac computer, I believe he will take
> care of RMCL better than before.
I very much agree with this. Please also make allowances --- RMCL is an
obscure implementation of an already (regrettably) obscure programming
languages. Those of us trying to maintain ASDF may need very clear
assistance in replicating bugs related to this implementation.
[As a point of process, it might help us somewhat if these bugs would
appear on launchpad, instead of only on the mailing list.]
> I understand that Faré are trying to make ASDF2 perfect: supporting all
> available CL platforms so that other ASDF-based packages could have chances to
> run. From my personal view in these months, maybe ASDF2 grows too fast, as a
> build tool it grows even faster than other CL packages which do real world
> function. As a common Lisper using CL on work and maintain some CL packages,
> I think I just need:
> 1) asdf:*central-registry* works the same way as before,
I use asdf:*central-registry* as before, and have had no troubles with
it. I have done so on Mac, Linux and Windows, SBCL, ACL and (a little) CCL.
> 2) Quicklisp works,
I don't use this, but Xach seems to be actively monitoring the state of
ASDF, and I believe the record shows that bugs he reports have been
> 3) All my previous written valid .asd files won't fail.
I don't believe this should ever be a problem, with the proviso that
behavior may change as bugs are fixed (see below).
As Fare has said before, it would /really/ help if people would
contribute test cases that exercise the asdf:*central-registry*.
> other things, I don't care. I think Faré is a very good Lisp programmer, I can
> see this from ASDF2 source code, I hope Faré could help us (MCL users) solving
> necessary issues which is caused by ASDF2 development when Faré don't have a
> Mac, and no doubt all MCL users will say thanks. And I think every ASDF user
> should want it stable than feature-rich, maybe Faré could consider this option
> someway in the future.
There has been some feature addition, but there has been no substantial
revision of existing functionality, except in cases which were clearly
bug fixes (e.g., the badly broken module dependencies; the erratic
behavior of the :pathname initargs).
I would also point out that there are still some known bugs in ASDF
/that we did not put there/. We have not meddled with them precisely
because of concern for stability, and despite the fact that some of
these are clearly bugs, and even critical bugs. Chief among these is
the fact that ASDF does not notice changes in upstream systems.
ASDF 2 is, in fact, quite conservative in its changes. The primary
changes have been in attempts to make configuration more reliable across
implementations and operating systems. The DEFSYSTEM API has been quite
Attentive readers of this mailing list should be able to assess this
claim themselves. Reviewing their memory or mailing list archives, they
will find that a number of changes to the API, even such changes that
appeared to be clearly improvements, have been rejected on the grounds
of backwards compatibility and stability.
Indeed, if anything I would like to see a move to start an ASDF 3 branch
where some issues like the aforementioned system dependencies could be
addressed. I understand and respect Fare's lack of desire to operate
such a branch in favor of XCVB, however.
More information about the asdf-devel