After being confused as to why (asdf:oos 'asdf:load-op :swank) wasn't
working, I decided to look at the source to figure it out. The
problem was that I was using ASDF-Binary-Locations to store my fasls
elsewhere on the disk, and once swank-loader.fasl was put in the
alternate location, it couldn't find any of the other swank .lisp files.
I created a new swank.asd that contains (I think) the full
functionality of swank-loader.lisp. This allows the fasls to be
relocated. I know, this means that changes have to happen in two
places. I think there's a solution to this, too. Rather than have
the .asd call swank-loader, reverse it. Write a new swank-loader that
just loads the .asd (untested):
(defvar *source-directory*
(make-pathname :name nil :type nil
:defaults (or *load-pathname* *default-pathname-
defaults*))
"The directory where to look for the source.")
(handler-case
(require :asdf)
(condition ()
(load (make-pathname "asdf" :defaults *source-directory*))
(pushnew *source-directory* asdf:*central-registry* :test
#'equal)))
(asdf:oos 'asdf:load-op :swank)
This tries to use an ASDF outside of the swank directory first, but
falls back to an included one if need be. Then it loads the system.
This means that for the time being, slim.e-el (and anyone setting the
slime-backend custom variable) doesn't have to change anything.
I know, it adds a dependency, but asdf is pretty ubiquitous anymore,
and the inclusion of a fallback version in the source should catch a
lot of the other cases.
Cons:
- requires ASDF
Pros:
- can eliminate a bunch of code used to manage file locations
- gain flexibility of ASDF and its extensions (like ASDF-Binary-
Locations)
It also seems like SWANK maybe should be made into its own ASDF-
Installable package, with SLIME having only the emacs code and SWINE
having the Climacs code.
Does anyone think any of this might be a good idea?