On re-reading CLHS, I retract my admission that ABCL is non-conformant. From the CLHS glossary a "valid pathname device [is a] a string, nil, :unspecific, or some other object defined by the implementation to be a valid pathname device." ABCL is using the "some other object" ability here. The "might" description in CLHS 19.2.2.4.2 offers guidance as to the allowed types, but doesn't put a firm requirement. Or is this understanding incorrect somehow? Note I am trying to use "conformant" here in the manner prescribed by CLHS 1.5, not in the informal sense of "what a friendly CL implementation" should do.
The CLHS sometimes contains mutually contradictory statements, or statements that have subtle interactions or reinforcing meaning. I seem to remember from previous discussions with SBCL language lawyers that there were somewhere in the CLHS restrictions in addition to these, but at this point it's third hand remembrance of second hand knowledge. Sigh.
But have the device component be a cons violates the first sentence of CLHS 19.2.2.4.2 that you are presumably referencing. Or how do I misunderstand?
Indeed. This paragraph suggests the component can be a string but not a cons except for wild pathnames.
OH I GET IT! (I think.) The bug is that (1) COMPILE-FILE-PATHNAME uses MERGE-PATHNAMES instead of ASDF:MERGE-PATHNAMES* (as you would, I assume). (2) Your absolute pathnames have a host and device of NIL, instead of a non-nil host device of say "FILE" and "LOCALHOST" or say "" and "".
Yes, it is our use of NIL here that is causing problems.
Good. At least, we understand the issue if not the solution.
What I was going to suggest is that the TRANSLATE-JAR-PATHNAME function return a pathname with an :UNSPECIFIC device component. This should allow the COMPILE-FILE-PATHNAME merge algorithm to do what we want, but I see you have incorporated this into your next message, which I will reply to.
That could be a solution. Another solution would be for ASDF to somewhat distrust the implementation, and do its own thing, using merge-pathnames* where the implementation would likely use the error-prone merge-pathnames.
How does THIS work for you?
(defun* compile-file-pathname* (input-file &rest keys &key output-file &allow-other-keys) (flet ((cfp (i o) ; what compile-file-pathname should actually do (let ((fasl (pathname-type (apply 'compile-file-pathname "foo.lisp" keys)))) (merge-pathnames* ; NB: the caller must (merge-pathnames* i) if o not absolute. o (make-pathname :type fasl :defaults i))))) (if (absolute-pathname-p output-file) (cfp input-file output-file) ; if user specifies absolute output, use it (apply-output-translations (cfp (truenamize input-file) output-file)))))
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "If men are good, you don't need government; if men are evil or ambivalent, you don't dare have one." — Robert LeFevre