[armedbear-devel] r12666 breaks ASDF compilation on Linux

[Alessio Stalla]

2010/6/2 Alessio Stalla <alessiostalla at gmail.com>:
> 2010/6/2 Mark Evenson <evenson at panix.com>:
>> On 6/1/10 9:50 PM, Knut Olav Bøhmer wrote:
>>>
>>> Is there any workaround for this?
>>>
>>
>> You got a patch for my wrist?  ;}
>>
>> But seriously, I think disabling the JAR output translation by removing the
>> reference(s) in ASDF:*OUTPUT-TRASLATIONS* with something like
>>
>> (setf asdf:*output-translations (list (remove
>> #P"/___jar___file___root___/**/*.*" (first *output-translations*) :key #'car
>> :test #'equal))
>>
>> would work.
>>
>> Alessio:  snow-0.3 fails to compile with 'sys:variable-information' not
>> being found in 'snow.lisp', so I can't reproduce your error.  Maybe you need
>> a new release from Snow trunk?
>
> You're right: Snow 0.3 was still supposed to build with a patched
> abcl, while trunk is not. However, I found out that the asdf problem
> is only in the binary release of ABCL downloaded from the site, while
> if I compile 0.20 myself it works, so r12666 is not the culprit. Since
> you cited a Windows pathname, and I think Erik built those binaries on
> Windows, is it possible that ASDF builds differently depending on the
> OS, so that the resulting binary only works on that OS?

Answering to myself, it appears indeed that the 0.20 binary contains a
reference to Windows pathnames:

CL-USER(1): *features*
(:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :LINUX :CDR6)

CL-USER(2): (require :asdf)
("CLOS" "PRINT-OBJECT" "FORMAT" "ASDF")

CL-USER(3): (asdf::wrapping-output-translations)
(:OUTPUT-TRANSLATIONS :INHERIT-CONFIGURATION
(#P"\\___jar___file___root___\\**\\*.*" (:USER-CACHE #P"**\\*.*"))
(#P"jar:file:\\**\\*.jar!/**/*.*" (:FUNCTION
ASDF::TRANSLATE-JAR-PATHNAME)) :ENABLE-USER-CACHE)

This is presumably because pathnames are serialized to FASLs using
their namestring, which is not necessarily the same string that was
passed in with #P"...". Storing the user-provided string in the
pathname and using that as a namestring if the pathname has not been
destructively modified could solve this issue, if it's doable. Sigh,
I'll have to reboot to Windows... ;)

Cheers,
Alessio