pymake returns nothing for $< and $^ in some cases

RESOLVED FIXED in mozilla25

Status

Firefox Build System
General
RESOLVED FIXED
6 years ago
2 months ago

People

(Reporter: glandium, Assigned: mshal)

Tracking

Trunk
mozilla25
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Example of a failing Makefile:

FOO = foo.o
BAR = bar.o

$(FOO): %.o: %.c
$(BAR): %.o: %.cpp

$(FOO): a.h

$(FOO) $(BAR):
	echo $<
	echo $^
Also adding a check/unit test to verify functionality when pymake is changed would be helpful going forward.

Run (g)?make and pymake on the test makefile, report values generated by all automatic variables then strcmp the two sets for equality.
Conveniently pymake has a rather thorough testsuite that runs tests in both gmake and pymake:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/pymake/file/9fb06df46292/tests
(Reporter)

Updated

5 years ago
Duplicate of this bug: 867483

Comment 4

5 years ago
Created attachment 744246 [details] [diff] [review]
Merge prerequisites for targets with multiple rules, v1

Assigning to glandium only because he filed the bug.

The pymake tests pass - ship it!

Try at https://tbpl.mozilla.org/?tree=Try&rev=23e4fdc98ae1
Assignee: nobody → gps
Status: NEW → ASSIGNED
Attachment #744246 - Flags: review?(mh+mozilla)
(Reporter)

Comment 6

5 years ago
(In reply to Gregory Szorc [:gps] from comment #5)
> And this broke the build:
> https://tbpl.mozilla.org/php/getParsedLog.
> php?id=22469633&tree=Try&full=1#error0

Dependencies are probably not handled correctly.
(Reporter)

Updated

5 years ago
Attachment #744246 - Flags: review?(mh+mozilla)
(Assignee)

Comment 7

5 years ago
Created attachment 772888 [details] [diff] [review]
Fix $< and $^ for pymake

I can't access the previous tbpl results so I don't know for certain, but the original patch was failing locally for me because $< was being set incorrectly. In gmake, if we have:

baz: baz.in2

baz: baz.in1
     Use $<

Then it treats baz.in1 as the first prereq for $< purposes, even though baz.in2 is technically "first". If the rule with $< has prereqs, it uses the first prereq in the rule itself. However if it has no prereqs, then it will use the first prereq available in any prior rules.

I've updated the patch to match gmake here, and included this in the test case. This builds locally in pymake, and Windows try results are here:

https://tbpl.mozilla.org/?tree=Try&rev=33487368330a

Not sure if the oranges are related or not though.
Assignee: gps → mshal
Attachment #744246 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Blocks: 888016
(Assignee)

Updated

5 years ago
Attachment #772888 - Flags: review?(benjamin)

Updated

5 years ago
Attachment #772888 - Flags: review?(benjamin) → review+

Comment 8

5 years ago
The Try push looks good. Just a JS JIT test failure.

mshal: Thank you very much for fixing this. This bug is likely responsible for a bunch of required clobbers. It also caused much grief as I was implementing non-recursive XPIDL generation. This will make writing nonrecursive make files much easier.

Please don't forget to double land pymake patches into https://hg.mozilla.org/users/bsmedberg_mozilla.com/pymake/
(Assignee)

Comment 9

5 years ago
inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/1ad29e4c3564

Also pushed into the pymake repo.
https://hg.mozilla.org/mozilla-central/rev/1ad29e4c3564
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
(Reporter)

Updated

5 years ago
Blocks: 899868

Updated

2 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.