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?
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:
- Is the directory containing the ".asd" writable? If so, continue
normally.
- Otherwise, can we establish an alternative location to write the output
of COMPILE-OP as configured by the user? If so, continue normally.
- 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.