On Sun, May 8, 2016 at 11:28 AM, Faré fahree@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.