A port of ASDF-INSTALL has been [committed to trunk][1].

[1]: http://trac.common-lisp.net/armedbear/changeset/12487

I have a lot of issues with the shape of this package. This is a commit to both get feedback and to leave a "stake in the ground" so I can move to the more pressing issue of the long form of DEFINE-METHOD-COMBINATION. I really don't expect ASDF-INSTALL to work well under Windows, but you at least need [cgywin installed][2] for the 'tar' and 'gpg' binaries to have a fighting chance.

[2]: http://www.cygwin.com/

To use this package, one must invoke Ant with the target "abcl.contrib" whereupon a jar named "dist/abcl-contrib.jar" is created. Use the following in your ~/.abclrc (replacing ${dist.dir} with the absolute path of 'abcl-contrib.jar'):

(require 'asdf) (pushnew "jar:file:${dist.dir}/abcl-contrib.jar!/asdf-install/" asdf:*central-registry*)

Then issuing

CL-USER> (require 'asdf-install)

will load ASDF-INSTALL.

After you have loaded ASDF-INSTALL, you use it by issuing commands of the form:

CL-USER> (asdf-install:install :PACKAGE)

where PACKAGE is [an asdf installable system identifier][3]. This will attempt to install that system and all of its dependencies under ~/.asdf-install-dir.

[3]: http://www.cliki.net/ASDF-Install

To use the system, you need to inform ADSF of the location to load systems by having

(pushnew '(merge-pathnames ".asdf-install-dir/systems/" (user-homedir-pathname)) asdf:*central-registry*)

in your '~/.abclrc'.

What are my "issues"?

1. A large part of the value proposition of ASDF-INSTALL is that it is supposed to be help people newish to Lisp manage the installation of a lot of libraries to "get something running fast" but we don't have it as a standard part of ABCL. Why? Because ABCL should simply mean "you need Java x.x to run Common Lisp" leaving the platform distinctions behind. But since under Microsoft Windows ASDF-INSTALL relies on a) cygwin and b) symbolic links, it requires even *more* steps to get working for the hypothetical newcomer (who is likely coming from Windows in the first place). So we currently have no choice (or so I have argued myself into the position of) other than making ASDF-INSTALL an optional part of ABCL, if we wish to preserve the worthwhile semantics of platform independence.

2. The determination of the location of 'tar' and 'gpg' binaries should be better handled.

3. A lot of ASDF packages don't work well with ABCL, at least without patches. It would be nice to have something sort of like [Lispy][4] that could "intervene" for patching and recommendations for versions to install. In fact, a much more distributed manner of naming ADSF installable systems would be welcome.

[4]: http://common-lisp.net/project/lispy/

4. The #+windows conditionals make the asdf-contrib.jar non-platform independent. They should be replaced with (find :windows *features*) type forms.

5. The location of the 'abcl-contrib.jar' should at least be inferred from the location of 'abcl.jar' if they are in the same directory, but there isn't currently a reasonable proposal for how this would work to specify the ASDF location.

6. SBCL's version of asdf-install, although listed as "0.2" compared to the "0.6.10" that I ported seems to have more sophisticated conditionals for Microsoft Windows conditionals that should be examined for inclusion.

Patches and comments welcome.