[asdf-devel] ASDF:OOS LOAD-OP :FORCE T and SBCL contribs

Robert Goldman rpgoldman at sift.info
Mon May 11 13:11:16 UTC 2009

Nikodemus Siivola wrote:
> LOAD-OP :FORCE T propagates to depended-on systems -- meaning they
> will be recompiled as well.
> This is nasty when depending on an SBCL contributed module or anything
> else likely to be installed in directory with no write-permissions for
> the user.
> The easiest way to deal with this would be to add
>   ;; Prevent :FORCE T from trying to recompile contribs.
>   (defclass sb-contrib-system (system) ())
>   (defmethod traverse :before ((o compile-op) (c sb-contrib-system))
>     (when (operation-forced o)
>       (warn "Ignoring :FORCE T for COMPILE-OP of SBCL contributed
> module ~:@(~A~)."
>             (component-name c))
>       (setf (operation-forced o) nil)))
> under #+sbcl in asdf.lisp, and make SBCL defsystems use :class
> asdf::sb-contrib-system.
> However, presumably there are other cases where systems may be
> installed without write-permissions, so recompilation is not going to
> work.
> Perhaps a better solution would be to export OPERATION-FORCED and
> TRAVERSE, so that this could be deal with where-ever is needed --
> especially in local initialization files for systems installed in
> read-only locations. The SBCL solution would look about the same -- it
> just would not reside inside asdf.lisp.

This seems like a reasonable solution.

Question:  wouldn't it be cleaner (and easier) to provide a
:recursive-force-p argument or something like that to allow the user to
control this better?  It seems like we're having to do a workaround
because the control levers are too crude.

This could either be combined with your solution or replace it.


More information about the asdf-devel mailing list