On 4/14/10 Apr 14 -8:52 PM, Robert Goldman wrote:
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.
Actually, this seems more difficult than I had hoped.
Here's the problem as I see it:
1. asdf-binary-locations compatbility does not set any state variable to indicate that ASDF is in compatbility mode.
2. The most straightforward way to restore a-b-l compatibility wrt this case would be, in the :around method for output-files, to check to see if we are in compatibliity mode, and then only rewrite output-files when the operation is compile-op.
3. Unfortunately, there is no way for output-files to detect that ASDF is in compatibility mode.
I am reluctant to add a global variable into your lovely code, but I don't see an alternative.
Yes, I see that I can punch a hole in the rewriting so that lisp files are not rewritten, but that doesn't solve the compatibility issue. Whether or not files are rewritten by A-B-L is a matter of both the operation and the component types. Neither of these is checked in the new code, which is only a function of pathnames. There is no set of filename patterns that I can assemble that can reliably reflect the criteria that Gary used in his code, because those criteria are not based on pathnames exclusively, but on ASDF operations and components, as well.
I'm going to push a branch with a proposed fix, but will not push the fix onto the master branch, hoping that someone can come up with something that does not involve a global variable.
OTOH, the sets of output-translation rules are effectively a global variable, too, so I should probably just get over this.
best, r
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 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
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel