[asdf-devel] ASDF 2.27 release candidate

[Faré]

GBBopen from svn trunk r1168 works fine for me using ASDF 2.26.45,
with or without the attached cleanup patch.

rlwrap sbcl --eval '(quote(#.(require "asdf")#.(in-package
:asdf)#.(upgrade-asdf)#.(load
"/home/tunes/quicklisp/setup.lisp")#.(progn(load-system
:gbbopen))#.(cl-user::gbbopen-test)))'
rlwrap sbcl --eval '(quote(#.(load
"/home/tunes/cl/asdf/asdf")#.(in-package :asdf)#.(upgrade-asdf)#.(load
"/home/tunes/quicklisp/setup.lisp")#.(progn(load-system
:gbbopen))#.(cl-user::gbbopen-test)))'

Note: the first cleanup in the patch, with subpathname, is not really
necessary and depends on ASDF 2.018 from October 2011.

What are you trying and what error are you getting?

Granted, the build infrastructure of GBBopen dates from ASDF1 days,
but really, a lot of it is just reinventing things that were done I
believe better and for everyone in ASDF2, and GBBopen should probably
adopt and embrace it.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
A real person has two reasons for doing anything ... a good reason and
the real reason.


On Fri, Dec 28, 2012 at 3:50 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> On 12/28/12 Dec 28 -9:55 AM, Zach Beane wrote:
>> Faré <fahree at gmail.com> writes:
>>
>>> OK, so 2.26.45 is my new release candidate for ASDF 2.27.
>>> Please grab it and test it.
>>
>> It still breaks gbbopen and fset.
>
> On the Mac with ACL and SBCL, the new ASDF works equally well/equally
> poorly (compared with the packaged ASDF) with GBBOpen from subversion:
> loading the system inappropriately dumps my SLIME repl into the SWANK
> package, and requires a call to
>
> (cl-user::gbbopen-user)
>
> to get into what seems like a sane state.  But it seems to build fine.
> What's happening for you?
>
> r
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.diff
Type: application/octet-stream
Size: 3638 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20121228/9f59e097/attachment.obj>