[asdf-devel] create temporary Lisp files in fasl directory

Robert Goldman rpgoldman at sift.info
Thu Aug 5 23:45:09 UTC 2010

On 8/5/10 Aug 5 -5:58 PM, Robert Brown wrote:
> I'm using ASDF to build an open source implementation of Google's protocol
> buffer data serialization library.  The code is here:
>   http://github.com/brown/protobuf
> I've defined a new component type that allows developers to include protobuf
> message definition files in their Lisp ASDF files:
>   (defclass protobuf-source-file (cl-source-file)
>     ((relative-proto-pathname ... )
>      (search-path ... )
>     (:documentation "A protocol buffer definition file."))
> When used like this in a system definition:
>   :components ((:protobuf-source-file "foo"))
> executing the ASDF:LOAD-OP operation causes the file called foo.proto to be
> translated into foo.lisp by a C++ program, and then compiled into foo.fasl
> and loaded.
> Note that foo.lisp is created in the same directory as the system
> definition, but I would prefer it to be created in the same directory as
> foo.fasl, which for me is in a subdirectory of ~/.cache/common-lisp.
> What's the easiest way to accomplish this?
> I initially tried overriding INPUT-FILES when applied to CL-SOURCE-FILE
> instances, but ASDF::PERFORM is defined like this:
>   (defmethod perform ((operation compile-op) (c cl-source-file))
>     (let ((source-file (component-pathname c)) ... ) ... )
> Since it calls COMPONENT-PATHNAME to find Lisp source, it will always look
> in the system definition directory.

Hm.  Interesting.  It looks like this reveals an uncertainty about the
semantics of COMPONENT (and specifically COMPONENT-PATHNAME) versus

LOAD-OP works on INPUT-FILES but COMPILE-OP does not, which seems like
an unhappy departure from orthogonality....

This seems like another case where we understand the object model of
ASDF (and the corresponding protocols) less well than might be
desirable.  Alas, I find no documentation for the intended meaning of
INPUT-FILES (which probably accounts for certain difficulties in
extending ASDF to new component classes and operations ;->).


More information about the asdf-devel mailing list