Re: compiled lisp file format (Re: Skipping unexec via a big .elc file)

[Ken Raeburn]

On May 28, 2017, at 17:09, Paul Eggert <address@hidden> wrote:

> Ken Raeburn wrote:
>> I think Guile is using whatever the native word size and architecture are.  
>> If we do that for Emacs, they’re not portable between platforms.
> 
> Sure, but we're talking about the format Emacs uses to save its state, not 
> the format of .elc files. Currently Emacs saves its state as an executable 
> file that in general cannot be moved from one GNU/Linux distribution to 
> another even if they have the same architecture. Switching to Guile's 
> platform-neutral approach would make Emacs's saved-state format more 
> portable, not less.

Actually, I was referring to compiled-Lisp files generally, including the 
“dumped.elc” file, when I suggested it.

And I wouldn’t describe Guile’s “ELF everywhere” approach as entirely 
platform-neutral.  I built a Guile tree tonight to take a look.  My guess 
earlier about using the native architecture was wrong (it uses “none”), but it 
appears that the generated files are specific to the host’s byte order and word 
size.  So some sharing is possible between similar platforms, but not across 
all as with the current .elc format.

Even saving just the Lisp state as with “dumped.elc”, I think there could be 
state from the environment or build options that varies across distributions.  
Lists of supported image types, distro customizations, things like that.  I’m 
not sure what benefit there is in trying to share saved Emacs state across 
distros.  If the goal is for a user to save a massively customized environment 
for future invocations, perhaps we should just work on speeding up the loading 
of the customizations.

If we want standardized object/executable format specifically for the preloaded 
environment, perhaps using the native format by way of the C compiler is a 
better choice.  I think this may have come up in the discussion before.  The 
big loss there is the ability to create a new saved environment without having 
a C compiler handy, but it seems like a thing few people are likely to want to 
do, and even fewer non-developers who might not be able to install a compiler.

Ken