How to fix arnesi:clean-op.

Ian Tegebo ian.tegebo at
Sun May 8 19:10:17 UTC 2016

On Sun, May 8, 2016 at 11:28 AM, Faré <fahree at> wrote:

> clean-op is an impossible operation to fix, because its meaning isn't
> defined in general, and CANNOT be defined in general. And while some
> specific subsets and variants of it CAN be defined, they remain so
> specific as to not be of general purpose and/or there are enough
> subtly different variants of it to require a breakdown of the vague
> idea into clearly separated concepts.
> For instance, in the context of using git, you might "just" do a:
> git clean -xfd
> and call it quits. Yet, unless you specifically configured your
> output-translations to point to under the current git repository,
> it won't clean your fasl-translated cache, which would be in e.g.
> ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/
> Then comes the question: should clean-op clean only for the
> current implementation, or should it also remove objects for
> sbcl, ecl, allegro, etc.? A git clean might erase files that
> you'd like to preserve, that you failed to git add. A
>         rm -rf
> ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/
> would fail to remove fasls from dependencies or on other
> implementations. You could try
>         rm -rf ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/
> or even
>         rm -rf ~/.cache/common-lisp/
> but then that might remove too many things, including things you might
> like to keep at that time. And if you have a non-standard
> configuration for output-translations, this might still miss some
> files you might want to remove.

These certainly are dicey issues given the default mapping of output files.

Something I've been looking into is moving towards "project-based" CL
development.  Most other languages now have some variant of this, where
dependencies and build artifacts are typically contained within some
sub-directory.  At this point in time, it's surprising that ASDF/Quicklisp
doesn't do things this way.  I've only found one project attempting to do
(after a quick read, I don't think it's mapping output-files underneath the
project directory like one might expect)

If you only expect to load files from within that project/directory, and
run separate lisp images for different projects/directories, then cleaning
is more intuitive for those coming from mainstream environments, i.e. you
just delete the build/ sub-directory.  I'd be interested to hear about
similar approaches and complications, e.g. you'd want a user-global
quicklisp cache to avoid re-fetching remote deps as in Maven with its

Ian Tegebo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the asdf-devel mailing list