To prevent Lisp files from being redirected, you can add a rule such as ((:root #p"**/*.lisp") t) in your translations.
OR, you can make sure your output-file methods return T as a second value to prevent relocation.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] To seek God is to find him. To seek happiness is to miss it.
On 14 April 2010 21:04, Robert Goldman rpgoldman@sift.info wrote:
One of my own systems got blown up by ASDF-OUTPUT-TRANSLATIONS recently, and the case may be an interesting one:
I am working on a system that involves taking an ontology from the Protege tool, and interpreting it as CL.
So we have a special component type which is "pont" (from Protege ontology).
A pont file is /almost/ readable CL, but not quite. So before we can do the compile-op on the pont file, we first do a pont-to-lisp operation on it, which involves calling a perl script to generate a lisp file from the pont file.
So.....
We have a pont-file which ISA cl-source-file.
But there is no .lisp file to begin with. Instead, we have the following chain of operations:
pont-file ==== pont-to-lisp ====> lisp file ==== compile-op ====> fasl
This works fine in ASDF Classic, even with asdf-binary-locations, because asdf-binary-locations ONLY rewrites the output-files of COMPILE-OP.
So, the output of the pont-to-lisp file, the lisp file, gets written into the source directory where the compile-op can find it.
Unfortunately, this is not what happens with ASDF-OUTPUT-LOCATIONS, because A-O-L translates /all/ output-files, not just those of compile-op. This means that our lisp file gets dropped somewhere into /var/cache/common-lisp-controller/501/....
[Is this a misconfiguration of A-O-L, btw? My colleague is compiling this code as an ordinary user. I guess I'm surprised that the default is to drop stuff into /var instead of into a userdir. Seems like this is going to create a lot of dark matter in the filesystem, since one will have to look pretty hard to clean up zombie fasls... I would have thought something in the user's homedir would be more likely as a default...]
I'm afraid this suggests that we should tweak the asdf-binary-locations compatibility code yet again.
I will see if I can suggest a patch.
BTW, I discovered this because some ubuntu version seems to be shipping with common-lisp-controller with an ASDF 2 from git's womb untimely ripp'd... So Ubuntu people are unwittingly getting their SBCL served to them with ASDF2 rolled into it. Slightly alarming.
Best, r