* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
@ 2017-04-12 8:54 Eli Zaretskii
2017-04-12 15:58 ` Glenn Morris
2017-04-12 21:37 ` Paul Eggert
0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-12 8:54 UTC (permalink / raw)
To: 26459, eggert
To reproduce:
$ touch .git/logs/HEAD
$ make
and observe loaddefs.el being regenerated for no good reason.
Generation of loaddefs.el is annoyingly slow (takes more than 1 minute
on a fast machine, almost 2 min on fencepost.gnu.org), so running it
on every pull should be avoided.
The reason for this are two rules. One is in src/Makefile.in:
$(lispsource)/loaddefs.el: $(VCSWITNESS) | bootstrap-emacs$(EXEEXT)
$(MAKE) -C ../lisp autoloads EMACS="$(bootstrap_exe)"
This triggers each "git pull" due to $(VCSWITNESS).
The other rule is in lisp/Makefile.in:
autoloads .PHONY: $(lisp)/loaddefs.el
Why should loaddefs.el be treated as a "phony" target? It's a real
file. This was introduced in d703a4d, whose log message says just
this:
* lisp/Makefile.in (PHONY_EXTRAS): New macro.
(.PHONY): Depend on it, and on $(lisp)/loaddefs.el, so that the
relevant files' time stamps are ignored.
That says nothing about the rationale, and I couldn't find any
discussions of the change. Paul, could you please explain why would
it be a bad idea to remove the "phony" status from loaddefs.el?
In GNU Emacs 26.0.50 (build 414, i686-pc-mingw32)
of 2017-04-12 built on HOME-C4E4A596F7
Repository revision: 449bc49c768a4733411c7e05186be7efc163cd7c
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int
--with-modules 'CFLAGS=-O0 -gdwarf-4 -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES
Important settings:
value of $LANG: ENU
locale-coding-system: cp1255
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message puny seq byte-opt subr-x gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)
Memory information:
((conses 16 102469 10783)
(symbols 56 21160 1)
(miscs 48 36 108)
(strings 16 21253 4892)
(string-bytes 1 601609)
(vectors 16 14701)
(vector-slots 8 479332 4573)
(floats 8 50 86)
(intervals 40 267 79)
(buffers 864 11))
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 8:54 bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Eli Zaretskii
@ 2017-04-12 15:58 ` Glenn Morris
2017-04-12 16:03 ` Eli Zaretskii
2017-04-12 21:37 ` Paul Eggert
1 sibling, 1 reply; 19+ messages in thread
From: Glenn Morris @ 2017-04-12 15:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 26459
IIUC 440bafe has made this much slower by defeating the prior "only
update where needed" aspect of this.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 15:58 ` Glenn Morris
@ 2017-04-12 16:03 ` Eli Zaretskii
2017-04-12 16:43 ` Glenn Morris
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-12 16:03 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, 26459
> From: Glenn Morris <rgm@gnu.org>
> Cc: 26459@debbugs.gnu.org, eggert@cs.ucla.edu
> Date: Wed, 12 Apr 2017 11:58:27 -0400
>
>
> IIUC 440bafe has made this much slower by defeating the prior "only
> update where needed" aspect of this.
440bafe made the rule generate the loaddefs in a temporary file.
Would it help to copy loaddefs.el into loaddefs.tmp before running
batch-update-autoloads?
Still, I don't see why the time stamp of loaddefs.el should be
ignored.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 16:03 ` Eli Zaretskii
@ 2017-04-12 16:43 ` Glenn Morris
2017-04-12 18:09 ` Glenn Morris
2017-04-13 7:06 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Glenn Morris @ 2017-04-12 16:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, raeburn, 26459
Eli Zaretskii wrote:
>> IIUC 440bafe has made this much slower by defeating the prior "only
>> update where needed" aspect of this.
>
> 440bafe made the rule generate the loaddefs in a temporary file.
> Would it help to copy loaddefs.el into loaddefs.tmp before running
> batch-update-autoloads?
Probably, together with a move-if-change at the end.
Actually, I think it would be better to make the "write to a tempfile"
aspect internal to Emacs, the same as it is for byte-compile-file.
Then all loaddefs generation would get the benefit.
(I wonder whether it could be pushed to a lower lever still, by giving
write-region an optional "atomic" mode of operation?)
> Still, I don't see why the time stamp of loaddefs.el should be
> ignored.
The Makefile doesn't know the dependencies, so the output timestamp is
meaningless to it. It must defer to Emacs to decide whether the file is
up-to-date.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 16:43 ` Glenn Morris
@ 2017-04-12 18:09 ` Glenn Morris
2017-04-13 7:06 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Glenn Morris @ 2017-04-12 18:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, raeburn, 26459
Glenn Morris wrote:
> Actually, I think it would be better to make the "write to a tempfile"
> aspect internal to Emacs, the same as it is for byte-compile-file.
> Then all loaddefs generation would get the benefit.
Oh, I have a vague memory that maybe autoload generation writes the
output file more than once, in which case that wouldn't work (unless it
was changed not to, which might be good).
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 8:54 bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Eli Zaretskii
2017-04-12 15:58 ` Glenn Morris
@ 2017-04-12 21:37 ` Paul Eggert
2017-04-13 7:09 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Paul Eggert @ 2017-04-12 21:37 UTC (permalink / raw)
To: Eli Zaretskii, 26459
On 04/12/2017 01:54 AM, Eli Zaretskii wrote:
> Paul, could you please explain why would
> it be a bad idea to remove the "phony" status from loaddefs.el?
That would cause loaddefs.el to not be generated sometimes when it
should be. loaddefs.el depends not only on $(LOADDEFS) (its explicit
dependencies), but also on all the other *.el files that have an
autoload directive.
I don't see how the problem you mention is one that d703a4d introduced,
as previously loaddefs.el was generated as a side effect of the
'autoloads' rule, which was already phony.
That being said, we could do a better job of dependency checking here,
so that loaddefs.el is not built so often. I'll see if I can think of
something.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 16:43 ` Glenn Morris
2017-04-12 18:09 ` Glenn Morris
@ 2017-04-13 7:06 ` Eli Zaretskii
2017-04-13 9:03 ` Ken Raeburn
2017-04-13 22:44 ` Paul Eggert
1 sibling, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-13 7:06 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, raeburn, 26459-done
> From: Glenn Morris <rgm@gnu.org>
> Cc: 26459@debbugs.gnu.org, eggert@cs.ucla.edu, raeburn@raeburn.org
> Date: Wed, 12 Apr 2017 12:43:01 -0400
>
> Eli Zaretskii wrote:
>
> >> IIUC 440bafe has made this much slower by defeating the prior "only
> >> update where needed" aspect of this.
> >
> > 440bafe made the rule generate the loaddefs in a temporary file.
> > Would it help to copy loaddefs.el into loaddefs.tmp before running
> > batch-update-autoloads?
>
> Probably, together with a move-if-change at the end.
Done in 88e0125. Generating loaddefs.el is fast again ;-)
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-12 21:37 ` Paul Eggert
@ 2017-04-13 7:09 ` Eli Zaretskii
0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-13 7:09 UTC (permalink / raw)
To: Paul Eggert; +Cc: 26459
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 12 Apr 2017 14:37:50 -0700
>
> On 04/12/2017 01:54 AM, Eli Zaretskii wrote:
> > Paul, could you please explain why would
> > it be a bad idea to remove the "phony" status from loaddefs.el?
>
> That would cause loaddefs.el to not be generated sometimes when it
> should be. loaddefs.el depends not only on $(LOADDEFS) (its explicit
> dependencies), but also on all the other *.el files that have an
> autoload directive.
Thanks, I have now added this rationale to the commentary in
Makefile.in.
> I don't see how the problem you mention is one that d703a4d introduced,
> as previously loaddefs.el was generated as a side effect of the
> 'autoloads' rule, which was already phony.
Yes, as Glenn pointed out, the actual culprit was a much later change.
> That being said, we could do a better job of dependency checking here,
> so that loaddefs.el is not built so often. I'll see if I can think of
> something.
Given that batch-update-autoloads already does a good job in picking
up the required changes, I doubt this would be worth your time. But
thanks anyway.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-13 7:06 ` Eli Zaretskii
@ 2017-04-13 9:03 ` Ken Raeburn
2017-04-13 22:44 ` Paul Eggert
1 sibling, 0 replies; 19+ messages in thread
From: Ken Raeburn @ 2017-04-13 9:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 26459-done
On Apr 13, 2017, at 03:06, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Glenn Morris <rgm@gnu.org>
>> Cc: 26459@debbugs.gnu.org, eggert@cs.ucla.edu, raeburn@raeburn.org
>> Date: Wed, 12 Apr 2017 12:43:01 -0400
>>
>> Eli Zaretskii wrote:
>>
>>>> IIUC 440bafe has made this much slower by defeating the prior "only
>>>> update where needed" aspect of this.
>>>
>>> 440bafe made the rule generate the loaddefs in a temporary file.
>>> Would it help to copy loaddefs.el into loaddefs.tmp before running
>>> batch-update-autoloads?
>>
>> Probably, together with a move-if-change at the end.
>
> Done in 88e0125. Generating loaddefs.el is fast again ;-)
I’m sorry about the inconvenience; doing bootstraps so often I didn’t realize non-bootstraps would be affected so.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-13 7:06 ` Eli Zaretskii
2017-04-13 9:03 ` Ken Raeburn
@ 2017-04-13 22:44 ` Paul Eggert
2017-04-14 1:08 ` Glenn Morris
1 sibling, 1 reply; 19+ messages in thread
From: Paul Eggert @ 2017-04-13 22:44 UTC (permalink / raw)
To: Eli Zaretskii, Glenn Morris; +Cc: raeburn, 26459-done
On 04/13/2017 12:06 AM, Eli Zaretskii wrote:
> Generating loaddefs.el is fast again;-)
I'm now experiencing failures like the following with 'make -j5' on my
circa-2012 desktop. They don't always happen so I assume there's a race
somewhere. Although I don't know whether it's caused by the recent
change, some loaddefs.el-related dependencies do seem to be missing, and
perhaps the recent change merely exposed longstanding problems elsewhere.
...
mv -f emacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Nothing to be done for 'compile-first'.
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make -C ../lisp autoloads EMACS="../src/bootstrap-emacs"
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
ELC ../lisp/cus-start.elc
GEN net/tramp-loaddefs.el
ELC ../lisp/faces.elc
ELC ../lisp/emacs-lisp/cl-preloaded.elc
ELC ../lisp/emacs-lisp/cl-generic.elc
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
ELC ../lisp/files.elc
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
ELC ../lisp/frame.elc
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
ELC ../lisp/help.elc
Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede
./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine
./cedet/semantic/decorate ./cedet/semantic/symref
./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc
./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic
./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes
./textmodes ./url ./vc
GEN loaddefs.el
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/admin/unidata'
ELC unidata-gen.elc
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
In create-file-buffer:
files.el:1768:8:Warning: function create-file-buffer used to take 0+
arguments, now takes 1
ELC ../lisp/mwheel.elc
GEN ../../lisp/international/charprop.el
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Entering directory
'/home/eggert/src/gnu/emacs/static-checking/lisp'
ELC ../lisp/replace.elc
ELC ../lisp/scroll-bar.elc
international/uni-bidi.el:0:0: error: file-missing: (Opening input file
No such file or directory
/home/eggert/src/gnu/emacs/static-checking/lisp/international/uni-bidi.el)
make[2]: *** [Makefile:198: loaddefs.el] Error 255
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[1]: *** [Makefile:734: ../lisp/loaddefs.el] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
make[2]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
Writing
/home/eggert/src/gnu/emacs/static-checking/lisp/international/charprop.el...
make[2]: Leaving directory
'/home/eggert/src/gnu/emacs/static-checking/admin/unidata'
make[1]: Leaving directory '/home/eggert/src/gnu/emacs/static-checking/src'
make: *** [Makefile:416: src] Error 2
Compilation exited abnormally with code 2 at Thu Apr 13 15:38:42
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-13 22:44 ` Paul Eggert
@ 2017-04-14 1:08 ` Glenn Morris
2017-04-14 7:21 ` Eli Zaretskii
2017-04-15 1:25 ` Glenn Morris
0 siblings, 2 replies; 19+ messages in thread
From: Glenn Morris @ 2017-04-14 1:08 UTC (permalink / raw)
To: Paul Eggert; +Cc: raeburn, 26459
Paul Eggert wrote:
> international/uni-bidi.el:0:0: error: file-missing: (Opening input
> file No such file or directory
> /home/eggert/src/gnu/emacs/static-checking/lisp/international/uni-bidi.el)
> make[2]: *** [Makefile:198: loaddefs.el] Error 255
At first glance, I don't see how this could be related to recent changes.
By a coincidence, after you posted the above I committed ad128fe,
which I've had sitting around for a while, and which might be related.
IIUC, making lisp's gen-lisp also generate the unidata files (as well as
leim and semantic) ought to fix your issue? In fact, I'm not sure why I
didn't do that - maybe it turns out not to be so straightforward.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-14 1:08 ` Glenn Morris
@ 2017-04-14 7:21 ` Eli Zaretskii
2017-04-14 17:08 ` Glenn Morris
2017-04-15 1:25 ` Glenn Morris
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-14 7:21 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, raeburn, 26459
> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 26459@debbugs.gnu.org, raeburn@raeburn.org
> Date: Thu, 13 Apr 2017 21:08:17 -0400
>
> Paul Eggert wrote:
>
> > international/uni-bidi.el:0:0: error: file-missing: (Opening input
> > file No such file or directory
> > /home/eggert/src/gnu/emacs/static-checking/lisp/international/uni-bidi.el)
> > make[2]: *** [Makefile:198: loaddefs.el] Error 255
>
> At first glance, I don't see how this could be related to recent changes.
Neither do I, FWIW. That recent change just populated loaddefs.tmp
before updating it, that's all. Since nothing else in the build
references loaddefs.tmp, I don't see how it could be related.
> IIUC, making lisp's gen-lisp also generate the unidata files (as well as
> leim and semantic) ought to fix your issue? In fact, I'm not sure why I
> didn't do that - maybe it turns out not to be so straightforward.
I think this is the right direction, but I can only wonder how come
this problem didn't come up before. I'm building with -j6 and -j8 for
a very long time, and never saw such failures, although clearly the
generated unidata files might not yet exist when loaddefs.el is
produced. Is this likely to happen only on slow machines?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-14 7:21 ` Eli Zaretskii
@ 2017-04-14 17:08 ` Glenn Morris
0 siblings, 0 replies; 19+ messages in thread
From: Glenn Morris @ 2017-04-14 17:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, raeburn, 26459
Eli Zaretskii wrote:
> I think this is the right direction, but I can only wonder how come
> this problem didn't come up before. I'm building with -j6 and -j8 for
> a very long time, and never saw such failures, although clearly the
> generated unidata files might not yet exist when loaddefs.el is
> produced. Is this likely to happen only on slow machines?
I was wondering the same thing and could only come up with the same
hypothesis. :)
(I also wondered if this indicates another area where atomic writes
would help.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-14 1:08 ` Glenn Morris
2017-04-14 7:21 ` Eli Zaretskii
@ 2017-04-15 1:25 ` Glenn Morris
2017-04-15 7:30 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Glenn Morris @ 2017-04-15 1:25 UTC (permalink / raw)
To: Paul Eggert; +Cc: 26459
Glenn Morris wrote:
> IIUC, making lisp's gen-lisp also generate the unidata files (as well as
> leim and semantic) ought to fix your issue? In fact, I'm not sure why I
> didn't do that - maybe it turns out not to be so straightforward.
I find the following patch causes my -j8 builds to often hang forever
(prior to 28718c4), because two Emacs processes try to modify eg
uni-name at the same time. I don't know why Make apparently spawns two
jobs at the same time to do the same thing. Possibly because
admin/unidata/Makefile doesn't explicitly list the output uni*.el files,
and calls make in a loop. Maybe we should improve that.
--- i/lisp/Makefile.in
+++ w/lisp/Makefile.in
@@ -347,9 +347,9 @@ compile-clean:
fi \
done
-.PHONY: gen-lisp leim semantic
+.PHONY: gen-lisp leim semantic unidata
-gen-lisp: leim semantic
+gen-lisp: leim semantic unidata
leim:
$(MAKE) -C ../leim all EMACS="$(EMACS)"
@@ -357,6 +357,9 @@ leim:
semantic:
$(MAKE) -C ../admin/grammars all EMACS="$(EMACS:.%=../.%)"
+unidata:
+ $(MAKE) -C ../admin/unidata all EMACS="$(EMACS:.%=../.%)"
+
# Compile all Lisp files, but don't recompile those that are up to
# date. Some .el files don't get compiled because they set the
# local variable no-byte-compile.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-15 1:25 ` Glenn Morris
@ 2017-04-15 7:30 ` Eli Zaretskii
2017-04-26 18:32 ` Glenn Morris
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2017-04-15 7:30 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, 26459
> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 14 Apr 2017 21:25:36 -0400
> Cc: 26459@debbugs.gnu.org
>
> I find the following patch causes my -j8 builds to often hang forever
> (prior to 28718c4), because two Emacs processes try to modify eg
> uni-name at the same time. I don't know why Make apparently spawns two
> jobs at the same time to do the same thing. Possibly because
> admin/unidata/Makefile doesn't explicitly list the output uni*.el files,
> and calls make in a loop. Maybe we should improve that.
Did you try making this new 'unidata' rule be more similar to the
other 2 rules, in src/Makefile.in, which do the same? IOW, instead of
a phony "unidata" target, use one of the targets that those other
rules use, which are real files. Then I hope Make will pay attention
that one such rule is already running, and won't launch another one to
do the same.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-15 7:30 ` Eli Zaretskii
@ 2017-04-26 18:32 ` Glenn Morris
2017-04-26 20:24 ` Paul Eggert
0 siblings, 1 reply; 19+ messages in thread
From: Glenn Morris @ 2017-04-26 18:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 26459
Eli Zaretskii wrote:
>> I find the following patch causes my -j8 builds to often hang forever
>> (prior to 28718c4), because two Emacs processes try to modify eg
>> uni-name at the same time. I don't know why Make apparently spawns two
>> jobs at the same time to do the same thing. Possibly because
>> admin/unidata/Makefile doesn't explicitly list the output uni*.el files,
>> and calls make in a loop. Maybe we should improve that.
>
> Did you try making this new 'unidata' rule be more similar to the
> other 2 rules, in src/Makefile.in, which do the same? IOW, instead of
> a phony "unidata" target, use one of the targets that those other
> rules use, which are real files. Then I hope Make will pay attention
> that one such rule is already running, and won't launch another one to
> do the same.
After more investigation, I believe this is unfixable, given the
limitations of recursive make. The only way to avoid such a race is to
only have one Makefile run a given rule (ie only lisp/Makefile or only
src/Makefile should be running unidata rules). And I can't see how to
remove the uni-* dependencies from src/Makefile (ns-win and
ucs-normalize are the blockers).
But I think (hope) that changes I have committed to unidata-gen.el
recently should mean Paul is less likely to see his particular race.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-26 18:32 ` Glenn Morris
@ 2017-04-26 20:24 ` Paul Eggert
2017-04-26 20:37 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each 'git pull' Phillip Lord
2017-04-26 20:47 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Glenn Morris
0 siblings, 2 replies; 19+ messages in thread
From: Paul Eggert @ 2017-04-26 20:24 UTC (permalink / raw)
To: Glenn Morris, Eli Zaretskii; +Cc: 26459
On 04/26/2017 11:32 AM, Glenn Morris wrote:
> After more investigation, I believe this is unfixable, given the
> limitations of recursive make.
How about if we switch to nonrecursive make? That is, have the top-level
makefile include the subsidiary makefiles, instead of having it run
$(MAKE) for each subsidiary makefile. This would be a major change, but
it has some real advantages, and other projects (e.g., coreutils) have
switched to this approach to good effect.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each 'git pull'
2017-04-26 20:24 ` Paul Eggert
@ 2017-04-26 20:37 ` Phillip Lord
2017-04-26 20:47 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Glenn Morris
1 sibling, 0 replies; 19+ messages in thread
From: Phillip Lord @ 2017-04-26 20:37 UTC (permalink / raw)
To: Paul Eggert; +Cc: 26459
On Wed, April 26, 2017 8:24 pm, Paul Eggert wrote:
> On 04/26/2017 11:32 AM, Glenn Morris wrote:
>
>> After more investigation, I believe this is unfixable, given the
>> limitations of recursive make.
>
> How about if we switch to nonrecursive make? That is, have the top-level
> makefile include the subsidiary makefiles, instead of having it run $(MAKE)
> for each subsidiary makefile. This would be a major change, but it has
> some real advantages, and other projects (e.g., coreutils) have switched
> to this approach to good effect.
That might help simplify some of the strange stuff in the makefiles --
having the Makefile in src call the Makefile in lisp is confusing.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
2017-04-26 20:24 ` Paul Eggert
2017-04-26 20:37 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each 'git pull' Phillip Lord
@ 2017-04-26 20:47 ` Glenn Morris
1 sibling, 0 replies; 19+ messages in thread
From: Glenn Morris @ 2017-04-26 20:47 UTC (permalink / raw)
To: Paul Eggert; +Cc: 26459
Paul Eggert wrote:
> How about if we switch to nonrecursive make?
I think that is a huge change, and best discussed outside this bug report.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-04-26 20:47 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-12 8:54 bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Eli Zaretskii
2017-04-12 15:58 ` Glenn Morris
2017-04-12 16:03 ` Eli Zaretskii
2017-04-12 16:43 ` Glenn Morris
2017-04-12 18:09 ` Glenn Morris
2017-04-13 7:06 ` Eli Zaretskii
2017-04-13 9:03 ` Ken Raeburn
2017-04-13 22:44 ` Paul Eggert
2017-04-14 1:08 ` Glenn Morris
2017-04-14 7:21 ` Eli Zaretskii
2017-04-14 17:08 ` Glenn Morris
2017-04-15 1:25 ` Glenn Morris
2017-04-15 7:30 ` Eli Zaretskii
2017-04-26 18:32 ` Glenn Morris
2017-04-26 20:24 ` Paul Eggert
2017-04-26 20:37 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each 'git pull' Phillip Lord
2017-04-26 20:47 ` bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" Glenn Morris
2017-04-12 21:37 ` Paul Eggert
2017-04-13 7:09 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).