[armedbear-devel] [asdf-devel] Patches for ABCL against asdf-1.641
Mark Evenson
evenson at panix.com
Thu Mar 25 05:59:55 UTC 2010
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/armedbear-devel/attachments/20100325/3ad038e1/attachment.ksh>
More information about the armedbear-devel
mailing list