Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
#!/bin/sh
#| cl-launch.sh -- shell wrapper generator for Common Lisp software -*- Lisp -*-
CL_LAUNCH_VERSION='2.16'
license_information () {
AUTHOR_NOTE="\
# Please send your improvements to the author:
# fare at tunes dot org < http://www.cliki.net/Fare%20Rideau >.
"
SHORT_LICENSE="\
# CL-Launch is available under the terms of the bugroff license.
# http://www.geocities.com/SoHo/Cafe/5947/bugroff.html
# You may at your leisure use the LLGPL instead < http://www.cliki.net/LLGPL >
"
WEB_SITE="# For the latest version of CL-Launch, see its web page at:
# http://www.cliki.net/cl-launch
"
LICENSE_COMMENT="\
# This software can be used in conjunction with any other software:
# the result may consist in pieces of the two software glued together in
# a same file, but even then these pieces remain well distinguished, and are
# each available under its own copyright and licensing terms, as applicable.
# The parts that come from the other software are subject to the terms of use
# and distribution relative to said software, which may well be
# more restrictive than the terms of this software (according to lawyers
# and the armed henchmen they got the taxpayers to pay to enforce their laws).
# The bits of code generated by cl-launch, however, remain available
# under the terms of their own license, and you may service them as you wish:
# manually, using cl-launch --update or whichever means you prefer.
# That said, if you believe in any of that intellectual property scam,
# you may be subject to the terms of my End-Seller License:
# http://www.livejournal.com/users/fare/21806.html
"
DISCLAIMER="\
# This file was automatically generated and contains parts of CL-Launch
"
}
license_information
### Settings for the current installation -- adjust to your convenience
### Or see documentation for using commands -B install and -B install_bin.
DEFAULT_LISPS="sbcl clisp ccl cmucl ecl gclcvs allegro lispworks lisp gcl"
DEFAULT_INCLUDE_PATH=
DEFAULT_USE_CL_LAUNCHRC=
DEFAULT_USE_CLBUILD=
### Initialize cl-launch variables
unset \
SOFTWARE_FILE SOFTWARE_SYSTEM SOFTWARE_INIT_FORMS \
SYSTEMS_PATHS INCLUDE_PATH LISPS WRAPPER_CODE \
OUTPUT_FILE UPDATE \
LINE LINE1 LINE2 NO_QUIT CONTENT_FILE \
TRIED_CONFIGURATION HAS_CONFIGURATION \
EXEC_LISP DO_LISP DUMP LOAD_IMAGE RESTART IMAGE IMAGE_OPT \
EXTRA_CONFIG_VARIABLES \
EXECUTABLE_IMAGE STANDALONE_EXECUTABLE CL_LAUNCH_STANDALONE \
TEST_SHELLS TORIG IMPL
LISPS="$DEFAULT_LISPS"
INCLUDE_PATH="$DEFAULT_INCLUDE_PATH"
USE_CL_LAUNCHRC="$DEFAULT_USE_CL_LAUNCHRC"
USE_CLBUILD="$DEFAULT_USE_CLBUILD"
UNREAD_DEPTH=0
OUTPUT_FILE="!"
### Other constants
MAGIC_MD5SUM="65bcc57c2179aad145614ec328ce5ba8"
CONTENT_DISCLAIMER="\
;;; THE SOFTWARE AFTER THIS MARKER AND TO THE END OF THE FILE IS NOT PART OF
;;; CL-LAUNCH BUT A PIECE OF SOFTWARE DISTINCT FROM CL-LAUNCH. IT IS OWNED BY
;;; BY ITS OWNERS AND IS SUBJECT ITS OWN INDEPENDENT TERMS OF AVAILABILITY."
CONTENT_BEGIN_MARKER="\
;;; ${MAGIC_MD5SUM} SOFTWARE WRAPPED BY CL-LAUNCH BEGINS HERE:"
### Help
## setup a few environment variables for the program
BASIC_ENV_CODE='PROG="$0"'
eval "$BASIC_ENV_CODE"
PROGBASE="${0##*/}" # "$(basename "$0")"
CL_LAUNCH_URL="http://fare.tunes.org/files/cl-launch/cl-launch.sh"
HELP_HEADER="cl-launch.sh $CL_LAUNCH_VERSION -- shell wrapper generator for Common Lisp software"
print_help_header () {
ECHO "$HELP_HEADER"
}
print_help () {
cat <<EOF
Usage:
$PROGBASE '(lisp (form) to evaluate)'
evaluate specified Lisp form, print the results followed by newline
$PROGBASE --execute [...] [-- arguments...]
run the specified software without generating a script (default)
$PROGBASE --output SCRIPT [--file LISP_FILE] [--init LISP_FORM] [...]
generate a runnable shell script FILE from a software specification
$PROGBASE --update FILE [...]
same as above, but reuse software specification from previous FILE
$PROGBASE [ --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
EOF
}
print_help_footer () {
cat<<EOF
See our web page on
http://www.cliki.net/cl-launch
Note: if this help is too long for you, you may scroll back, or use
$PROG --more-help | less
EOF
}
print_more_help () {
cat<<EOF
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:
$DEFAULT_LISPS
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 ${CL_LAUNCH_URL}
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
Share and Enjoy!
EOF
}
show_help () {
print_help_header
echo
print_help
echo
print_help_footer
exit "${1:-0}"
}
show_more_help () {
print_help_header
echo
print_help
echo
print_more_help
echo
print_help_footer
exit "${1:-0}"
}
error_help () {
show_help "${1:-2}" >& 2
}
show_version () {
echo "cl-launch ${CL_LAUNCH_VERSION}
Supported implementations:
sbcl, cmucl (lisp), clisp, ecl, gcl (gclcvs), ccl (openmcl),
allegro, lispworks
Local defaults for generated scripts:
will search in this order these supported implementations:
${DEFAULT_LISPS}"
if [ -z "$DEFAULT_INCLUDE_PATH" ] ; then
echo "\
will generate self-contained scripts using option --no-include by default"
else
echo "\
will generate scripts by default with runtime dependencies using option
--include ${DEFAULT_INCLUDE_PATH}"
fi
if [ -n "$DEFAULT_USE_CL_LAUNCHRC" ] ; then
echo "\
will use /etc/cl-launchrc and ~/.cl-launchrc by default"
else
echo "\
will not use /etc/cl-launchrc and ~/.cl-launchrc by default"
fi
if [ -z "$DEFAULT_USE_CLBUILD" ] ; then
echo "\
will generate scripts that do not use clbuild by default"
else
echo "\
will generate scripts that use clbuild"
fi
echo
exit
}
### Generic debugging library excerpted from ~fare/etc/zsh/aliases.debug
print_basic_functions () {
cat <<'EOF'
ECHOn () { printf '%s' "$*" ;}
simple_term_p () {
case "$1" in *[!a-zA-Z0-9-+_,.:=%/]*) return 1 ;; *) return 0 ;; esac
}
kwote0 () { ECHOn "$1" | sed -e "s/\([\\\\\"\$\`]\)/\\\\\\1/g" ;}
kwote () { if simple_term_p "$1" ; then ECHOn "$1" ; else kwote0 "$1" ; fi ;}
load_form_0 () { echo "(load $1 :verbose nil :print nil)" ;}
load_form () { load_form_0 "\"$(kwote "$1")\"" ;}
ECHO () { printf '%s\n' "$*" ;}
DBG () { ECHO "$*" >& 2 ;}
abort () { ERR="$1" ; shift ; DBG "$*" ; exit "$ERR" ;}
ABORT () { abort 42 "$*" ;}
EOF
}
eval "$(print_basic_functions)"
kwote1 () { if simple_term_p "$1" ; then ECHOn "$1"
else ECHOn "\"$(kwote0 "$1")\"" ; fi ;}
SHOW () { ( set +x
k="" ; for i ; do ECHOn "$k" ; kwote1 "$i" ; k=" " ; done ; echo
) }
XDO () { SHOW "$@" >&2 ; "$@" ;}
DO () { SHOW "$@" ; "$@" ;}
EVAL () { ECHO "$*" ; eval "$*" ;}
fullpath () {
# If we were sure readlink is here, we could: for i ; do readlink -f "$i" ; done
for i ; do case "$i" in /*) ECHO "$i" ;; *) ECHO "$PWD/$i" ;; esac ; done
}
print_var () {
for var ; do eval "ECHO \"$var=\$(kwote1 \"\${$var}\")\"" ; done ;}
create_file () {
MOD="$1" OUT="$2" ; shift 2; TMPFILE="$OUT.tmp$$~"
if "${@:-cat}" > "$TMPFILE" &&
chmod "$MOD" "$TMPFILE" &&
mv -f "$TMPFILE" "$OUT" ;
then return 0 ; else rm -f "$TMPFILE" ; return 1 ; fi
}
### Process options
OPTION () { process_options "$@" ;}
process_options () {
case "$#:$1" in
"1:-"*)
: ;;
"1:"*)
add_init_form "(princ(progn $1))(terpri)"
shift ;;
esac
while [ $# -gt 0 ] ; do
x="$1" ; shift
case "$x" in
-h|"-?"|--help)
show_help
;;
-H|--more-help)
show_more_help
;;
-V|--version)
show_version
;;
-v|--verbose)
export CL_LAUNCH_VERBOSE=t
;;
-q|--quiet)
unset CL_LAUNCH_VERBOSE
;;
-f|--file)
SOFTWARE_FILE="$1"
shift ;;
-s|--system)
SOFTWARE_SYSTEM="$1"
shift ;;
-i|--init)
add_init_form "$1"
shift ;;
-ip|--print)
add_init_form "(princ(progn $1))(terpri)"
shift ;;
-iw|--write)
add_init_form "(write(progn $1))(terpri)"
shift ;;
-p|--path)
register_system_path "$1"
shift 1 ;;
-pc|--path-current)
path_current ;;
+p|--no-path)
no_paths ;;
-l|--lisp) LISPS="$1"
shift ;;
-w|--wrap) WRAPPER_CODE="$1" ;
shift ;;
-I|--include)
INCLUDE_PATH="$1"
shift ;;
+I|--no-include)
INCLUDE_PATH="" ;;
-R|--rc)
USE_CL_LAUNCHRC=t ;;
+R|--no-rc)
USE_CL_LAUNCHRC= ;;
-b|--clbuild)
USE_CLBUILD=t ;;
+b|--no-clbuild)
USE_CLBUILD= ;;
-o|--output)
OUTPUT_FILE="$1"
shift ;;
-x|--execute)
OUTPUT_FILE="!" ;;
--)
if [ "x${OUTPUT_FILE}" = "x!" ] ; then
do_it "$@"
else
ABORT "Extra arguments given but not in --execute mode"
fi
;;
-X) OPTION -x
#OPTION -iw "cl-launch::*arguments*"
OPTION -i "(cl-launch::compile-and-load-file (pop cl-launch::*arguments*))"
#OPTION -i "$(load_form_0 "(pop cl-launch::*arguments*)")"
;;
-X' '*)
# DBG "Working around sh script script limitation..."
# The below gets the script arguments from the kernel-given argument:
# OPTS="$x" ; eval "OPTION $OPTS \"\$@\""
# The kernel lumps everything after the interpreter name in the #! line
# into one (optional) argument. The line is limited to 127 characters,
# as defined in linux/{fs/binfmt_script.c,include/linux/binfmts.h}.
# If we want to allow for a longer in-script command line argument,
# and we do if we want to accomodate for inline Lisp code using -i
# then we'd need to go fetch the full line and parse it. Here it is:
OPTS="$(get_hashbang_arguments "$1")"
eval "OPTION $OPTS \"\$@\""
ABORT "The cl-launch script $1 failed to use -X ... --"
;;
-u|--update)
UPDATE="$1"
shift ;;
-m|--image)
LOAD_IMAGE="$1"
shift ;;
-d|--dump)
DUMP="$1"
shift ;;
-r|--restart)
RESTART="$1"
shift ;;
-B|--backdoor) "$@" ; exit ;;