Re: Guile-Emacs update

[taylanbayirli@gmail.com (Taylan Ulrich B.)]

joakim@verona.se writes:

> Paul Smith <psmith@gnu.org> writes:
>
>> On Wed, 2013-07-31 at 20:54 +0200, joakim@verona.se wrote:
>>> #make takes a loong time, much more than a normal emacs
>>> ./autogen.sh && ./configure && make
>>
>> I'm not familiar with building Emacs, but doesn't its build system
>> support parallel compilation (couldn't you run "make -j4" or whatever's
>> appropriate for your system to get a nice speedup)?
>>
>
> I think the slowness was during lisp compilation, and that didnt use to
> benefit from parallel compilation. I might try again though.

The slowness is during .el byte-code compilation (and partly autoload
generation), because the Makefile starts a new Emacs for every .el to be
compiled, and Guile Emacs starts very slow (about 10 seconds?) because
the "dumping" feature of Emacs is disabled, thus it loads even the
fundamental Elisp libraries from the ground up when started (the
executable is "barebones").  The loading of said fundamental Elisp
libraries is normally suppressed by using not a barebones executable,
but an executable that's generated by starting said barebones executable
once (*with* dumping capability), loading the files, then dumping.

(Yeah, Emacs actually supports dumping its memory image into a runnable
executable, see Elisp function `dump-emacs', but it's limited and
unusable for day-to-day usage, and only used during compilation to
generate this executable with pre-loaded Elisp libraries.)

I managed to inhibit .el compilation and autoload generation by screwing
around with the Makefiles and loadup.el; the result just causes more
headaches if you want to test Guile Emacs in a sane fashion, but it
basically works if you don't have a fancy .emacs, and allows to test
changes in the base C source (which is what I'm doing recently), so if
you have a similar use-case you can notify me and I'll post the hacky
patches somewhere.