License: LLGPL
Source repository: http://common-lisp.net/project/xcvb/git/cl-launch.git
Download: http://common-lisp.net/project/xcvb/cl-launch/
cl-launch will help you invoke your Lisp software from the Unix command-line. It is a self-contained shell-script that will abstract away the details of the underlying Lisp implementation by generating the proper Lisp and shell code. Extensive automated testing ensures that it works in thousands of valid combined operation modes, Lisp and shell implementations.
Currently supported Lisp implementations:
Full support (including standalone programs): sbcl 1.0.22, clisp 2.48, clozurecl 1.2, ecl 0.9.6
Supporting everything but standalone programs: cmucl 19b, allegro 5.0, gcl 2.7.
Partial support: gcl 2.6 (no asdf), lispworks 5.1 pro (with limitations).
Here follows the output of /usr/bin/cl-launch.sh --more-help:
cl-launch.sh 2.15 -- shell wrapper generator for Common Lisp software
Usage:
cl-launch '(lisp (form) to evaluate)'
evaluate specified Lisp form, print the results followed by newline
cl-launch --execute [...] [-- arguments...]
run the specified software without generating a script (default)
cl-launch --output SCRIPT [--file LISP_FILE] [--init LISP_FORM] [...]
generate a runnable shell script FILE from a software specification
cl-launch --update FILE [...]
same as above, but reuse software specification from previous FILE
cl-launch [ --version | --help | --more-help ]
display information (might be long, you may pipe it into a pager)
Special modes:
-h or -? --help display a short help message
-H --more-help display a longer help message
-V --version display cl-launch version and configuration
-u FILE --update FILE update a cl-launch script to current version
Software specification:
-m IMAGE --image IMAGE Load Lisp image IMAGE
-f FILE --file FILE FILE to be embedded or loaded
-s SYSTEM --system SYSTEM asdf SYSTEM to be loaded
-r FUNC --restart restart FUNC to funcall before initializations
-i FORM --init FORM initialization FORM to evaluate after loading
-ip FORM --print FORM evaluate and princ FORM after loading
-iw FORM --write FORM evaluate and write FORM after loading
-p PATH --path PATH register asdf systems search PATH
-pc --path-current register current directory to asdf (default)
+p --no-path do not register any asdf system PATH
-l LISP... --lisp LISP... specify list of supported LISP implementations
-w CODE --wrap CODE specify shell CODE to run in the wrapper
-I PATH --include PATH specify runtime PATH to cl-launch installation
+I --no-include disable cl-launch installation feature
-R --rc try read /etc/cl-launchrc and ~/.cl-launchrc
+R --no-rc skip /etc/cl-launchrc and ~/.cl-launchrc
-b --clbuild use clbuild (see limitations in documentation)
+b --no-clbuild do not use clbuild
-v --verbose be very noisy while building software
-q --quiet be quiet while building software (default)
Output options:
-x -o ! --execute no file creation, run the thing NOW (default)
-o FILE --output FILE specify FILE name of output script
-d DUMP --dump DUMP dump an image of the world for faster startup
-X ... -- (see more help) use #!/path/to/cl-launch as script interpreter
-- -- end of cl-launch arguments when using -x or -X
INVOCATION OF CL-LAUNCH
CL-Launch will create a shell script that, when invoked, will evaluate
the specified Lisp software with an appropriate Common Lisp implementation.
A suggested short-hand name for cl-launch is cl (you may create a symlink
if it isn't included in your operating system's cl-launch package).
The software is specified as the execution, in this order, of:
* optionally having your Lisp start from a Lisp IMAGE (option --image)
* loading a small header of code that provides common cl-launch functionality
* optionally loading the contents of a FILE (option --file)
* optionally having ASDF load a SYSTEM (option --system)
* optionally having your Lisp DUMP an image to restart from (option --dump)
* optionally having your Lisp execute a RESTART function (option --restart)
* optionally evaluating a series of initialization FORMS (option --init)
General note on cl-launch invocation: options are processed from left to right;
in case of conflicting or redundant options, the latter override the former.
The cl-launch Lisp header manages compilation of Lisp code into a fasl cache
and provides uniform access to the invocation context. It defines a package
:cl-launch that exports the following symbols:
*arguments* getenv quit
load-system compile-and-load-file compile-file-pathname*
apply-pathname-translations *output-pathname-translations*
apply-output-pathname-translations
See below section 'CL-LAUNCH RUNTIME API'.
The cl-launch header will try to load ASDF. It will first try to (require ...)
it from your Lisp implementation, then will try a path provided through
environment variable $ASDF_PATH if available, then it will look in your
home directory under ~src/asdf/asdf.lisp and finally it will search for
the default common-lisp-controller installation of it in
/usr/share/common-lisp/source/asdf/asdf.lisp
or
/usr/share/common-lisp/source/cl-asdf/asdf.lisp
If asdf is not found, cl-launch will proceed but you won't be able to use it
and the --system option will be unavailable.
Only one input files may be specified with option --file. Now, if the specified
filename is '-' (without the quotes), then the standard input is used. You may
thus concatenate several files and feed them to cl-launch through a pipe. Or
you may write Lisp code that loads the files you need in order.
Only one system may be specified with option --system, because the right thing
to do if your software depends upon multiple systems is to write a system
definition that :depends-on several other systems. It may still be useful to
combine options --file and --system, since you may want to prepare your Lisp
system with proper settings and proclamations before you load your system.
You may specify that a snapshot image of the Lisp world be dumped at this point
with option --dump. Execution of the program will consist in restarting the Lisp
implementation from that dumped image. See section DUMPING IMAGES.
You may optionally specify a restart function with option --restart,
to be called every time the software is invoked. If you are dumping an image,
this function will be called right after execution resumes from the dumped
image. If you are not dumping an image, it will merely be executed after
loading the system from source or fasl. Only one restart function may be
specified with option --restart. If you want several functions to be called,
you may DEFUN one that calls them and use it as a restart, or you may use
init forms below.
Several instances of option --init FORMS may specify as many series of forms
that will be read and evaluated sequentially as top-level forms, as loaded
from a string stream after the rest of the software has been loaded.
Loading from a stream means you don't have to worry about packages and other
nasty read-time issues; however it also means that if you care a lot about
the very last drop of startup delay when invoking a dumped image,
you'll be using option --restart only and avoiding --init.
Option --print (or -ip) specifies FORMS where the result of the last form
is to be printed as if by PRINC, followed by a newline. Option --write
(or -iw) is similar to --print, using WRITE instead of PRINC.
When the various side effects from software invocation happen depend on how
cl-launch is invoked. For the purpose of side effects, software invocation
may be divided in two phases: software preparation and software execution.
Software preparation consists in compiling and loading the software as
specified by options --file and --system. During software preparation, object
files are cached and will be loaded without being recompiled if a previous
version exists that does not depend upon any modified sources. If no image is
dumped, then software preparation happens at each invocation of the generated
script. If an image is dumped then the preparation only happens at invocation
of cl-launch, and the generated script will use the prepared software directly;
with ECL, the load-time (but not compile-time) side-effects of software
preparation are evaluated every time a dumped image is invoked.
Software execution happens at every invocation, after the prepared software
has been suitably loaded. First the --restart function, if provided, is called.
Then, the --init forms, if provided, are evaluated.
When option --execute is specified, the specified software is executed.
Command-line arguments may be given to software being executed by putting
them after a special marker '--', that ends cl-launch option processing.
When option --output FILE is used, code will be generated into the specified
FILE. The output file itself will be created atomically from complete
generated contents and may thus have the same pathname as the input file.
The restart function and init forms will not be evaluated, but kept for
when the output file is executed.
If '-' (without quotes) is specified, then the standard output is used.
If '!' (without quotes) is specified, then option --execute is assumed.
When no --output file is specified, option --execute is implicitly assumed.
The last --output or --execute option takes precedence over the previous ones.
If only one argument exists and it doesn't start with '-' then the argument is
considered as if given to option -ip, to be evaluated and printed immediately.
Multiple paths may be supplied that will be added to asdf:*central-registry*
before any software is loaded, so that asdf may find the required systems.
Each instance of option --path will specify one such path. The paths will
be added in reverse order, so that the those specified earlier have priority
over those specified later. You may also withhold any modification to asdf's
central registry by specifying option --no-path. Or you may specify the current
directory (at the time cl-launch is run) with option --path-current. The
default if none of these options have been specified is --no-path.
At each specification, an argument containing only alphanumerics and characters
-+_,.:=%/ will be considered as a pathname; any other specification will be
considered as an arbitrary Lisp expression (that will not be evaluated).
You can also add things to asdf:*central-registry* in your system-wide
or user configuration files for the startup of your Lisp implementation,
but note that the default arguments used by cl-launch when invoking those
implementations will disable system and user configuration files.
See below how to change these arguments.
Options --lisp and --wrap may be used to control the way that a Common Lisp
implementation is found when the software is run. Option --lisp specifies the
list of Common Lisp implementations to try to use; the list is
whitespace-separated, and consists in nicknames recognized by cl-launch.
Option --wrap supplies arbitrary code to be evaluated by the shell wrapper,
after it has read its configuration and defined its internal functions, but
before it tries to find and run a Lisp implementation. Such wrapper code is
typically used to modify the variables that control the run-time behaviour
of generated scripts, as documented below. Use of other internals of cl-launch
is possible, but not supported, which means that it is your responsibility to
keep a copy of the specific version of cl-launch with which your code works and
to update your code if you later make an upgrade to an incompatible cl-launch.
For instance, --lisp "foo bar" is equivalent to --wrap 'LISPS="foo bar"'.
See below the documentation section on 'LISP IMPLEMENTATION INVOCATION'.
Option --no-include specifies that cl-launch should generate a standalone
script that includes the configuration, shell wrapper, Lisp header, and
user-provided Lisp code (from --file). If the software doesn't use asdf, or
if the asdf systems remain well located at runtime, then the script is pretty
much standalone indeed an may be moved around the filesystem and still used.
However the size of the output will be the size of the user Lisp code
plus about 43KiB.
Option --include PATH specifies that cl-launch should generate a very small
script (typically under 1KiB) that when run will read the cl-launch shell
wrapper and Lisp header from a specified installation directory PATH.
Also, if option --include is used, and Lisp code is specified with --file
and an absolute pathname starting with / as opposed to a relative pathname
or to the standard input, then Lisp code will also be loaded from the specified
location at runtime rather than embedded into the script at generation time.
This option generates leaner scripts, but may not be applicable when
the very same script is to used in a variety of situations
that lack common coherent filesystem management.
Which of --include or --no-include is the default may depend on your cl-launch
installation. The version of cl-launch distributed by the author uses
--no-include by default, but the version of cl-launch available in your
operating system distribution may rely on a well-managed include path (this is
the case with debian for instance). You may query the configuration of an
instance of cl-launch with option --version.
For instance, one may expect a debian version of cl-launch to use
/usr/share/common-lisp/source/cl-launch/
as a system-managed include path. One may also expect that Lisp implementations
managed by the system would come with cl-launch precompiled in Lisp images.
Since the cl-launch provides feature :cl-launch, and since the cl-launch Lisp
header is conditionalized to not be read with this feature, this would make
cl-launch startup faster, while still allowing non-system-managed Lisp
implementations to run fine.
You may create an installation of cl-launch with such a command as
cl-launch --include /usr/share/common-lisp/source/cl-launch \
--lisp 'sbcl ccl clisp' \
--rc \
--output /usr/bin/cl-launch -B install
You can use command -B install_bin if you only want to configure cl-launch
(with a different default for --lisp but no --include, for instance), and
command -B install_path if you only want to create support files.
Note that the --backdoor option -B must come last in your invocation.
Option --no-rc or +R specifies that cl-launch should not try to read resource
files /etc/cl-launchrc and ~/.cl-launchrc.
Option --rc or -R specifies that cl-launch should try to read resource
files /etc/cl-launchrc and ~/.cl-launchrc. These files are notably useful
to define override the value of $LISP depending on $SOFTWARE_SYSTEM.
A function system_preferred_lisps is provided so that your cl-launchrc might
contain lines as follows:
system_preferred_lisps stumpwm cmucl sbcl clisp
system_preferred_lisps exscribe clisp cmucl sbcl
Beware that for the sake of parsing option --no-rc, the resource files are run
*after* options are processed, and that any overriding of internal variables
will thus preempt user-specified options. A warning will be printed on the
standard error output when such an override happens.
Note that such overrides only happen at script-creation time. A script created
by cl-launch will not try to read the cl-launch resource files.
Files generated by cl-launch are made of several well-identifiable sections.
These sections may thus be considered as distinct software, each available
under its own regime of intellectual property (if any). In case of an accident,
you may still retrieve the exact original code provided with option --file
by stripping the wrapper, as delimited by well-identified markers.
Search for the marker string "BEGINS HERE:". Every after it is not cl-launch.
This can be done automatically with backdoor option -B extract_lisp_content.
cl-launch uses this functionality implicitly when embedding a file specified
with the option --file, so that you may process a script previously generated
by cl-launch and change the options with which it wraps the embedded Lisp code
into runnable software.
As an alternative, you may also upgrade a previously generated script to use
the current version of cl-launch while preserving its original wrapping options
with option --update. In this case, software specification options are ignored.
Output options still apply. Specifying '-' (without quotes) as the file to
update means to read the contents to be read from the standard input.
This feature might not work with scripts generated by very early versions
of the cl-launch utility. It should work with versions later than 1.47.
COMPILATION AND FASL CACHING
A cl-launch generated program will compile the contents of the file supplied
with --file the first time it is invoked. Note that this happens even when
the file contents were embedded in the script, since compiling or loading
the wrapped file is equivalent to compiling or loading the original file
supplied.
So as to avoid problems with badly interfering fasl files everywhere,
cl-launch sets up a fasl cache to hold fasl files in a proper place.
It will also modify asdf so that it too will put files in the same cache.
This caching mechanism will be disabled if common-lisp-controller is present,
since c-l-c version 6.0 and later already do a similar caching.
The fasl cache is a per-user, per-Lisp-implementation, per-source-pathname,
mapping of source files to compiled files fasl.
The fasl for a file $DIR/$FILE with be stored in directory
$HOME/.cache/lisp-fasl/$IMPL/$DIR/
Here, $IMPL is a unique string generated by cl-launch in a way similar
to what SLIME does, and stored in cl-launch::*implementation-name*.
You may specify an alternate cache directory instead of the default
$HOME/.cache/lisp-fasl/ by setting and exporting the environment variable
$LISP_FASL_CACHE
You may also disable the cache altogether, by using the value NIL (uppercase).
This path is stored in variable cl-launch::*lisp-fasl-cache*.
Because the cache reserves a separate directory for every Lisp implementation,
it prevents common problems due to a same pathname being used by several
different and incompatible implementations or versions of a same implementation
to store their fasl files, resulting in conflict. This makes it easy to
share source code hierarchy among users, machines, implementations.
As a variant, if you know for sure which implementation you're using and
have set the variable $LISP, you can override the whole path with variable
$LISP_FASL_ROOT
so that fasls for code under $DIR with be stored under $LISP_FASL_ROOT/$DIR.
This feature plays well with common-lisp-controller: the clc cache will take
precedence when detected (tested with common-lisp-controller 4.12 to 6.6).
Hopefully, upstream versions of cl-launch and common-lisp-controller
will synchronize to prevent or quickly fix any possible breakage.
Due to outstanding bugs as of clc 6.17, 0.9j-20080306-4, and gclcvs 2.7.0-84.1,
the clc cache is disabled for ECL and GCL.
Note that you may use symlinks to move ~/.cache/lisp-fasl/ to the place of your
choice, and to equate NFS paths that vary across machines for a same directory.
To distinguish paths between machines that share a common home directory but
with varying directory contents mounted on given identical pathnames, you can
use distinct values of $LISP_FASL_CACHE depending on the machine, and merge
back whatever can be merged with symlinks.
SUPPORTED LISP IMPLEMENTATIONS
The implementations supported by current version of cl-launch are
sbcl cmucl clisp ccl allegro lispworks ecl gcl
Also defined are
gclcvs openmcl lisp
which are name variations for gcl, ccl and cmucl respectively.
Fully supported, including standalone executables:
sbcl: SBCL 1.0 (1.0.21.24 needed for standalone executable)
clisp: GNU CLISP 2.44 (no standalone exec before 2.48, broken before 2.36)
ecl: ECL 0.9l (Beware! cache needs be cleared before to dump asd images)
Fully supported, but no standalone executables:
cmucl: CMUCL 19b (recently only tested with 19d)
ccl: ClozureCL 1.2 (support for OpenMCL 1.1 and earlier discontinued)
gclcvs (GCL 2.7): GCL 2.7.0 ansi mode (get a recent release)
Incomplete support:
gcl (GCL 2.6): GCL 2.6.7 ansi mode (no ASDF so --system not supported)
allegro: Allegro 5 (not tested on recent versions)
lispworks: LispWorks Professional 5.1.0 (annoying banner, no personal ed)
GCL is only supported in ANSI mode. cl-launch does export GCL_ANSI=t in the
hope that the gcl wrapper script does the right thing as it does in Debian.
Also ASDF requires GCL 2.7 so --system won't work with an old gcl 2.6.
There are some issues regarding standalone executables on CLISP or ECL.
See below in the section regarding STANDALONE EXECUTABLES.
LispWorks requires the Professional Edition. Personal edition isn't supported
as it won't let you control the command line or dump images. Dumped Images
will print a banner, unless you dump a standalone executable.
Additionally, cl-launch supports the use of clbuild as a wrapper to invoke
the Lisp implementation, with the --clbuild option.
LISP IMPLEMENTATION INVOCATION
When a cl-launch generated script is invoked, the cl-launch shell wrapper will
try to execute the Lisp code with the first Common Lisp implementation it finds
in a given list, which can be specified through option --lisp. The runtime
behaviour of the cl-launch shell wrapper is very configurable through a series
of environment variables. These variables can be controlled by the user by
exporting them in his environment, or they can be restricted at the time of
script generation by using cl-launch option --wrap.
If variable LISP is defined, the shell wrapper will first try the implementation
named by variable LISP. If that fails, it will try the list of implementations
provided at script generation time. The list of implementations generated will
be the argument to option --lisp if specified. Otherwise, cl-launch will supply
its default value. This default value for the current instance of cl-launch is:
sbcl clisp ccl cmucl ecl gclcvs allegro lispworks lisp gcl
This LISP selection only happens at system preparation time. If you dump an
image then the script will always use the Lisp implementation for which an
image was dumped. If you don't then the user may override the implementation.
Note that these are nicknames built into the cl-launch shell wrapper, and not
necessarily names of actual binary. You may control the mapping of
implementation nickname to actual binary pathname to call with an environment
variable. For a given implementation nickname, the environment variable will be
the capitalization of the given nickname. Hence, variable $SBCL controls where
to look for a sbcl implementation, and variable $CMUCL controls where to look
for a cmucl implementation. If a binary is found with a matching pathname
(using the standard unix $PATH as required), then said implementation will be
used, using proper command line options, that may be overriden with an
environment variable similar to the previous but with _OPTIONS appended to its
name. Hence, $CMUCL_OPTIONS for cmucl, $CLISP_OPTIONS for clisp, etc.
Sensible defaults are provided for each implementation, so as to execute the
software in non-interactive mode, with debugger disabled, without reading
user-specific configuration files, etc.
If you want to insist on using a given implementation with given options,
you may use option --lisp and --wrap, as follows:
--lisp 'sbcl clisp' wrap '
LISP= # do not allow the user to specify his implementation
SBCL=/usr/bin/sbcl # not any experimental thing by the user
SBCL_OPTIONS="--noinform --sysinit /dev/null --userinit /dev/null \
--disable-debugger" # predictable Lisp state
CLISP=/usr/bin/clisp # fall back on machines that lack SBCL
CLISP_OPTIONS=" -norc --quiet --quiet"
LISP_FASL_CACHE=/var/cache/lisp-fasl # assuming precompiled fasls there
'
If you dump an image, you need not unset the LISP variable, but you
might still want to override any user-specified SBCL and SBCL_OPTIONS
(or corresponding variables for your selected implementation) from what
the user may specify.
Note that you can use option --wrap "$(cat your_script)"
to embed into your program a full fledged script from a file.
Your script may do arbitrary computations before the shell wrapper is run.
It may make some consistency checks and abort before to run Lisp.
Or it may analyze invocation arguments and make according adjustments
to Lisp implementation options. This can be useful for setting options
that cannot be set from the Lisp code, such the path to a runtime image,
interactive or non-interactive execution, size of heaps,
locale settings for source file encoding, etc.
Reading the source code of cl-launch can be completely crazy. You may have
great fun understanding why things are how they are and adding features
without breaking anything! However, adding support for a new CL implementation
should be straightforward enough: just search the sources for "clisp" or "sbcl"
and mimic what I did for them. Be sure to send me what will get your favorite
Lisp flavor of the month rolling.
LIMITED CLBUILD SUPPORT
cl-launch 2.12 and later support using clbuild as a wrapper to configure your
Lisp implementation, with option --clbuild (which can be disabled with option
--no-clbuild if it was enabled by default in your cl-launch installation).
Note that you use clbuild, you can no longer override implementation options
with say SBCL_OPTIONS, as clbuild takes care of the options for you. Any
implementation banner will not be removed unless you instruct clbuild to do so.
Also, you cannot use clbuild with a non-executable image different from
clbuild's, which precludes image dumping with cmucl or allegro (allegro could
probably be updated, but I don't have a recent licence to test and develop).
clbuild support is not fully tested at this point. Please report any bug.
SIMPLE CL-LAUNCH SCRIPTS
In simple cases, you may create a Common Lisp shell script with CL-Launch
without a script generation step, just because you'll spend a lot of time
editing the script and distributing it, and little time waiting for script
startup time anyway. This notably is a good idea if you're not spawning many
instances of the same version of a script on a given computer. If that's
what you want, you may use cl-launch as a script interpret the following way
(stripping leading spaces):
#!/path/to/cl-launch -X ...options... --
For instance, you may write the following script (stripping leading spaces):
#!/usr/bin/cl-launch -X --init '(format t "foo~%")' --
(format t "hello, world~%")
(write cl-launch:*arguments*) (terpri)
The limitation is that the first argument MUST be '-X' (upper case matters,
and so does the following space actually), the last one MUST be '--' and all
your other arguments (if any) must fit on the first line, although said line
can be as long as you want: the kernel has a limit of 127 characters or so
for this first line, but cl-launch will read the first line directly from
the Lisp script, anyway.
Note that if you don't need Lisp code to be loaded from your script,
with everything happening in the --file --system and --init software
specification, then you may instead use a simple #!/bin/sh shell script
from which you exec /path/to/cl-launch -x ... -- "$@".
Also, in case you can't rely on cl-launch being at a fixed path, or if your
shell and/or kernel combination doesn't support using cl-launch as a script
interpreter, then you may instead start your script with the following lines
(stripping leading spaces):
#!/bin/sh
":" ; exec cl-launch -X -- "$0" "$@" || exit 42
(format t "It works!~%")
In practice, I've found that machines with custom-compiled Linux kernels
2.6.15 and later supported #!/usr/bin/cl-launch fine with a wide variety of
shells (I tried all of posh 0.4.7, bash 2.05, bash 3.1, zsh 4.3.2, dash 0.5.3
and busybox 1.01 ash), whereas other machines with a standard Linux
kernel 2.6.11 from debian would not support it with any shell.
Maybe an issue with kernel binfmt_misc configuration?
DUMPING IMAGES
You can dump an image (for static compilation and fast startup) with option
--dump IMAGE where IMAGE specifies the path where the image will be dumped.
If you use option --include PATH then the image will be loaded back from
that specified directory instead of the directory where you dumped it. This
is useful if you're preparing a script to be installed at another place maybe
on another computer.
This option is currently supported on all CL implementations available
with cl-launch.
As a limitation, LispWorks will print a banner on standard output,
unless you use the standalone executable option below.
STANDALONE EXECUTABLES
You can create standalone executables with the option --dump '!'
(or by giving a --dump argument identical to the --output argument).
This option is currently only supported with SBCL, ECL, CLISP and
LispWorks Professional. Moreover, ECL and CLISP have the issues below.
CLISP standalone executables will react magically if invoked with options
such as --clisp-help or --clisp-x '(sys::main-loop)'. That's a pretty
far-fetched thing to hit by mistake, and the CLISP maintainers consider it
a feature. But don't use such executables as setuid, and don't let untrusted
users control arguments given to such executables that are run with extra
privileges.
As of CL-Launch 2.11 and ECL 0.9l, dumping ASDF systems seems to not work
reliably when some object files from previous compilation attempts are
present in the cache (typically in ~/.cache/lisp-fasl/ecl*). The current
known workaround is to clear (rm -rf) your cache and compile from clean.
CL-LAUNCH RUNTIME API
cl-launch provides the following Lisp functions:
Variable cl-launch:*arguments* contains the command-line arguments used
to invoke the software.
Function cl-launch:getenv allows to query (but not modify) the environment
variables, as in (getenv "HOME"), returning nil when the variable is unbound.
Function cl-launch:load-system takes as an argument the name of an asdf system
and the keyword argument verbose, and loads specified system with specified
verbosity.
Function cl-launch:compile-and-load-file takes as an argument a source pathname
designator, and keyword arguments force-recompile (default NIL) and verbose
(default NIL). It will arrange to compile the specified source file if it is
explicitly requested, or if the file doesn't exist, or if the fasl is not
up-to-date. It will compile and load with the specified verbosity. It will
take use cl-launch:compile-file-pathname* to determine the fasl pathname.
Function cl-launch:compile-file-pathname* is a variant of the similarly named
ANSI CL function cl:compile-file-pathname that takes into account the
fasl cache and also common-lisp-controller (if present).
It works by calling cl-launch:apply-output-pathname-translations with the truename
of the given source file. The specified source file must exist.
Function cl-launch:apply-pathname-translations takes a pathname as an argument,
and an optional list of translations (by default, it will use those from
cl-launch:*output-pathname-translations*). It will scan the list of
translations, where every translation is a list of a source pathname
and a destination pathname. If the source pathname matches, then the file
is translated to the destination pathname.
Function cl-launch:apply-output-pathname-translations takes a pathname as an
argument translates it into a pathname in the cache. If common-lisp-controller
is present then the c-l-c cache is used. Otherwise, the cl-launch cache as
specified by cl-launch:*output-pathname-translations* is used.
Variable cl-launch:*output-pathname-translations* is the list of translations
that apply-pathname-translations will use by default.
asdf, if present, will have been configured to make use of this mechanism.
Function cl-launch:quit will cause the current Lisp application to exit.
It takes two optional arguments code with default value 0, and finish-output
with default value t. The first is to be used as the process exit code, the
second specifies whether to call finish-output on *standard-output* and
*error-output*. Note that you should use (finish-output) and otherwise flush
buffers as applicable before you quit, not just to be standard-compliant, but
also to support ccl and any other Lisp implementation that do buffering.
Additionally, environment variables CL_LAUNCH_PID and CL_LAUNCH_FILE
will be set to the process ID and the script invocation filename respectively.
VERBOSE OUTPUT MODE
If the shell variable CL_LAUNCH_VERBOSE is exported and non-nil, then
cl-launch and the scripts it generates will produce an abundance of output,
display such things as the Lisp invocation command, compiling and loading
files with :verbose t and :print t, etc. This is only useful for debugging
cl-launch and/or your build process. Option --verbose sets this variable,
whereas option --quiet resets it.
USING CL-LAUNCH FUNCTIONALITY IN YOUR LISP DEVELOPMENT ENVIRONMENT
When you develop programs that you will use with cl-launch, you may as well use
cl-launch during development, and benefit from its fasl cache architecture.
To this end, you may explicitly include the cl-launch Lisp header from your
Lisp source code or from the Lisp initialization file for your favorite
implementation (~/.sbclrc, ~/.cmucl-init, ~/.clisprc, etc.):
#-cl-launch (load "/usr/share/common-lisp/source/cl-launch/launcher.lisp")
If cl-launch is not installed at a fixed system location, you may create
a copy in your own directory with such a command as
cl-launch -B print_lisp_launcher > ~/src/cl-launch/launcher.lisp
Alternatively, you may include cl-launch itself instead of an extracted header,
if only you tell your Lisp reader consider #! as introducing a line comment:
(set-dispatch-macro-character #\# #\!
#'(lambda (stream char arg)
(declare (ignore char arg)) (values (read-line stream))))
#-cl-launch (load "/path/to/cl-launch.sh")
Finally, if you use cl-launch from debian, or it was otherwise installed with
cl-launch -B install
or if you create the asd in addition to the header and declare it to asdf
cl-launch -B print_cl_launch_asd > ~/src/cl-launch/cl-launch.asd
then if your installed cl-launch.asd is properly symlinked from a directory
in your asdf:*central-registry*, you may just have your software depend on
the system :cl-launch
(asdf:oos 'asdf:load-op :cl-launch)
which in some implementations (sbcl) can be simplified into
(require :cl-launch)
You may also declare in the asdf:defsystem for your software that it
:depends-on (:cl-launch ...)
MAKEFILE EXAMPLES:
### Automatically download of the current version of cl-launch if not present
cl-launch.sh:
wget -O cl-launch.sh http://fare.tunes.org/files/cl-launch/cl-launch.sh
chmod a+x cl-launch.sh
### Making a shell script executable from a simple Lisp file named foo.lisp
foo.sh: cl-launch.sh foo.lisp
./cl-launch.sh --output foo.sh --file foo.lisp
### A more complex example using all options.
run-foo.sh: cl-launch.sh preamble.lisp
./cl-launch.sh --output run-foo.sh --file preamble.lisp --system foo \
--init "(foo:main cl-launch:*arguments*)" \
--path ${PREFIX}/cl-foo/systems \
--lisp "ccl sbcl" --wrap 'SBCL=/usr/local/bin/sbcl-no-unicode' \
--no-include
### An example with horrible nested makefile, shell and Lisp quoting
hello:
opera=wORlD ; ./cl-launch.sh --execute --init \
"(format t \"~25R~A~A~%\" 6873049 #\\space '$$opera)"
CAVEAT LISPOR
cl-launch begins evaluation of your Lisp software in the CL-USER package.
By the time your initialization forms are evaluated, the package may or may
not have changed, depending on the fine-grained semantics of load.
Be sure to use in-package if these things matter.
There are lots of ways of making mistakes by improperly quoting things when
you write shell commands. cl-launch does the right thing, but you still must
be careful with the nested quoting mechanisms of make, shell, and Lisp.
Here is a simple example use of cl-launch to quickly compare the result of
a same computation on a variety of systems:
for l in sbcl cmucl clisp gcl ccl ; do
./cl-launch.sh --lisp $l --execute --init \
'(format t "'$l' ~A~%" most-positive-fixnum)' ; done
Internally, cl-launch includes many self-test functions.
You may for instance try (from a directory where it may create junk)
./cl-launch.sh -l 'sbcl cmucl clisp gclcvs' -B tests
ASDF-install package (obsolete) http://common-lisp.net/project/xcvb/cl-launch/cl-launch.tar.gz
deployment