[asdf-devel] Hoist by my own petard: problem with asdf-binary-locations compatibility.

[Robert Goldman]

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 at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel