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

[Robert Goldman]

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