Hi Faré,


On Mon, Apr 1, 2013 at 12:04 AM, Faré <fahree@gmail.com> wrote:
I admit I had never looked at how ACBL-JAR works before. I see it's there:

IIUC, the gist is that you somehow traverse the system to gather what files to zip,
and the tricky issue is that since the output-translations function will be different
in the build environment and the deployment environment, you have to build a map
of build-time pathnames in the filesystem to deploy-time pathnames in the jar file.
Because ASDF 1 or 2 didn't have a good way to do that, ABCL currently does it
in a clunky way that doesn't account for ASDF extensions.
Doing it correctly is possible using exported functionality of ASDF3,
but requires intercepting (with-asdf-cache (:override t) ...) and
*output-translation-functions* to build a reverse translation table
around a call to (traverse 'load-op system).

As we discussed on IRC, I think it's best to hook into ASDF's facilities: This is simply the only way to leverage cross-implementation efforts. If ASD files need to be fixed or changed to support these kinds of hooks, I'm quite sure chances of that happening increase if people on all implementations are bound to run into them.
 
Your second email suggests you're looking into combining fasls as an alternative to building a jar. Sounds great. Regarding how to build a system that loads the concatenated fasl,
see in asdf/bundle.lisp the (largely untested, stolen from asdf-ecl.lisp)
   defmethod perform ((o binary-op) (s system))
Or search the same file for "Example use:"

Yes, I'm trying to come up with the best way to support deployment. Both the JAR solution as well as the "concatenated FASL" solution aim at that goal. If the concatenated FASL solution helps to get there, then that's what I'll aim at.

Bye,

Erik.