Not all dumping methods work with all implementations either. The
following table summarizes the situation. And of course, don’t mix
methods! For example, do not attempt to dump the ASDF way if your code
includes a call to dump.
| SBCL | CMUCL | CCL | CLISP | ECL | ABCL | Lispworks | ACL | |
Clon | ✓ | ✓ | ✓ | (1) | (2) | (3) | (4) | (5) |
ASDF | ✓ | ✓ | ✓ | (1) | (2) | (4) |
Dumping with both Clon and ASDF should work with CLISP in theory, but
the current trunk (2.49) seems to have a problem with its command-line in
dumped images. Its is possible to work around it by putting all
command-line options after a -- separator, as for regular sessions
(see Delivering Scripts). This issue has been reported at
https://sourceforge.net/p/clisp/bugs/745/.
Please note also that standalone CLISP executables continue to recognize
lisp-specific command-line options, when they are prefixed with
--clisp-. Hence, you should obviously avoid defining options by
those names.
Dumping an ECL image with Clon is not supported because of the way
ECL works. In short, ECL requires every single Lisp file to be compiled
to a system object file first, so you would need to know all the Lisp
files involved, and I mean, all: all systems, all dependencies,
etc. ASDF, on the other hand, has this information, so the ASDF
method is much preferred.
Another difference between ECL and the other Lisp compilers is that it
doesn’t require a particular function as the entry point for your
executable, but instead relies on having code to execute directly at the
toplevel of some file. Clon helps a little bit with this by making
the dump macro expand to a call to the specified function. That
way, you can still have a more or less portable file including a call to
dump, should you choose to call ECL’s c:build-program all
by yourself.
Finally, note also that Clon has some peculiar bootstrapping
requirements with its setup sub-system. These requirements seem to cause
problems with ASDF’s way of dumping executables in ECL, so in order for
it to work properly, your own system depending on Clon needs to
include an explicit dependency on ‘net.didierverna.clon.setup’ first,
as shown in the example above, as well as in the demonstration programs
included in the distribution.
ABCL is a totally different beast because it’s a Java implementation, so
there’s no real notion of standalone executable. In order to be able to
use a clonified program portably with ABCL, the dump macro does
as in ECL: it simply expands to a call to the specified function.
There’s more to it than that though. It is possible to get closer to
standalone executables with ABCL by providing your whole application in
a jar file, and overriding ABCL’s entry point with a custom
interpreter running the main function automatically. I have described
this process in more details in the following blog entry:
http://www.didierverna.com/sciblog/index.php?post/2011/01/22/Towards-ABCL-Standalone-Executables.
Clon helps you to do this to some extend. If the :dump
configuration option is set (see Configuration), then the
dump macro doesn’t do as described above, but instead dumps a
Java file containing an alternate ABCL interpreter that you can compile
and add to the original ABCL jar file, along with the Lisp file
containing the main function. If you want more details on this, you will
need to look at the Makefile in the demo/ directory and
also at the file make/config.make. You can also use make
-n clon-dump LISP=ABCL to see it in (fake) action.
The file in question is created based on a template that is located
under etc/abcl/template.java in the distribution, so you can also
edit this file, copy it, or do whatever you want with it. Note that this
file is not installed anywhere. Every time dumping is requested,
Clon looks for it in its own directory tree, so it must stay there.
Also, if you ever want to modify its contents and keep it as a template
for dumping (for example, in order to use ‘ql:quickload’ instead of
‘asdf:load-system’, you should know that this file is read in as a
Lisp format string, and in must always contain three
format directives: the first one for the class name, the second
one for the program invocation name (argv[0]), and the thrid one
for the file containing the call to dump. Again, better take a
look at how it is done in the demonstration programs.
Everything should work normally in Lispworks, but please remember that dumping a complete application is only possible in the Professional or Enterprise editions.
Finally, dumping a complete application with Allegro is complicated, but
more importantly only possible in the Enterprise edition. Because of
that, Clon’s dumping facility is currently limited to the
dumplisp feature, which only dumps a Lisp image. When dumped with
ACL, the demonstration programs included in the distribution also get
their own shell wrappers for loading the concerned images.