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/l...
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.