pymake decides when targets need to be made earlier than gmake

RESOLVED INVALID

Status

()

Core
Build Config
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: khuey, Unassigned)

Tracking

8 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 555710 [details]
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.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) 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 ...
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.
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.
Want to fix client.mk? ;-)

Comment 5

6 years ago
Presumably we should make Makefile depend on config.status as it's normally newer?
Think we've concluded gmake is broken here.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.