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

Faré fare at tunes.org
Thu Apr 15 01:41:57 UTC 2010


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




More information about the asdf-devel mailing list