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

[Faré]

Dear Mark,

> 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.
>
OK.

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

> 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).
>
OK. But doesn't asdf-output-translations (the replacement for
asdf-binary-locations) by default redirect the output to a user cache?
Or did you disable that?

> [1]:
> http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/asdf-abcl.lisp
>
Do you want me to merge that into upstream ASDF with #+abcl conditions?

Note: If ABCL supports matching and translating such paths,
there could be ASDF-Output-Translation rules by default with ABCL
in the idea of
(#p"/**/*.jar/**/*.*" (:home #p"**/*.jar/**/*.*")

> 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?
>
How do you propose to do that?

> 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.
>
Juanjo of ECL was thinking of a different delivery mechanism, where
compiling a ASDF system would yield another ASDF system of the same
interchangeable name, but the content of which would be just one or
several binary objects to load.

Perhaps that's what you really want to be using?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The Philosophy of Liberty, or Libertarianism, is a theory of Law; it is an
ethics of Liberty and Responsibility; it is a cybernetics of Human Action;
it is the only authentically subversive ideology.