Self-contained emacs binary?

[Daniel Colascione <dancol@dancol.org>]

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.