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 <[email protected]> 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 > > _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
