What's the right way to extend ASDF with new symbols?

Robert Goldman rpgoldman at sift.net
Wed Nov 18 13:59:25 UTC 2015


Commonly, one wants to extend ASDF with new operation and component classes.

But the support in ASDF for referencing such classes all involves
automagically interpreting keyword symbols (and some unqualified
symbols?) in the ASDF package.

If I understand this correctly, this leaves the ASDF extender with the
alternatives of either jamming their new symbols into the ASDF package
late, and exporting them, or having them live in a new package, which is
cleaner, but relegates these new components to second-class status.

Consider the following

(defpackage my-system-def
  (:use common-lisp asdf))

(in-package :my-system-def)

(defsystem my-system
  :defsystem-depends-on ("my-asdf-extension")
  :components ((:my-new-file "file1")))

I don't seem to be able to define MY-NEW-FILE in my-asdf-extension and
export it into my-system-def, because my-system-def is already defined
by the time my-asdf-extension is loaded.  That means I pretty much have
to either muck around in the ASDF package (which doesn't scale to
multiple different people extending ASDF) or use side effects:

(asdf:load-system "my-asdf-extension")

(defpackage my-system-def
  (:use common-lisp asdf my-asdf-extension))

(in-package :my-system-def)

(defsystem my-system
 :components ((:my-new-file "file1")))

Am I right about this?  If I am, is there some way to better handle
this?  Or do we need to rethink how :defsystem-depends-on works?



More information about the asdf-devel mailing list