Does anybody know what the right solution to this problem is? I'm happy to
implement/test either one, but I don't want to spend my time working on a
solution that won't be accepted upstream.

Tim

On Tue, Nov 22, 2011 at 3:16 PM, Tim Newsome <tnews...@aristanetworks.com>wrote:

> TEST #9 in targets/SECONDARY sometimes fails when two commands execute in
> a different order than expected. As far as I can tell make is doing the
> right thing.
>
> # TEST #9 -- Savannah bug #15919
> # The original fix for this bug caused a new bug, shown here.
>
> touch(qw(1.a 2.a));
>
> run_make_test('
> %.c : %.b ; cp $< $@
> %.b : %.a ; cp $< $@
> all : 1.c 2.c', '-rR -j',
> 'cp 1.a 1.b
> cp 2.a 2.b
> cp 1.b 1.c
> cp 2.b 2.c
> rm 1.b 2.b');
>
> unlink(qw(1.a 2.a 1.c 2.c));
>
> The expected order of cp statements is above, but sometimes I see the
> following:
> cp 1.a 1.b
> cp 2.a 2.b
> cp 2.b 2.c
> cp 1.b 1.c
> rm 1.b 2.b
>
> I can think of two ways to fix this:
> 1. Make 2.c depend on 1.c.
> 2. Change the verification code to accept both orders.
>
> What is the right solution?
>
> Tim
>
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to