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