681927 - pymake decides when targets need to be made earlier than gmake

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: test.mk

Consider the attached makefile:

$ make -f test.mk
touch thing3
touch thing1 thing2
if [ -s sentinel ]; then echo TEST-FAIL; fi
echo foo > sentinel
TEST-PASS

$ python -OO ../pymake/make.py -f test.mk
make.py[0]: Entering directory 'c:\dev\test'
c:\dev\test\test.mk:10:0$ touch thing3
c:\dev\test\test.mk:5:0$ touch thing1 thing2
c:\dev\test\test.mk:6:0$ if [ -s sentinel ]; then echo TEST-FAIL; fi
c:\dev\test\test.mk:7:0$ echo foo > sentinel
c:\dev\test\test.mk:5:0$ touch thing1 thing2
c:\dev\test\test.mk:6:0$ if [ -s sentinel ]; then echo TEST-FAIL; fi
TEST-FAIL
c:\dev\test\test.mk:7:0$ echo foo > sentinel
TEST-PASS
make.py[0]: Leaving directory 'c:\dev\test'

It appears that pymake decides that thing1 and thing2 need to be remade, and then remakes them, while gmake decides that thing1 needs to be remade, remakes it, and then considers thing2 and sees that it's up to date.

I prefer pymake's behavior here, because gmake's is in theory racy.  It's not in practice though, from what I can tell in this situation gmake ensures that the Nth line of the recipe is executed for both thing1 and thing2 before executing the N+1th line for either.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> I prefer pymake's behavior here, because gmake's is in theory racy.  It's
> not in practice though, from what I can tell in this situation gmake ensures
> that the Nth line of the recipe is executed for both thing1 and thing2
> before executing the N+1th line for either.

To be clear, make -f test.mk -j2 doesn't cause this test to fail.  It does cause the recipe to be run twice, so it is racy ...

Comment 2

[(not currently active) Ted Mielczarek]

I don't know that this behavior is really specified anywhere in the GNU Make documentation, but the fact that the rule is run twice is expected, AFAICT:
http://www.gnu.org/software/make/manual/make.html#Multiple-Targets

If you have a rule that generates two targets, you should probably just make one a dependency of the other, like:
thing1: thing2
thing2: thing3
	touch thing1 thing2

That way parallel execution will do the right thing.

Comment 3

[Mike Hommey [:glandium]]

That's why such makefiles are actually broken and should be fixed. Not make.

If I remember correctly, I fixed a bunch of makefiles for that some time ago.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Want to fix client.mk? ;-)

Comment 5

[[e-mail]]

Presumably we should make Makefile depend on config.status as it's normally newer?

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Think we've concluded gmake is broken here.