[armedbear-devel] ASDF-JAR vs ASDF3 deployment support

[Erik Huelsmann]

Hi all,


Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and
their dependencies in JARs.

As it turns out, the solution chosen has some problems with correctly
packaging ASDs for systems which use the #. reader macro. As an example:
bordeaux-threads uses a version.lisp-sexp file to canonically define the
version number and the system definition reads that file in a #. form.
However, this file isn't packaged because it's not part of the file listing
in the system definition. This means asdf can't load the definition after
deployment.

With the advent of ASDF3, its developers have created infrastructure to
combine fasls of a single system and even fasls of a  system and all its
dependencies into a single large combined FASL. Among others, this new
infrastructure does not run into the issue ASDF-JAR is running into. While
not completely equivalent to the JAR solution, using this infrastructure
would help us a huge step along that way of getting better deployment. My
current thinking is that if the single-packed-FASL needs to end up as a
jar, we can work on that as a next step.

The first step to take would be to create "concatenate fasls"
functionality, which would do the following:

 * Detect all the file entries in all the passed-in fasls
 * Create a new output zip file with directories for each fasl being
packed, populated with the files and directories of that fasl
 * create a toplevel ._ file which loads the sub-fasls' ._ files


Comments?

Bye,


Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130401/bfe6fc69/attachment.html>