Stellian's [normalization to ANSI semantics of COMPILE-FILE-PATHNAME*][1] has the unfortunate effect of breaking ABCL's translation of systems packaged in jar files.
[1]: http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=commit;h=ed4cd32932...
I have applied the subsequent patch to the asdf-2.016 packaged with ABCL to restore our needed functionality but am unhappy at the necessity of introducing a runtime implementation conditional, as sure a sign as anything that I'm "doing it wrong," and can't really request that ASDF patch itself in this manner. Maybe if I explain things as I have analyzed them, someone else can suggest a better way forward.
Recall that ABCL uses the presence of a cons in the DEVICE component to indicate that a Pathname represents an entry in a jar archive. A pathname located within a jar archive is not a writable location, so we introduced ABCL specific ASDF output translation rules which translate such a source location to an appropriately differentiated output location in the ASDF cache hierarchy. This results in ASDF making the following kind of call in preparation of the output file location it will pass to COMPILE-FILE:
(compile-file-pathname* <path with a DEVICE> :output-file <path without a DEVICE>)
Stellian's patch correctly fixes behavior of COMPILE-FILE-PATHNAME* to use pathname components in input-file if none are specified in output-file. For ABCL systems in a jar, this results in returning an output location within the jar file, which being a non-valid output location because it is not writable causes ASDF to error out in compiling the system.
If there were some mechanism to indicate that the invocation of APPLY-OUTPUT-TRANSLATIONS had really "finished" so that no further processing was necessary, we could possibly plausibly short-circuit this call to COMPILE-FILE-PATHAME*. I suppose my recursive invocation of APPLY-OUTPUT-TRANSLATIONS in the ABCL-specific TRANSLATE-JAR-PATHNAME adds the missing TYPE to the pathname which other code paths don't have at this point, which is why the call to COMPILE-FILE-PATHNAME* is necessary.
ANSI allows the addition of implementation specific arguments to COMPILE-FILE-PATHNAME, so we could maybe add a :strip-device for ABCL but this seems even less elegant.
Any suggestions?
@@ -3523,7 +3525,16 @@ --- a/asdf.lisp Thu Jun 09 06:03:20 2011 +0000 +++ b/asdf.lisp Thu Jun 09 15:00:45 2011 +0200 (defun* compile-file-pathname* (input-file &rest keys &key output-file &allow-other-keys) (if (absolute-pathname-p output-file) - (apply 'compile-file-pathname (lispize-pathname input-file) keys) + ;;; If the default ABCL rules for translating from a jar path to + ;;; a non-jar path have been affected, no further computation of + ;;; the output location is necessary. + (if (and (find :abcl *features*) + (pathname-device input-file) ; input-file is in a jar + (not (pathname-device output-file)) ; output-file is not in a jar + (equal (pathname-type input-file) "lisp") + (equal (pathname-type output-file) "abcl")) + output-file + (apply 'compile-file-pathname (lispize-pathname input-file) keys)) (apply-output-translations (apply 'compile-file-pathname (truenamize (lispize-pathname input-file))