TODO for cl-launch as of 4.1.4
* When resuming from an image then dumping another, the INCLUDE_PATH
becomes a very bad variable to look for the image.
Include a test case and fix it.
More generally, test with directory differences between image and
* Maybe: add "dump from previous image" support for ECL?
One limitation that cl-launch has on ECL (vs on e.g. SBCL)
is the inability to "dump an image from a previous image".
This could be achieved by hacking asdf:make-build
(from ecl/contrib/asdf/asdf-ecl.lisp) to intercept in a
(defmethod perform :before ((op monolithic-bundle-op) (c system)) ...)
the arguments to the last call to c::builder, and to re-inject those
arguments in same call them the next time around, assuming
(which is somewhat fragile) that objects won't have been moved or
deleted by then. I do not currently intend to support this feature
in cl-launch, but will hopefully support it in XCVB that can do the
bookkeeping on its side.
NB: as in uiop/lisp-build:compile-file*, use
(with-enough-pathname (input-file :defaults *base-build-directory*)
* Add support for the REPL and/or interpreting commands from stdin;
it can be called explicitly with --repl
or disabled explicitly with --no-repl,
but it otherwise provided as the default fallback behavior
when neither script nor build or execution command is provided.
This brings behavior to par with /bin/sh.
For extra brownies, automatically wrap inside rlwrap or some such
if at the terminal (or conversely, disable GNU CLISP interactivity
when not wanted).
* Convert cl-launch to a pure Lisp program, that can
create a shell script for bootstrap purposes?
Therefore, /usr/bin/cl can have fast startup,
and not have to spawn an external program
unless explicitly requested a non-default implementation.
Maybe just add all the cl-launch features to buildapp.
* Support these other options from Xach's buildapp?
--load-path --asdf-path --asdf-tree --manifest-file --logfile
* asdf-path and asdf-tree would be accumulated into a source-registry
argument to be passed to cl-launch.
* load-path would not only require something similar, but also
using a SEARCH-AND-LOAD function that consults this path
before it loads something.
* Maybe add these SBCL-specific options, too?
this one is trivial to add --
currently, buildapp silently ignores the option on CCL,
but Xach feels like he may issue an error in the future instead.
a lot of implementation have something like that.
Abstract it away, or leave it implementation-specific?
Can already be done with:
--wrap 'SBCL_OPTIONS="--dynamic-space-size 1024"
Can already be done with:
Implement it that way?
That's hard to add, not that useful, and may require hacking
both uiop and cl-launch to get it right. Lots of pain, no gain.
* Find a way to load faster?
When starting cl-launch, I experience a pause of ~1s.
Half of it is loading the asdf fasl, then the upgraded asdf fasl.
The other half is scanning the source registry.
At least this scanning can be sped up, using ASDF 3.1.4's
* Use #+sbcl (setf sb-ext:*evaluator-mode* :interpret)
and a series of (declaim (optimize (speed 0) (size 0) (debug 0)
(compilation-speed 3))) and such to speed up the cl-launch