On Sun, May 8, 2016 at 11:28 AM, Faré <fah...@gmail.com> 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 this, https://github.com/fukamachi/qlot (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 ~/.m2. -- Ian Tegebo
