Re: Skipping unexec via a big .elc file

[Ken Raeburn]

> On Jan 7, 2017, at 04:40, Eli Zaretskii <address@hidden> wrote:
> 
> Ken,
> 
> I tried to get rid of calling dump-emacs in the raeburn-startup
> branch, see the changes below.  The resulting code builds and produces
> dumped.elc, but then fails to compile the *.el files:

I’ve been looking into it this weekend.  It appears that in some of my builds 
I’m seeing in dumped.elc stuff along the lines of:

(setplist 'window-parameter '(gv-expander (closure (t) #19=(do &rest args) 
(gv--defsetter 'window-parameter (lambda #20=(val &rest args) 
`(,'set-window-parameter . #21=(,@args ,val))) . #22=(do args))) 
side-effect-free t))

That’s with my #N# patch removed; that patch obfuscates the code but I don’t 
think it should be changing the meaning.

The comma-quote-symbol syntax looks strange to me, could that be causing it?

> This could be related to the fact that the original code produced the
> first dumped.elc in the top-level directory, not in src/, and I needed
> to fix that, since otherwise bootstrap-emacs would exit immediately
> (see the changes below).  In the original version, src/dumped.elc was
> only produced after all the necessary Lisp files were byte-compiled
> already.

In the GNU/Linux build, the dumped.elc file is generated in the src directory 
of the build tree.  So that part of your patch didn’t alter anything for my 
testing as far as I can see.

But the GNU/Linux build supports building in a separate tree from the source 
tree, a mode I usually do my builds in, and at startup we look for dumped.elc 
in the src directory of the source tree, not the build tree.  So I still have 
to tweak it manually.

> So it seems like the current build process on this branch still
> somehow depends on a dumped emacs executable, until it byte-compiles
> all the preloaded Lisp files, and produces dumped.elc from that.  IOW,
> the first dumped.elc produced before byte-compiling those files is not
> up to the job of running Emacs for byte-compiling Lisp files.  How can
> we fix that, so that unexec and its call can be really removed from
> the sources?  Or did I miss something?

A workaround might be to use loadup.el instead of dumped.elc during that stage. 
 But that doesn’t fix the problem.

Ken