Re: Skipping unexec via a big .elc file

[Ken Raeburn]

On Feb 6, 2017, at 17:39, Stefan Monnier <address@hidden> wrote:

>> Is this a known (and filed) bug?
> 
> I don't think it's filed, no.  I've known about it for a while now, and
> it came up "recently" in the discussion about reproducible builds.
> Until then it wasn't considered as a real bug, I think, more like
> a quirk.

Ah, okay.  I didn’t follow that discussion closely.  I haven’t got the 
bandwidth to keep up on everything, and until now I thought I didn’t care about 
this one. :-)

With my bootstrap builds running without parallel make, I’ve gotten things much 
further along in terms of generating .elc files that match what I get without 
all the big-elc changes.

The difference in progmodes/python.elc came down to the use of UTF-8 in the 
environment during byte compilation affecting the generated doc strings (using 
format-message in a macro).  Removing internal--text-quoting-flag from the 
stuff saved in dumped.elc made the files match for me on my Mac (with UTF-8 in 
use by default).  I think that’s just papering over the real problem (the 
macro’s result shouldn’t depend on the UTF-8-ness of the environment), but the 
flag should reflect the environment of the current Emacs invocation anyway, not 
the one that produced dumped.elc.

The difference in url/url-handler.elc was because the subr doc strings were 
getting lost.  The numbers (“DOC” file offsets) stored in the Lisp_Subr 
structure weren’t preserved, so url-handlers-create-wrapper would just fill in 
“No original documentation.”  I’m making dumped.elc invoke Snarf-documentation 
for now.

A tangent: As it happens, a couple years back I was experimenting with having 
C-based subr/variable documentation stuffed into the executable instead of 
needing the DOC file, in ways that wouldn’t add a lot of Lisp data unless the 
doc strings were actually needed.  For subr documentation, it doesn’t create 
Lisp strings until they’re requested.  For variables, I’ve got an idea on 
deferring the Lisp string creation, but currently they’re created at startup 
and stuffed into the property list.  I’ve just updated it to recent Emacs 
sources, in case we might want to explore that direction further; it might be 
more efficient than patching up doc pointers every time we start up.

Anyway, with the changes I’ve just pushed to the branch, my bootstrapped tree 
has .elc files that match those built from the branch point, except for 
mule.elc, macroexp.elc (both source files changed on the branch), bytecomp.elc 
and byte-opt.elc (probably due to macroexp changes).

I haven’t tried any more extensive testing.
There may be some funny stuff going on in restoring the charset definitions 
that I still need to look into.

I haven’t pulled in Ken Brown’s Cygwin changes; Ken, feel free to push those to 
the branch as well.

Ken