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

[Faré]

>> Note that when I (describe #p"jar:file:///foo/bar.jar!/baz/quux.lisp")
>> I get:
>>        #P"jar:file:/foo/bar.jar!/baz/quux.lisp" is an object of type
>> EXTENSIONS:JAR-PATHNAME:
>>   HOST         NIL
>>   DEVICE       (#P"/foo/bar.jar")
>>   DIRECTORY    (:ABSOLUTE "baz")
>>   NAME         "quux"
>>   TYPE         "lisp"
>>   VERSION      NIL
>>
>> I believe that a pathname instead of a namestring
>> makes that non-conformant. Sigh.
>
> You mean the list with pathname in the device field?  Yes, ABCL is
> non-conformant in this manner in order to support addressing entries in jar
> files.
>
>> Note that if requires you could keep a cache of the pathname
>> in addition (or underlying store?) to any namestring in the device.
>
> I don't think I understand this suggestion.
>
You could be conformant if the device component were ("/foo/bar.jar")
instead of (#P"/foo/bar.jar"). Internally, you could even store
the pre-parsed pathname in a slot rather than the namestring,
as long as the pathname-device accessor returns a namestring and
as equal does the right thing.

>> What output-file do you get and where is it from?
>
> 0: (ASDF:COMPILE-FILE-PATHNAME*
> #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/jss/packages.lisp"
> :OUTPUT-FILE
> #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/Users/evenson/work/abcl/dist/abcl-contrib.jar/jss/packages.abcl"
> :OUTPUT-FILE
> #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/Users/evenson/work/abcl/dist/abcl-contrib.jar/jss/packages.abcl")
>  0: COMPILE-FILE-PATHNAME* returned
> #P"jar:file:/Users/evenson/work/abcl/dist/abcl-contrib.jar!/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/Users/evenson/work/abcl/dist/abcl-contrib.jar/jss/packages.abcl"
>
At this point can you trace COMPILE-FILE-PATHNAME, too?
Since the output-file satisfies absolute-pathname-p,
the branch taken by COMPILE-FILE-PATHNAME* should be to just call
COMPILE-FILE-PATHNAME, at which point I expect it to *not*
merge the device of the source file.
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 "".

Sigh. I would have suggested fixing things by having
ABCL's pathname scheme not use NIL for HOST and DEVICE in such cases,
but who knows what other interesting (positive or negative) consequences
that might or might not have. It could be a big win or a big headache.

If you can't fix ABCL this way, if such "fix" actually breaks other stuff,
or if you don't dare try, I suppose I need to reimplement in ASDF
what CL implementations *should* have done, i.e. using MERGE-PATHNAMES*
instead of MERGE-PATHNAMES in handling the OUTPUT-FILE.

> My understanding is that ASDF uses the COMPILE-FILE-PATHNAME* to supply the
> TYPE of fasl, which is implementation dependent.  Otherwise I didn't have an
> explanation as to why we run COMPILE-FILE-PATHNAME* before COMPILE-FILE
> which is going to return the same results, as in my testing the value that
> :output-file has at this point is already the final value anyways.
>
The reason why we pass :output-file is that we want to preserve the
API of compile-file-pathname, to which it is valid to pass arguments such as
:output-file "/tmp/" or :output-file "foo" (without type) or
:output-file (make-pathname :name nil :type "a") (without name).

If feel like more headaches are on their way...

What is the PROPER output-file defaulting algorithm for CL,
and what SHOULD it be for ASDF?

Stelian -- I demand your opinion on that one, since you started it all.

>> Can you give examples of functions giving the "wrong" results?
>
> No.  As I stated, it is correct that COMPILE-FILE-PATHNAME* merges in the
> device from input-file when the output-file arg has NIL for device.  This is
> the expected behavior from the ANSI perspective, but what we are trying to
> get away from in ABCL's case.
>
> Thanks for thinking with me on this.
>

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you make people think they're thinking, they'll love you;
but if you really make them think, they'll hate you. — Don Marquis