15727 - NSPR environment not determined if using external NSPR

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect, P3)

Description

[Greg Noel, Unix Guru]

If the build is not using NSPR in the source tree (which is awful, so I copy it
elsewhere and compile there), the NSPR options determined during the build are
not calculated, so they are not saved in build/unix/nspr_my_*.mk.  This means
that I can't verify that the options that Mozilla expects are the same as the
ones I'm using.

The attached patch simply eliminates the test that suppresses the calculation of
the NSRP environment values.  With the values calculated, the values are inserted
in build/unix/nspr_my_*.mk.

Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.506
diff -c -r1.506 configure.in
*** configure.in	1999/10/02 00:02:35	1.506
--- configure.in	1999/10/02 22:39:35
***************
*** 3134,3141 ****
  dnl = DIST
  dnl =
  dnl ========================================================
- if test ! "$MOZ_NATIVE_NSPR"
- then
  dnl
  dnl USE_PTHREADS
  dnl
--- 3134,3139 ----
***************
*** 3246,3252 ****
  AC_SUBST(MOZ_NSPRENV_CLASSIC_NSPR)
  AC_SUBST(MOZ_NSPRENV_DIST)
  AC_SUBST(MOZ_NSPRENV_OVERRIDE_MAKE)
- fi
  dnl ========================================================


--- 3244,3249 ----

Comment 1

[cls]

Adding a dependency for 11893 because once autoconf for NSPR lands, this entire
section will be removed.
I don't quite understand the need for this patch as the options you use with an
external NSPR do not have to match the ones that would have been detected for a
in-tree NSPR.  Say if you build the external NSPR w/o pthreads, but mozilla
detects pthreads on your system, then you will have set nspr*.mk to assume that
you are using pthreads when you are not. (Ignoring the fact that the current
logic in configure.in is wrong anyways.)

Comment 2

[Greg Noel, Unix Guru]

This only removes the test where the NSPR environment variables are _calculated_,
not where the constructed files are copied over to the NSPR directories.  That
later test remains, so the files in build/unix represent what configure would
have used.

Right now, the files in build/unix are created, but all the values are empty.
I'd like the files to have values in them so I can compare them against the files
I use when compiling NSPR.

I've been waiting for the autoconf changes to NSPR with bated breath; it's
irritating to go to all this trouble because it has to be built in the source
tree.  I have a script that copies the sources to a scratch area and compiles
them there, but it'd be better if it just worked like all the rest of it.

Comment 3

[Jon Granrose]

accept bug.

Comment 4

[Jon Granrose]

mass move to M14.

Comment 5

[Jon Granrose]

Is this still an issue now that we're pulling NSPR from a static tag?

Comment 6

[Daniel (Leaf) Nunes]

Pulling by tag doesn't affect this issue. Chris, is nspr-with-autoconf working
now?

Comment 7

[cls]

I build with it daily under Linux and I had a tinderbox (twain) going for awhile
under solaris/x86.  We should probably verify that it works on all of our
non-tier 1 platforms though before we turn it on by default.
Marking this as won't fix as the default values calculated by Mozilla have no
bearing on how an external NSPR module was built.