Closed Bug 520359 Opened 10 years ago Closed 10 years ago

pymake fails to build Firefox

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(status1.9.2 beta5-fixed)

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta5-fixed

People

(Reporter: Mitch, Assigned: ted)

References

Details

Attachments

(2 files)

Attached patch Patch v1.0Splinter Review
Building Firefox from mozilla-central, using pymake currently fails.

This patch fixes the non-NSPR parts. (Ted did all the work.)
Attachment #404411 - Flags: review?(benjamin)
This patch fixes the NSPR part. (Again, Ted did all the work.)
Comment on attachment 404411 [details] [diff] [review]
Patch v1.0

>diff --git a/config/config.mk b/config/config.mk

> ifeq (,$(filter-out WINCE,$(OS_ARCH)))
> NSINSTALL	= $(CYGWIN_WRAPPER) nsinstall
>-INSTALL     = $(CYGWIN_WRAPPER) nsinstall 
>+INSTALL     = $(CYGWIN_WRAPPER) nsinstall
> endif

Did you mean to use HOST_BIN_SUFFIX here, or why did you change this line at all?
I think I did initially change that, but then reverted it, but I guess I wound up removing some trailing whitespace there.
Attachment #404412 - Flags: review?(wtc)
Comment on attachment 404412 [details] [diff] [review]
Patch v1.0 (Part Deux)

wtc, this is needed to get through a build with pymake, because `pwd` prints an MSYS path, and pymake wants Windows-style paths. $(CURDIR) has been available since GNU Make 3.77.
Blocks: 485412
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Comment on attachment 404412 [details] [diff] [review]
Patch v1.0 (Part Deux)

r=wtc.

This construct is also used in mozilla/security/coreconf/rules.mk:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/rules.mk&rev=1.81&mark=394,400,403,409,413#388
Attachment #404412 - Flags: review?(wtc) → review+
It looks like we're ok there, since they explicitly handle Win32 paths. We could probably simplify that whole block to use $(CURDIR), though.
Attachment #404411 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
Comment on attachment 404412 [details] [diff] [review]
Patch v1.0 (Part Deux)

Landed on NSPR trunk:
Checking in config/rules.mk;
/cvsroot/mozilla/nsprpub/config/rules.mk,v  <--  rules.mk
new revision: 3.73; previous revision: 3.72
done
Pushed the other patch to m-c:
http://hg.mozilla.org/mozilla-central/rev/ccb86dc8e0da

We'll need to get NSPR updated on trunk to pick up the other fix.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I updated NSPR on m-c, so this should all work again:
http://hg.mozilla.org/mozilla-central/rev/d82fe5d73822
Attachment #404411 - Flags: approval1.9.2?
Comment on attachment 404411 [details] [diff] [review]
Patch v1.0

a192=beltzner
Attachment #404411 - Flags: approval1.9.2? → approval1.9.2+
Blocks: C192ConfSync
Flags: in-testsuite-
Target Milestone: --- → mozilla1.9.3a1
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.