TODO for cl-launch as of 4.1.4

* Maybe add support for some Guile-like "meta switch" ?
  https://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html#The-Meta-Switch

* 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
   other stuff.

* 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?
   * --compress-core

     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.

   * --dynamic-space-size
     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"
   * --sbcl
     Can already be done with:
       --wrap 'SBCL="/opt/sbcl/bin/sbcl"

     Implement it that way?

   * --core-only
     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
   tools/cl-source-registry-cache.lisp

* 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
   bootstrap?