On 16 Nov 2014, at 11:19, Mark Evenson evenson@panix.com wrote:
Commit [14736][] on ABCL trunk enables ASDF-JAR:PACKAGE to complete.
I have not testing loading the falls from the jar yet, but will hopefully get to it later today.
After further testing, I can confirm that ASDF-JAR:PACKAGE and ASDF-JAR:ADD-TO-ASDF now “mostly” work on trunk.
“mostly” with the following two caveats:
1) ASDF systems which do not declare all their source code necessary to run within the ASDF grammar don’t package according to this method. An example of a system which exhibits this sort of failure is BORDEAUX-THREADS. For these sort of systems it is necessary to make the assumption that the “asd” file is in the top-most directory of the system source and to recursively copy. See [abcl-servlet][1] for an example of this strategy which shells out to rsync.
[1]: https://bitbucket.org/easye/abcl-servlet/src/b0e7e5353d6c92a1990ed1bb5500be1...
2) Using the jar for the pre-compiled fasls does not work with the current incarnation of ASDF. Instead, upon first use of the source packaged in the jar, ASDF will compile the fasls according to its output translations logic. This has to do with the special translations rules for ABCL for converting jar source locations, which are always included in the output translation logic, even if ASDF:DISABLE-OUTPUT-TRANSLATIONS is specifically called. As a hack—y workaround, executing the following form will completely disable ASDF’s caching mechanism which, when coupled with a non-nil value of *LOAD-VERBOSE*, will show that the FASLs are indeed being loaded from the jar:
(setf asdf::*output-translations* '(((T T))))
Do you have an absolute need to load the pre-compiled FASLs from the jar, or can you take the hit of compilation on first use coupled with the requirement that the user have a writable home directory for your deployment scenario?