Errol Pelchat  <pelchat.errol@gmail.com> 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
very important.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607