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

[james anderson]

good evening;

On 2010-04-15, at 03:04 , Robert Goldman wrote:

> One of my own systems got blown up by ASDF-OUTPUT-TRANSLATIONS  
> recently,
> and the case may be an interesting one:
>
> [ ... ]
> 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/....

when my former construction crew partner used to characterize the  
"sawzall"[1] as a "tool of the devil", he was right. it was rightly  
respected as an infernal device - exactly for its single-minded  
simplicity. and rightly in demand. a-o-t finds itself on the same  
page, not just for its dsl qualities, but just as well for the  
potential the undo the unsuspecting. in its case, however, more  
likely for the surprising consequences of unappreciated interacting  
factors.

if only there were a simpler alternative...

it has been suggested, that logical pathnames are an alternative. to  
the response, that logical pathnames themselves are not compatible  
with asdf realpolitik - real-world system component names simply do  
not conform to logical pathname restrictions.
on the other hand, given that a-o-l devolves to translate-pathname,  
how far off can logical pathnames be from supporting the real asdf  
use cases?

as an experiment on this topic it seemed worth while to see if it  
would be possible to arrange asdf to separate the component naming  
from the component location mapping. it turns out to be quite  
straight-forward. enclosed is a diff to asdf 1.502 which exhibits the  
following:

- system definition proceeds in two phases. the first phase is the  
standard call to parse-component. this is followed immediately by an  
additional operation, bind-component-pathname, which walks the system  
top-down and computes an absolute pathname for each component from a  
combination of the parent absolute pathname, the component name, the  
component relative pathname, and the component type.
- if the absolute pathname is a logical pathname, it is arranged that  
all components be valid and, where necessary, a map is constructed  
for components which must be "canonicalized" to retain the respective  
original term.
- component-pathname, input-files, and output-files are modified to  
refer to the component's absolute pathname only. the first two  
resolve the absolute to a physical pathname and then map back  
components as appropriate. output-files first performs the input- 
 >output translation.

the modified version passes all but four of the pathname tests. the  
fours test which expect the component named "module2/typed-file.type"  
to designate the file "typed-file.lisp" fail, as the absolute  
pathname construction uses the expressed type rather than overriding  
it with the component file type. which, upon reflection, really seems  
correct in any case.

as is evident in the diff, the mechanism to manage the pathname  
component mapping requires about two dozen lines of code - the extra  
slot per component to hold the mapping, the component-translate- 
pathname operator, and the logical operator in bind-component- 
pathname. although the top-down apriori construction makes it easier  
to understand, that code is independent of the mapping.


---
[1] : http://en.wikipedia.org/wiki/Sawzall

---

-------------- next part --------------
A non-text attachment was scrubbed...
Name: asdf.diff
Type: application/octet-stream
Size: 14637 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100415/a412635c/attachment.obj>