>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Ok, what about this (untested) patch?
I'll do something like that. The "recover" idiom is not only
used here, and there are all those trap/exit portability issues
to handle. I just don't have the time for this now :(
--
Alexandre
Alexandre Duret-Lutz wrote:
> a fix for this belongs to the rule that starts those multiple `$(MAKE)
> elc-stamp' processes, not to the elc-stamp rule. IOW locks are
> not needed in regular builds, they would only be needed to
> prevent multiple *recover* rules to start `$(MAKE) elc-stamp'.
Ok, w
>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> So it must mean: "If the user has removed *.elc but elc-stamp is still
Bruno> there, then remake elc-stamp." This scenario can still occur, and will
Bruno> still lead to multiple parallel processes [except if only one .elc file
Bru
Alexandre Duret-Lutz wrote:
> Make starts only one command per target, and wait for this
> target to be completed before building any other dependent
> targets.
>
> The only way to have the same target built several times is to
> explicitly start separate make processes yourself. (That was
> what
>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Your modification does not fix this, because
Bruno> - It didn't change the dependencies of this rule, or the rules which
Bruno> depend on this one. Therefore this rule can still be started by two
Bruno> parallel processes.
Bruno>
Alexandre Duret-Lutz wrote:
> > What happened was: In the rules
> >
> > elc-stamp: $(LISP)
> > @rm -f elc-temp && touch elc-temp
> > ...
> > @mv -f elc-temp $@
> >
> > 3 independent 'make' processes started working on this rule.
>
> It seems you are trying to allow this, bu
