[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Self-contained emacs binary?
From: |
Ken Raeburn |
Subject: |
Re: Self-contained emacs binary? |
Date: |
Sun, 18 Feb 2018 11:05:03 -0500 |
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
- Re: Preview: portable dumper, (continued)
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/15
- Re: Preview: portable dumper, Paul Eggert, 2018/02/15
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/15
- Re: Preview: portable dumper, Eli Zaretskii, 2018/02/16
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/16
- Re: Preview: portable dumper, Eli Zaretskii, 2018/02/16
- Re: Preview: portable dumper, Andy Moreton, 2018/02/16
- Re: Preview: portable dumper, Stefan Monnier, 2018/02/15
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/15
- Self-contained emacs binary?, Daniel Colascione, 2018/02/15
- Re: Self-contained emacs binary?,
Ken Raeburn <=
- Re: Preview: portable dumper, Phillip Lord, 2018/02/21
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/26
- Re: Preview: portable dumper, Phillip Lord, 2018/02/26
- Re: Preview: portable dumper, Clément Pit-Claudel, 2018/02/26
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/26
- Re: Preview: portable dumper, Eli Zaretskii, 2018/02/16
- Re: Preview: portable dumper, Andy Moreton, 2018/02/16
- Re: Preview: portable dumper, Daniel Colascione, 2018/02/16
- Re: Preview: portable dumper, Robert Pluim, 2018/02/16
- Re: Preview: portable dumper, Philipp Stephani, 2018/02/16