[asdf-devel] ASDF 2.016 breaks ABCL translations for jar files

[Mark Evenson]

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=ed4cd32932e937724b0b28d1c20ed6abe5d58dc0;js=1

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

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."