[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"
From: |
Glenn Morris |
Subject: |
bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull" |
Date: |
Wed, 26 Apr 2017 14:32:22 -0400 |
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
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.
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", (continued)
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/12
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/12
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Eli Zaretskii, 2017/04/13
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Ken Raeburn, 2017/04/13
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Paul Eggert, 2017/04/13
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/13
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Eli Zaretskii, 2017/04/14
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/14
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/14
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Eli Zaretskii, 2017/04/15
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull",
Glenn Morris <=
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Paul Eggert, 2017/04/26
- bug#26459: 26.0.50; loaddefs.el is regenerated after each 'git pull', Phillip Lord, 2017/04/26
- bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Glenn Morris, 2017/04/26
bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull", Paul Eggert, 2017/04/12