Errol Pelchat <firstname.lastname@example.org> wrote:
| From what I've gathered so far there doesn't seem to by a
| typical way to deploy a LISP app, but I suspect I have overlooked
| something. Is there a typical way of deploying a LISP program,
| installing it (if necessary), and running it?
There are several typical ways, depending on:
1. The kind of app (interactive, "batch", or service daemon);
2. How widely it's going to be deployed (how many platforms);
3. What *kind* of platform (server or client/standalone);
4. Whether startup time is critical or not.
Some ways to package it include [*not* a complete list!]:
1. Single standalone executable: load all your FASLs into a Lisp,
define a special-purpose top-level startup routine, and save
the heap image ("core") and startup executable out as a single
A.OUT, ELF, ".exe", ".dll", or whatever. You will have to build
one of these for each separate target architecture the app needs
to run on, and in some cases for each version of the OS.
2. Deliver a compressed source tarball [usually containing
an ASDF or MK:DEFSYSTEM system definition file] and let the
user unpack, compile, install, & run it. If you're somewhat
careful, this can be fairly portable across machine architecture,
operating system, and Common Lisp implementation.
Note: These two are not exclusive if the compilation process in #2
produces a standalone executable, as in #1. But #1 is really only
helpful for short-lived human-interactive apps. Any kind of "server"
(service daemon) application should *NOT* be run from scratch for
each service request, but rather should be run once per system boot,
as a persistent daemon which is "connected to" with some kind of
protocol [possibly with connection caching, depending on where the
requests are coming from]. In that mode, startup time is seldom
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607