GNU bug report logs - #26459
26.0.50; loaddefs.el is regenerated after each "git pull"

Previous Next

Full log

Message #52 received at 26459 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 26459 <at> debbugs.gnu.org
Subject: Re: bug#26459: 26.0.50;
 loaddefs.el is regenerated after each "git pull"
Date: Wed, 26 Apr 2017 14:32:22 -0400

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.