aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGlenn Morris2012-07-06 00:08:10 -0700
committerGlenn Morris2012-07-06 00:08:10 -0700
commit50394322c54ab8b51b752c0abe11d75dff5dd18e (patch)
tree64339562e816d7caa5cb1059a6d629f0042efbe0
parent211b896bb076174d325604d886d7dc043f89ca14 (diff)
downloademacs-50394322c54ab8b51b752c0abe11d75dff5dd18e.tar.gz
emacs-50394322c54ab8b51b752c0abe11d75dff5dd18e.zip
* lisp/Makefile.in (compile-one-process): Rename from "recompile".
-rw-r--r--lisp/ChangeLog2
-rw-r--r--lisp/Makefile.in31
2 files changed, 18 insertions, 15 deletions
diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index b9ec54285ec..c177f1540af 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,5 +1,7 @@
12012-07-06 Glenn Morris <rgm@gnu.org> 12012-07-06 Glenn Morris <rgm@gnu.org>
2 2
3 * Makefile.in (compile-one-process): Rename from "recompile".
4
3 * Makefile.in (bzr-update): "compile" is the same as "recompile 5 * Makefile.in (bzr-update): "compile" is the same as "recompile
4 autoloads", but parallelizable, so use that instead. 6 autoloads", but parallelizable, so use that instead.
5 7
diff --git a/lisp/Makefile.in b/lisp/Makefile.in
index 9221ca39168..babb5f3369f 100644
--- a/lisp/Makefile.in
+++ b/lisp/Makefile.in
@@ -133,8 +133,6 @@ setwins_for_subdirs=subdirs=`find . -type d -print`; \
133 esac; \ 133 esac; \
134 done 134 done
135 135
136# `compile-main' tends to be slower than `recompile' but can be parallelized
137# with "make -j" and results in more deterministic compilation warnings.
138# cus-load and finder-inf are not explicitly requested by anything, so 136# cus-load and finder-inf are not explicitly requested by anything, so
139# we add them here to make sure they get built. 137# we add them here to make sure they get built.
140all: compile-main $(lisp)/cus-load.el $(lisp)/finder-inf.el 138all: compile-main $(lisp)/cus-load.el $(lisp)/finder-inf.el
@@ -317,19 +315,22 @@ backup-compiled-files:
317 315
318compile-after-backup: backup-compiled-files compile-always 316compile-after-backup: backup-compiled-files compile-always
319 317
320# Recompile all Lisp files which are newer than their .elc files and compile 318# This does the same job as the "compile" rule, but in a different way.
321# new ones. 319# Rather than spawning a separate Emacs instance to compile each file,
322# This has the same effect as compile-main. recompile has some advantages: 320# it uses the same Emacs instance to compile everything.
323# i) It is faster (on a single processor), since it only has to start 321# This is faster on a single core, since it avoids the overhead of
324# Emacs once. It was 33% faster on a test with a random 10% of the .el 322# starting Emacs many times (it was 33% faster on a test with a
325# files needing recompilation. 323# random 10% of the .el files needing recompilation).
326# ii) The explicit cc-mode dependency. 324# Unlike compile, this is not parallelizable; so if you have more than
327# recompile's disadvantages are: 325# one core, compile will be (much) faster.
328# i) Not parallelizable. 326# This rule also produces less accurate compilation warnings.
329# ii) Compiling multiple files in the same instance of Emacs is wrong, 327# The environment of later files is affected by definitions in
330# since the environment of later files is affected by definitions in 328# earlier ones, so it does not produce some warnings that it should.
331# earlier ones. 329# It can also produces spurious warnings about "invalid byte code" if
332recompile: doit $(LOADDEFS) compile-first $(lisp)/progmodes/cc-mode.elc 330# files that use byte-compile-dynamic are updated.
331# There is no reason to use this rule unless you only have a single
332# core and CPU time is an issue.
333compile-one-process: doit $(LOADDEFS) compile-first $(lisp)/progmodes/cc-mode.elc
333 $(emacs) $(BYTE_COMPILE_FLAGS) \ 334 $(emacs) $(BYTE_COMPILE_FLAGS) \
334 --eval "(batch-byte-recompile-directory 0)" $(lisp) 335 --eval "(batch-byte-recompile-directory 0)" $(lisp)
335 336