485405 - Use gmake to build NSS, even when using pymake everywhere else

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Benjamin Smedberg]

Attachment: Build NSS with gmake always, rev. 1 [Checkin: Comment 2]

Building NSS with pymake on Windows is almost impossible because it mixes Windows-style paths and Unix-style paths very poorly. So rather than deal with the rats nest, I'm just bailing and building NSS with gmake.

We can revisit later if appropriate.

This also moves make version and flavor checks into the root Makefile instead of putting them in configure.

Comment 1

[(not currently active) Ted Mielczarek]

Comment on attachment 369554 [details] [diff] [review]
Build NSS with gmake always, rev. 1
[Checkin: Comment 2]

I don't really like this patch, but I don't want to block on fixing NSS' build system, either. Can you file a followup on fixing NSS to work properly with pymake?

Comment 2

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/rev/29c9518a29af

Which unfortunately didn't have a bug# in the commit comment. Filed bug 486141 for NSS followup.

Comment 3

[Serge Gautherie (:sgautherie)]

Comment on attachment 369554 [details] [diff] [review]
Build NSS with gmake always, rev. 1
[Checkin: Comment 2]

>diff --git a/configure.in b/configure.in
> dnl Be sure the make we use is GNU make.
> dnl on win32, gmake.exe is the generally the wrong version

It looks like this comment should be removed from this file too.

Comment 4

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1-CC) Remove all these from comm-central

Port it as in bug 513709 ;-)

Comment 5

[Justin Wood (:Callek)]

Comment on attachment 427020 [details] [diff] [review]
(Bv1-CC) Remove all these from comm-central

You're right in that c-c doesn't need the gmake part of this. Put please port the Makefile.in change: (including wrapping in |ifndef .PYMAKE| like the actual checkin did)

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: (Bv2-CC) On comm-central, Copy the useful part of this, Remove the rest [Checkin: Comment 7]

Bv1-CC, with comment 5 suggestion(s).

I thought the m-c check might be enough, but no problem adding it on c-c too.

Comment 7

[Serge Gautherie (:sgautherie)]

Comment on attachment 427058 [details] [diff] [review]
(Bv2-CC) On comm-central, Copy the useful part of this, Remove the rest
[Checkin: Comment 7]


http://hg.mozilla.org/comm-central/rev/ce2c7c200aa9

Comment 8

[Serge Gautherie (:sgautherie)]

Attachment: (Cv1) Remove leftover comment on (1.9.3) m-c [Checkin: Comment 12]

Per comment 3.

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)
> http://hg.mozilla.org/comm-central/rev/ce2c7c200aa9

Bustage worked around in bug 492026.

Comment 10

[Justin Wood (:Callek)]

Comment on attachment 427058 [details] [diff] [review]
(Bv2-CC) On comm-central, Copy the useful part of this, Remove the rest
[Checkin: Comment 7]

(In reply to Bug 492026 comment #14)
> {
> make[2]: MAKE@: Command not found
> make[2]: *** [default] Error 127
> }
> 
> http://hg.mozilla.org/comm-central/rev/b80103b363ea
> (Bv1) configure.in: restore 'AC_PATH_PROGS(MAKE, ...' removed too soon by bug
> 485405.

Hmm actually though the bustage fix you checked in works, its the incorrect fix.

The problem was with this actual patch, (and sorry for not catching the problem).

Just remove the autoconf.in MAKE = @MAKE@ stuff. the error is because the build system expanded $(MAKE) to "@MAKE@" the first @ is interpreted as an "ignore errors on this line" and then it tries to execute a program called "MAKE@" which it doesn't find.

So feel free to backout that changeset along with the removal of MAKE in the autoconf.in with rs=me.

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)

Replied on bug 492026!

Comment 12

[Serge Gautherie (:sgautherie)]

Comment on attachment 427232 [details] [diff] [review]
(Cv1) Remove leftover comment on (1.9.3) m-c
[Checkin: Comment 12]


http://hg.mozilla.org/mozilla-central/rev/ecf773a4b36f