On 3/29/10 8:25 AM, Faré wrote:
Dear Mark,
Fare's suggestion that I use an output translation based on the jar pathname doesn't quite work, because in our current implementation, the pathname of the jar is stored in DEVICE, separate from the rest of the jar pathname. I extended PATHNAME-MATCH-P to match jars correctly, but I don't see a possible extension of TRANSLATE-PATHNAME.
Couldn't you extend the ABCL pathname matching algorithm to allow for wildcards and all in the device component?
Wildcards do work in DEVICE but you can't currently use unused results of the wildcard matches on the DEVICE components to "carry over" to the translation of the DIRECTORY component. I suppose that's what you were suggesting anyways. There isn't an obviously easy way to implement this in ABCL due to the structure of our code and I need to think through the various permutations, but that doesn't mean that its implementation isn't a win for the end user. I'll see what I can do.
So I would ask the ASDF developers to consider extending the output translation DSL to allow something like
(initialize-output-translations '(:output-translations :ignore-inherited-configuration (#p"jar:file:/**/*.jar!/**/*.*" :function SYS::ASDF-JAR-OUTPUT-TRANSLATE)))
I suggest that either you make (:function foo) a valid second value for an output-translations list, or you make said list accept a&key function argument in addition to its two current positional arguments. But having weird non-standard vararg convention for such lists is probably a bad API. The default function would be TRANSLATE-PATHNAME and the calling convention would be the same.
I'd favor the first proposal, as making :FUNCTION a real key argument would imply that the second positional parameter is optional, whereas it is actually being replaced by the (:FUNCTION ARG) parameter. When I get time to revisit the patch, I'll implement your first proposal.
[…]
Thanks, Mark