bug#26459: 26.0.50; loaddefs.el is regenerated after each "git pull"

[Glenn Morris <rgm@gnu.org>]

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.