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

[Robert Goldman]

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 <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
>>
>>