[armedbear-devel] Using ASDF/BUNDLE for ABCL
ehuels at gmail.com
Mon Apr 1 10:49:18 UTC 2013
On Mon, Apr 1, 2013 at 12:04 AM, Faré <fahree at 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel