Closed Bug 487858 Opened 11 years ago Closed 11 years ago

Remove obsolete build options MOZILLA_SECURITY_BUILD and MOZILLA_BSAFE_BUILD

Categories

(NSS :: Build, defect, P3, trivial)

defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.4

People

(Reporter: wtc, Assigned: wtc)

Details

Attachments

(1 file, 1 obsolete file)

While reviewing Elio's patch for bug 486698, I found that
the ancient build options MOZILLA_SECURITY_BUILD and
MOZILLA_BSAFE_BUILD (not used since the NSS 3.1/3.2 release
in year 2000) may confuse new NSS developers like Elio, and
should be removed.

http://mxr.mozilla.org/security/search?string=MOZILLA_SECURITY_BUILD
http://mxr.mozilla.org/security/search?string=MOZILLA_BSAFE_BUILD

I believe the makefile variable CRYPTODIR can also be removed:

http://mxr.mozilla.org/security/search?string=CRYPTODIR
Attached patch Proposed patch (obsolete) — Splinter Review
Remove MOZILLA_SECURITY_BUILD, MOZILLA_BSAFE_BUILD, and CRYPTODIR.
Assignee: nobody → wtc
Status: NEW → ASSIGNED
Priority: -- → P3
Version: unspecified → trunk
Attachment #372113 - Flags: review?(emaldona)
Wan-Teh, I tried applying this patch after mine and had a reject. 
patching file mozilla/security/nss/lib/ssl/config.mk
Hunk #1 FAILED at 69. That's probably because the other patch adds two lines to that file. When I applied it before my patch and it applied without error messages but then I need to adjust my patch. Either you check in yours first and I adjust mine as needed or I check-in mine and you adjust yours as needed. I don't mind adjusting mine to work after yours. Do you have a preference?
On second thought, after trying both orders it looks that it would be easier if I check in first and you adjust your patch afterwards.
Attachment #372113 - Flags: review?(emaldona) → review-
Comment on attachment 372113 [details] [diff] [review]
Proposed patch

This patch will need some slight adjustments once the patch for Bug 486698 is checked in.
Comment on attachment 372113 [details] [diff] [review]
Proposed patch

Elio, you should definitely check in your patch first.
This patch is optional, and I will take care of resolving
the merging conflicts.
My patch is now checked in.
Comment on attachment 372113 [details] [diff] [review]
Proposed patch

Elio, you should not reject a patch because it will
cause merging conflicts with another patch.  Otherwise
our code reviews will need to be serialized.  It is
assumed that whoever checks in late is responsible for
resolving the merging conflicts.

The exception is when two patches modify the same
code.  In that case only one patch should be taken.
But that's not the case here.  Here the two patches
modify neighboring code (but not the same code),
and are in fact independent in spite of the merging
conflicts.

In any case I will create a new patch tonight or
tomorrow.
Attachment #372113 - Attachment is obsolete: true
Attachment #372265 - Flags: review?(emaldona)
Attachment #372265 - Flags: review?(emaldona) → review+
I checked in the patch on the NSS trunk (NSS 3.12.4).

Checking in cmd/platlibs.mk;
/cvsroot/mozilla/security/nss/cmd/platlibs.mk,v  <--  platlibs.mk
new revision: 1.61; previous revision: 1.60
done
Checking in lib/Makefile;
/cvsroot/mozilla/security/nss/lib/Makefile,v  <--  Makefile
new revision: 1.12; previous revision: 1.11
done
Checking in lib/softoken/config.mk;
/cvsroot/mozilla/security/nss/lib/softoken/config.mk,v  <--  config.mk
new revision: 1.27; previous revision: 1.26
done
Checking in lib/softoken/legacydb/config.mk;
/cvsroot/mozilla/security/nss/lib/softoken/legacydb/config.mk,v  <--  config.mk
new revision: 1.10; previous revision: 1.9
done
Checking in lib/ssl/config.mk;
/cvsroot/mozilla/security/nss/lib/ssl/config.mk,v  <--  config.mk
new revision: 1.28; previous revision: 1.27
done
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.12.4
You need to log in before you can comment on or make changes to this bug.