joa...@verona.se writes: > Paul Smith <psm...@gnu.org> writes: > >> On Wed, 2013-07-31 at 20:54 +0200, joa...@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.
