297091 - Provide a way for mozilla to build more nss tools

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, enhancement)

Description

[timeless]

this code is from Cenzic Hailstorm 2.0-2.6

We'd like to check this (or something like it) in controlled by a configure flag

(newuser doesn't build, so we explicitly remove it from the list of things we
try to build)

Comment 1

[timeless]

Attachment: changes against mozilla1.8a5

Comment 2

[Wan-Teh Chang]

If you want to build NSS command-line tools, you
should do a standalone NSS build.

mozilla/security/manager/Makefile.in is designed
to build only the subset of NSS Mozilla clients
need.

mozilla/security/nss/cmd/swfort/newuser should build.
(By the way, we plan to remove the "swfort" directory
in a future NSS release.)

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 185685 [details] [diff] [review]
changes against mozilla1.8a5

NSS has two sets of Makefiles: 
1. one set used by everyone but the moz/ff/tb developers and builders.
   This set is tightly controlled by the NSS development team.
   The files manifest.mn, Makefile, and *.mk are all part of this set.

2. A set used by moz/ff/tb developers/builders (makefile.in).
   IMO, this set is essentially controlled by moz/ff/tb developers,
   and they should define its behavior and review changes to it.

The NSS team's Makefiles build a product that has shared libs and
QA programs and utility programs that are released as a set.  
The definition of that set cannot be changed simply because some
builder of moz has had trouble building part of it.  

So, I give this patch r- for the change to a manifest.mn file that
removes one of the utility programs from NSS product builds.  

It appears to me that the proposed patch would build ALL the NSS QA and
utility programs for all developers and builders of mozilla.org client
products (moz/ff/tb).  I would think such a change would need to be 
approved by the usual mozilla.org drivers, and I'd be surprised if they
wanted that.  So let me suggest that, rather than building all of 
nss/cmd, you add lines to makefiles.in to build the few commands you 
think most developers/builders need.  Then get drivers to review that
change.

Comment 4

[Doug Turner (:dougt)]

I would like to have the NSS tools built when we build mozilla -- even if I had
to specify a special ac_add_options to mozilla's configuration.  Such a change
wouldn't matter to the applications since these tools don't have to be shipped.
 And as it is today, we pick stuff out of our dist/bin directory.  Since these
tools aren't in our manifest, they will not be seen by the install packager.

However, a downside to this change would slow down our tinderboxes by some small
amount.

Comment 5

[Julien Pierre]

I would like to note also that the NSS tools may not build, even less run, on
all platforms. For example, libssl has some code conditionally compiled for the
server side cache, and selfserv will not work properly without it.

Years ago, I had to make a lot of changes to nss/cmd to make nss/cmd build and
run on OS/2. It turns out only the portion of the NSS libraries required by the
mozilla browser had been ported, and there was a lot of work left after that.

I'm not sure which platforms will actually fail the nss/cmd build or NSS QA at
this point, but anything not officially built by RedHat or Sun is potentially at
risk. So watch out before enabling this option in mozilla tinderboxes.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

The NSS tools build and run on all supported platforms (which we formerly
called tier 1).  We never supported SSL servers on MacOS before OS/X. 
Probably don't on AmigaDos either.  :)

It's pretty clear to me that the mozilla client folks don't want to build 
every NSS test program, but rather want to build certain utility programs.
Let me suggest that they start by producing a list of the utility programs
they want, then simply add lines to make them to makefile.in, as is now done 
for the shlibsign utility.  If any of those tools don't build on some 
platform, bugs can be filed.  

Comment 7

[timeless]

seems like a waste, the only thing that didn't build for me is the one i removed from the manifest. -- one that was eventually *removed* from cvs as wtc noted would happen in comment 2.

i'd like to spend one minute to get on a soap box and thank everyone for the fast and expeditious pace at which this patch made it into cvs. it's only a year old and had a very simple goal, seems to have reasonable support from the gecko community. i see no indication anywhere of the gecko community indicating that they don't want to build test apps, there's actually a flag available --disable-tests, so anything that's a test could certainly be guarded by that.

i'd like to repeat that no one from mozilla (and especially dougt) indicated any objection to building all of the tools (precisely what this patch does). relatively speaking nss is trivial in size and space, and anything we don't ship doesn't influence anything. so that's a bad straw man which was explicitly beaten down.

now supposing i do get some poor person to waste time writing the patch you proposed (which will be dozens of lines long, and very awkward) and then you do remove something else as you did for swfort, will you update the mozilla makefile, or will it just break?

given that newuser is part of swfort which was removed, there's no build error that i know of that will happen when all of the tools are built. but it now seems like a huge waste of time that i was expected to get a build error for newuser, just because my patch removed one piece which wtc noted was going away anyway. afaik that's the only reason that the patch i wrote was rejected, and that seems amazingly stupid. why did you care if we stopped building something a bit sooner that you were planning to and did remove all of shortly.

sorry. i just had a terrible 30mins of a saturday night [lasting the following 5hrs in the morning] coming off a bad end of the week coming off a note particularly good month. but this is stupid. oh, and i don't have time to waste on it, so i'm just going to rant, because i already posted a patch, and none of the objections you people posted are relevant. i don't really mean any disrespect, you're all nice, and i appreciate the work you do on the project, but this is really frustrating.

all i'm doing atm is reviewing the list of all the lost nss bugs, and this is among that large list. your module [nss:build] does not seem to be well maintained (which doesn't make it special by any means).

note that the patch here is perfectly satisfactory as is (since the one file that it's patching, that hunk will be discarded) and should therefor be reviewable and satisfactory to everyone's tastes.

and as for vinegar and honey. i don't care because i'm not going to be using nss at all, so this nss:build triaging is charity work.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

You're right.  I never should have reviewed this patch at all.
This is not an NSS bug.
mozilla/security/manager/Makefile.in is not part of NSS.
This bug should have been reassigned to the proper product (whatever that is) 
back when I wrote comment #3.  

Comment 9

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 10

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Currently some NSS tools are built when building mozilla-central. If more need to be built, we can handle that on a case-by-case basis in new bugs.