> The attached patch implements an extension to SAVE-LISP-AND-DIE that
> can be used to deliver "standalone" executables. The general plan is
> the same as that used by OpenMCL:
Cool. A few thoughts on the interface:
> There are some other things that could perhaps be done: it might be
> nice to rename the runtime options when using an embedded image (maybe
> --sbcl-<option>) to make things easier on delivered programs that
> parse command-line arguments.
Renaming the options seems confusing. If normal parsing must be
circumvented (I'm not sure whether it's a good idea), how about
skipping runtime arguments unless argv starts with
"--begin-runtime-arguments", or something along those lines?
> I also think initialization files
> should not be loaded
People using their own toplevel function won't get any non-runtime
command line processing by default (which includes the init files).
> and --noinform should be the default.
Maybe allow specifying what default command line arguments to use when
saving the core? These could be saved in the executable the same way
the core is. Though possibly the utility of this wouldn't justify the
> I've tested this so far on Linux (x86 and x86-64) and ppc/Darwin. I
> included an implementation of os_get_runtime_executable_path for
> Win32, but I haven't tested it yet---I'd be happy to do so when the
> immediate Win32 pathname problems are resolved. It should be easy
> to port this to other UNIXes if they have something like Linux's
It seem to me that when the executable can't be found (due to it being
impossible on the platform, proc not being mounted, or whatever) the
user should be allowed to specify a path to the runtime. For example
:PREPEND-RUNTIME NIL -> save normal core, T -> determine runtime
location automatically, a pathname designator -> use that pathname as
> + :PREPEND-RUNTIME
> + If true, the SBCL runtime executable will be prepended to the
> + core file. On supported operating systems (currently Linux,
> + Darwin, and Windows), the core file will be made executable and
> + can be delivered as a stand-alone binary. If false (the default),
> + the core file will not be made directly executable.
Exposing the implementation details in the interface doesn't seem like
the right thing. Maybe something like :EXECUTABLE or
> +save_runtime_to_filehandle(char *runtime_path, FILE *output)
This function should check whether the specified runtime already
contains a core, and only output the non-core parts of the file if so.