[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: |
Mon, 9 Jan 2017 05:28:43 -0500 |
> 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
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/01/07
- Re: Skipping unexec via a big .elc file,
Ken Raeburn <=
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/01/09
- Re: Skipping unexec via a big .elc file, Andreas Schwab, 2017/01/10
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/01/10
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/01/11
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/01/12
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/01/14
- Re: Skipping unexec via a big .elc file, Andreas Schwab, 2017/01/14
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/01/14
- Re: Skipping unexec via a big .elc file, Alan Mackenzie, 2017/01/14
- Re: Skipping unexec via a big .elc file, Andreas Schwab, 2017/01/14