On 4/14/10 Apr 14 -8:41 PM, Faré wrote: > 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.
Right. I understand that, and I can make ASDF2 do the right thing for this case. But this shows an imperfection in our backward compatibility. I will see if I can propose a fix for this. I was pretty shocked, actually, that a git version of ASDF2 was shipped in ubuntu... best, r > > [ 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
