[cmucl-imp] ASDF 2.016 released

[Faré]

> I started to move the shell script into C; that doesn't look too hard,
> but then I realized that for an executable to be able to create another
> executable image, you need to also have lisp.a, which is basically the
> run time.  For the executable to be self contained, that would also have
> to be in the executable.
>
> At this point I'm giving up.  I don't really want to store lisp.a inside
> the executable too.
>
> Not sure what to do at this point.  But I will add the necessary
> function to load up unidata into core in case someone wants that.
>
Interesting. Well, for delivery, I would be satisfied with not
including the lisp.a in the executable -- it is only require when
you're using the compiler for development, at which point it's OK to
not embed lisp.a (or unidata) into the image. After all, the CLISP
linkkit isn't embedded in the clisp executable itself, so you'll be no
worse off than other implementations. But yes, that sucks. Of course,
you could conceivably "unlink" the current process image (or its
executable as found with /proc ?) into a platform-specific .o file to
link at a static address, but while a cool hack, it's not necessary.
Didn't ELK kind of do that, though?

This all reminds me how cl-launch does it, being a shell script that
embeds code that it can either use (after eval'ing it) or dump into
shell scripts for delivery. Gah.

-#f