Alexandre Duret-Lutz wrote:
> This code still has a race if one of the followers gets signaled
> after its trap has been set. Then it will erase elc-lock, and
> another follower can create it.
When one of the processes gets a signal, usually all of them get the
signal. So this shouldn't be a big
>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
[...]
Bruno> $(am__ELCFILES): elc-stamp
Bruno> ## Recover from the removal of [EMAIL PROTECTED]
Bruno> ##
Bruno> ! ## Do not call `make elc-stamp' if emacs is not available, because it
would
Bruno> ! ## be useless.
Bruno> @if test "$(EM
>>> "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
On Wed, Mar 16, 2005 at 03:08:06PM +0100, Bruno Haible wrote:
> Alexandre Duret-Lutz wrote:
> > Thanks, I'm installing the following fix on HEAD and branch-1-9.
> > ...
> > -## Recover from the removal of $@
> > - @if test ! -f $@; then \
> > +## Recover from the removal of [EMAIL PROTECTED]
> >
Stepan Kasal wrote:
> > mv -f elc-temp $@
>
> ..
>
> > mv -f elc-temp $@ || { touch $@; rm -f elc-temp; }
>
> But this change is incorrect. It canmcels the whole trick:
>
> touch tmp
> ...
> mv tmp $@
>
> ensures that the stamp file will be older than the files created by
> "
Hi,
On Wed, Mar 16, 2005 at 03:08:06PM +0100, Bruno Haible wrote:
> mv -f elc-temp $@
..
> mv -f elc-temp $@ || { touch $@; rm -f elc-temp; }
But this change is incorrect. It canmcels the whole trick:
touch tmp
...
mv tmp $@
ensures that the stamp file will be olde
Alexandre Duret-Lutz wrote:
> Thanks, I'm installing the following fix on HEAD and branch-1-9.
> ...
> -## Recover from the removal of $@
> - @if test ! -f $@; then \
> +## Recover from the removal of [EMAIL PROTECTED]
> +##
> +## Make sure not to call `make elc-stamp' if emacs is not available
>>> "Greg" == Greg Schafer <[EMAIL PROTECTED]> writes:
Greg> Sure. The output is attached.
Thanks, I'm installing the following fix on HEAD and branch-1-9.
(Perhaps I should update these rules to use AM_CONDITIONAL
before 1.10. I'll look into this later.)
2005-03-16 Alexandre Duret-Lutz <[E
On Tue, Mar 15, 2005 at 09:12:43AM +1100, Greg Schafer wrote:
>
> The issue is still present
Could you show it to us?
Thanks.
On Mon, Mar 14, 2005 at 11:39:28PM +0100, Alexandre Duret-Lutz wrote:
> On Tue, Mar 15, 2005 at 09:12:43AM +1100, Greg Schafer wrote:
> >
> > The issue is still present
>
> Could you show it to us?
Sure. The output is attached.
Regards
Greg
$ make -C gettext-tools/misc -j3
make: Entering direc
On Fri, Feb 25, 2005 at 01:39:50PM +0100, Bruno Haible wrote:
> Greg Schafer wrote:
> > gettext-0.14.2 seems to work well in general, but there is a problem on
> > parallel builds in the `gettext-tools/misc' dir. You should be able to
> > reproduce the problem by running this after configure:
> >
Greg Schafer wrote:
> gettext-0.14.2 seems to work well in general, but there is a problem on
> parallel builds in the `gettext-tools/misc' dir. You should be able to
> reproduce the problem by running this after configure:
>
> make -C gettext-tools/misc -j 3
Thanks for the report. I cannot repr
17 matches
Mail list logo
