Re: Self-contained emacs binary?

[Ken Raeburn]

On Feb 15, 2018, at 21:37, Daniel Colascione <address@hidden> 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