[asdf-devel] [armedbear-devel] Patches for ABCL against asdf-1.641

[Mark Evenson]

On 3/24/10 7:08 PM, Faré wrote:
[…]

> Can ASDF1 do this loading from jar files? I certainly didn't remove
> anything from it. If you have a local patch to ASDF1 to do it, I'll be
> please to include it in either ASDF2 or a contrib to it.

Yes, ABCL ADSF1 can load from jar files and no, nothing has been removed 
from ASDF2 as it's more of a case of what has been added, namely that it 
now OPENs the .asd file instead of LOADing it, and ASDF-BINARY-LOCATIONS 
are baked-in.

That a Pathname for jar locations in ABCL are not currently capable of 
being OPENed turns out to be easily implemented (see attached patch).

That a jar Pathname is not a writable location turns out to cause 
problems for the binary locations part of ASDF2.   It was sufficient to 
[patch the behavior][1] of ASDF1 to have OPERATION-DONE-P return T if 
all the members of the output files of COMPILE-OP on a CL-SOURCE-FILE 
were determined to be within a jar.  But this turns out only to have 
worked with ABCL because there was a bug in how *LOAD-TRUENAME* was 
computed in loading from a jar Pathname that I would like to fix going 
forward (it's fixed in the patch).

[1]: 
http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/asdf-abcl.lisp 


It would be perhaps cleaner to have the binary locations machinery of 
ASDF2 react to not being able to write to the Pathname derived from the 
location of the ".asd" file in an extensible manner.  This might be 
useful for users of Lisps other than ABCL who don't have permission to 
write to the system ASDF location for instance.  My current problem is 
that the :BEFORE for PERFORM specialized on COMPILE-OP SOURCE-FILE 
contains an ENSURE-DIRECTORIES-EXIST which by default is derived from 
the ".asd" Pathname.  Is there a way to per-system customization of the 
output location?

Thinking quickly for an ASDF2 algorithm:

1.  Is the directory containing the ".asd" writable?  If so, continue 
normally.

2.  Otherwise, can we establish an alternative location to write the 
output of COMPILE-OP as configured by the user?  If so, continue normally.

3.  Otherwise, skip the COMPILE-OP of this system.  For LOAD-OP, search 
for FASLs by some user-extensible mechanism, falling back to looking in 
the same directory as the ".lisp" files.  If no FASLs can be found, load 
the source files.

> If there are any regressions from ASDF1 to ASDF2, I want them fixed.
> Otherwise, there shouldn't be a problem upgrading ABCL from ASDF1 to
> ASDF2.

No regressions have been noted;  I will report them if found.  As it 
stands, I can't upgrade ABCL to ASDF2 without breaking the existing 
functionality of loading ADSF definitions from jars.  The responsibility 
for fixing this situation certainly lies with ABCL's extension of 
Pathnames to cover jar files, which we are working to bring in line with 
new features offered by ASDF2.

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: abcl-asdf2-jar.patch
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100325/3ad038e1/attachment.ksh>