Closed Bug 643167 Opened 10 years ago Closed 9 years ago
Spidermonkey configure should build js-config with MAKE, not GMAKE
creating js-config.h invoking make to create js-config script make.exe: Entering directory `/z/dev/build-rebuild/obj-i686-pc-mingw32/js/src ' config/autoconf.mk:354: *** Windows-style srcdir being used with GNU make. Did y ou mean to run z:/dev/build-rebuild/js/src/build/pymake/make.py instead? [see-al so: https://developer.mozilla.org/en/Gmake_vs._Pymake]. Stop.
Assignee: nobody → khuey
Status: NEW → ASSIGNED
Attachment #520466 - Flags: review?(ted.mielczarek)
Hrm, when I did this originally I used gmake very specifically on purpose. I don't remember why it was necessary, though, so perhaps the reason is moot. Have you tried it with a client.mk-style build?
pbiggar changed this in the mega-patch in bug 605133, but I don't recall why. (He and I went through all the changes together at one point.) It probably has to do with syncing this bit from the top-level makefile: http://hg.mozilla.org/mozilla-central/rev/b1094f628602#l1.601
(In reply to comment #1) > Created attachment 520466 [details] [diff] [review] > Patch The MAKE->GMAKE change was to fix cross-compilation, see bug 605133 comment 22. Best to check that it still works before pushing this.
Boris Zbarsky (:bz) 2010-10-29 14:05:00 PDT This (as determined by local bisect) seems to have broken my ability to build 32-bit shell builds on Mac: js/src/opt-obj-32% rm -rf * && ( cd .. && autoconf213 ) && env CC="gcc-4.2 -arch i386" CXX="g++-4.2 -arch i386" AR=ar CROSS_COMPILE=1 ../configure --enable-optimize --disable-debug --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --enable-shark .... invoking make to create js-config script ../configure: line 16054: js-config: command not found This leads me to believe that MAKE was not set in his environment. Since I'm setting MAKE in client.mk, that shouldn't be a problem. And if we break it I'm sure Boris will let us know ;-)
(In reply to comment #5) > This leads me to believe that MAKE was not set in his environment. Since I'm > setting MAKE in client.mk, that shouldn't be a problem. client.mk is not used for a shell build. > And if we break it I'm sure Boris will let us know ;-) Please test it first. You're reverting a change that was specifically put in to a fix Boris' problem. Checking that you don't regress the problem is surely a requirement for checking this in.
(In reply to comment #6) > (In reply to comment #5) > > This leads me to believe that MAKE was not set in his environment. Since I'm > > setting MAKE in client.mk, that shouldn't be a problem. > > client.mk is not used for a shell build. Ah, that's a good point.
So I think we want to use GMAKE if MAKE is not defined then.
Comment on attachment 520466 [details] [diff] [review] Patch r- till you prove that you're not breaking standalone js builds.
Attachment #520466 - Flags: review?(ted.mielczarek) → review-
9 years ago
Duplicate of this bug: 707511
(Kyle, hope you don't mind me taking). As previous patch, but also sets $MAKE to $GMAKE if it's not defined, so as to avoid Boris' problem with standalone js builds (a la bug 605133 comment 22). Solves the pymake problem in comment 0 / bug 707511 for me locally. Will get Boris to test standalone js builds with this applied before landing. https://tbpl.mozilla.org/?tree=Try&rev=11a0cf64e403
Hardware: x86_64 → All
Version: unspecified → 2.0 Branch
Comment on attachment 578926 [details] [diff] [review] Patch v2 Review of attachment 578926 [details] [diff] [review]: ----------------------------------------------------------------- As long as this doesn't break anyone, fine with me.
Attachment #578926 - Flags: review?(ted.mielczarek) → review+
(bz confirmed this didn't break his js shell builds) https://hg.mozilla.org/integration/mozilla-inbound/rev/758a0ae33484
Target Milestone: --- → mozilla11
Thanks for taking this on.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.