[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Skipping unexec via a big .elc file
From: |
Ken Raeburn |
Subject: |
Re: Skipping unexec via a big .elc file |
Date: |
Wed, 8 Feb 2017 05:31:31 -0500 |
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
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/02
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/02/04
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/05
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/02/05
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/05
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/06
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/02/06
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/06
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/02/06
- Re: Skipping unexec via a big .elc file,
Ken Raeburn <=
- Re: Skipping unexec via a big .elc file, Ken Brown, 2017/02/08
- Re: Skipping unexec via a big .elc file, Ken Brown, 2017/02/05
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/02/25
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/02/25
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/02/26