Re: Self-contained emacs binary?

[Ken Raeburn <raeburn@raeburn.org>]

On Feb 15, 2018, at 21:37, Daniel Colascione <dancol@dancol.org> wrote:

> On 02/15/2018 06:25 PM, Daniel Colascione wrote:
>> On 02/15/2018 05:54 PM, Stefan Monnier wrote:
>>>> I do wonder whether it makes sense to try to copy the dump into the
>>>> Emacs executable itself instead of leaving it as a separate file.
>>> 
>>> We could try, but:
>>> - it adds complexity and maybe system-dependent hacks.
>> Not if we just tack onto the end.
>>> - it closes the opportunity to have several dump files for a single
>>>    executable (I was thinking we could try and let end-users build their
>>>    own dump file).
>> Not necessarily. Suppose we go with the append-to-the-executable option. Then, to "re-dump" emacs, we'd open the current executable, copy it to a temporary file, back up to the start of the dump, ftruncate. Now we've recovered temacs and we can go through normal loadup and dump.
>> Maybe we can even automatically detect changes to any file in load-history and perform this procedure automatically on startup.
> 
> You know, we could just append a whole zip archive to the executable and load elisp files from this zip archive. (The dump file would be just another file in the archive.) This way, we'd be able to make a self-contained "emacs" binary that wouldn't need special installation. (arc-mode would keep find-library working.) We could even mmap files from the zip archive as long as the files are suitably aligned and STOREd instead of compressed; Android uses this trick to map stuff sitting inside APK files.

Embedding the Lisp support code (or other things) via C character arrays during the build process would also work, and would be cleaner, though it specifically fails to handle your dump-file issue, unless you do go the route of patching up an embedded array later. I do think that’s probably cleaner than appending arbitrary data to an executable.

(On a tangent to that, I’ve got some experimental patches around for embedding the C doc strings in the executable, halfway to eliminating the need for the separate DOC file.)

Tying the dump to the executable image required to make it work does seem like a win. I’m not sure I’d call it entirely “self-contained” unless you could somehow fold in the info files, support executables like movemail and hexl, etc., sort of like the “app” bundle on macOS does (really a directory but the GUI treats it as one object for moving around).

Ken