433062 - Implement separate makefile targets for nss-softoken and nss-util

Status: RESOLVED INACTIVE

(NSS :: Build, enhancement)

Description

[Kai Engert (:KaiE:)]

Make it possible to build softoken, without building anything else.

Make it possible to build nss-lib, without building freebl/softoken.


Implement separate makefile targets for nss-softoken and nss-lib.


Should this makefile target live at 
(a)  mozilla/security/nss
or
(b)  mozilla/security/nss/lib
?

I vote for (a).

But this means, we should also have separate makefile targets for other parts, that get built as part of "nss_build_all" when building in security/nss (such as cmd?).


cd mozilla/security/nss
make nss-softoken

=> build everything that's required to produce the softoken library
   (as of today includes util, freebl)


cd mozilla/security/nss
make nss-lib

=> build everything, except softoken


cd mozilla/security/nss
make nss-tools

=> build everything below mozilla/security/nss/cmd


As part of this bug, we should describe how one can build with a separate dist dir.
It has been mentioned that we could leverage variables.
How does this get done exactly?


Building nss-tools might require that libs from both nss-softoken and nss-libs are available.
We need a solution for the following:
- build nss-softoken in nss-libs in separate trees
- somehow merge the results into a single dist area
- make sure that building nss-tools will work, because it can find the merged
  libs from both nss-softoken and nss-libs

Comment 1

[Kai Engert (:KaiE:)]

(In reply to comment #0)
> Make it possible to build softoken, without building anything else.

Please don't take this literally. I mean:
Make it possible to build softoken, and build only the parts of NSS that are absolutely necessary.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This bug is either a prerequisite for, or a duplicate of, bug 360426.
I'm marking this bug as a blocker of bug 360426.
The blockers for that bug should be examined for duplicates.

Comment 3

[glen beasley]

If this bug is completed by Nov17 2008 it will be included in the FIPS2008 validation otherwise it will be dropped for a later release.

Comment 4

[Kai Engert (:KaiE:)]

IMHO, if we want to avoid the nightmares we had in the past, this is a blocker bug.

Comment 5

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 6

[Kai Engert (:KaiE:)]

Attachment: Patch v2

Comment 7

[Kai Engert (:KaiE:)]

I noticed that security/nss/lib/manifest.mn is missing the sqlite directory.

Comment 8

[Kai Engert (:KaiE:)]

Attachment: Patch v4

Comment 9

[Kai Engert (:KaiE:)]

Please ignore the chunks that include "kaiexxx", I require that patch to build locally...

Comment 10

[Kai Engert (:KaiE:)]

Let me describe the patch.

I've attempted to make as few changes as possible, in order to increase the likelihood it will get accepted in time. I didn't want to move files or directories.

There are 4 header files, outside of util/freebl/softoken, that are required to build softoken, they are from cryptohi and pk11wrap.

I've declared a new fips_export target, that allows to install the softoken dependencies into mozilla/dist. I've moved those headers to the new target, and removed them from the old export target.

I've removed directory "lib" from mozilla/security/nss/manifest.mn, because I wasn't sure how much Makefile logic is happening automatically, which I'm not aware of... I wanted to make sure I have control over what makefile targets get executed for each of the subdirectories.

I've introduced two new makefile targets build_lib_softoken and build_lib_rest. Those are sub-targets of nss_build_all.

Target build_lib_rest will not touch util/freebl/softoken.

Should we ever have the need to build a fips-approved-softoken sources with newer rest-of-nss sources, this would allow us to execute the build_lib_softoken on the fips approved snapshot, and produce all deliverables part of that module.

Running build_lib_rest using the new NSS snapshot would not use any of the newer files, that must be used from the older FIPS approved snapshot.

Comment 11

[Kai Engert (:KaiE:)]

Some more characteristics of the above approach:

By default, When building in a single source tree, mixing two NSS snapshots, we'll get the older versions of the 4 dependent header files from cryptohi/pk11wrap.

However, should it be desired, the software controlling the NSS build can run build_lib_softoken, then run the fips_export targets on pk11wrap/cryptohi in the directories from the newer snapshot, overwriting the fips snapshot files.


Also this approach will always give us the libutil from the older fips approved snapshot.

If we want the option to be flexible in the future, we could make that a separate build target, in other words, nss_build_all would call {build_lib_util, build_lib_softoken, build_lib_rest}.

With this alternate approach (not yet implemented, but simple to do), the software controlling the NSS build can choose whether libutil gets built from the old sources, or from the new sources.

Comment 12

[Kai Engert (:KaiE:)]

This approach does not yet solve the problem of strict separation of FIPS approved sources from newer-remainder-of-nss sources. That's tricky, because pk11wrap and cryptohi are defined as outside the FIPS boundary, but on the other hand, they contain header files that softoken depends on.

If we wanted to clean up further, we could move those header files into a separate directory. Should we do that?

Comment 13

[Kai Engert (:KaiE:)]

Attachment: Patch v5

I've decided to implement the second half of comment 11, produce a separate makefile target for lib/util.

I've learned that we have a cyclic dependency.

lib/softoken depends on the code in lib/util, but lib/util requires header files from lib/softoken...!

Please see the patch v5 for the new proposal, introducing two more makefile targets:

- build_fips_exports
    runs export in freebl and softoken, 
    and runs fips_export in cryptohi and pk11wrap

- build_lib_util
  builds util, only
  Requires that build_fips_exports already got executed
  (using an old or a new nss snapshot)

Comment 14

[Kai Engert (:KaiE:)]

Comment on attachment 343652 [details] [diff] [review]
Patch v5

Not sure whether Nelson or Bob should review this, up to you!

Wan-Teh gave some thoughts. He thinks this approached might be a good interim solution. But in the long term, it would be better if softoken/freebl were completely independent of other headers. The required sections from those headers should get moved over to freebl/softoken. However, it were probably best if someone with more experience would do this work.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 343652 [details] [diff] [review]
Patch v5

This bug calls for separate targets for softoken and the rest of NSS.
It does not call for separate targets for FIPS  and non-FIPS softoken.
I do not support such targets.

Comment 16

[Kai Engert (:KaiE:)]

Comment on attachment 343652 [details] [diff] [review]
Patch v5

Nelson, you might have misunderstood the patch, sorry for not being clear.

I think it confused you that I used the term "fips" in the makefile targets. You assumed a different meaning than it is.

I used the term fips for naming build rules that are required for the subset of NSS that gets FIPS approved. Maybe I should have chosen a different name. If you think it is confusing, we could call it "cryptocore" or any other name you find appropriate.

So, when you reread the patch, and you see the term fips in the patch, please think "cryptocore".

The patch introduces the following two targets to build the contents of security/nss/lib:
- build_lib_softoken
- build_lib_rest

Because lib/util is required for both the above targets, I introduced it as a separate, third target.
- build_lib_util

The intention is, if both "softoken" and "rest" are built in a single source tree, having a separate build_lib_util allows to build inside lib/util only once.

Also, when building from two separate source snapshots, but sharing a common "dist" output area, this gives control which of both snapshots shall be used to build lib/util.

I hope the patch more sense now, re-requesting review.

Comment 17

[Kai Engert (:KaiE:)]

(In reply to comment #15)
> This bug calls for separate targets for softoken and the rest of NSS.

The patch does exactly that, and a bit more.


> It does not call for separate targets for FIPS  and non-FIPS softoken.

This is not what the patch does, please see my previous comment.

Comment 18

[Robert Relyea]

Comment on attachment 343652 [details] [diff] [review]
Patch v5

r- For one case: sqlite.

sqlite is required by softoken. You have it built with the rest of NSS. Your build is probably succeeding because you are using the system sqlite, which brings up the other issue. sqlite was not in the manifest because it was conditionally built. There's an environment variable which does not build sqlite if there is a system one available (this includes all mozilla builds, as well as rh builds).

The rest looks OK for now, though I agree with wtc that it would be better to get rid of the FIPS_EXPORT hack. A better match might be just removing the 4 offending header to freebl (hash headers) or softoken (secmod/pk11 headers). Then export them from there. (This works if they don't include other headers outside, which I believe is the case).

bob

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 343652 [details] [diff] [review]
Patch v5

Kai, my objectjion was to the use of the word FIPS to indicate things that may or may not be FIPS validated.  
I want a term that means PKCS#11 modules, whether the objective is to FIPS validate them, or not.

Comment 20

[Kai Engert (:KaiE:)]

Attachment: Patch v7

Comment 21

[Kai Engert (:KaiE:)]

(In reply to comment #18)
> 
> The rest looks OK for now, though I agree with wtc that it would be better to
> get rid of the FIPS_EXPORT hack. A better match might be just removing the 4
> offending header to freebl (hash headers) or softoken (secmod/pk11 headers).
> Then export them from there. (This works if they don't include other headers
> outside, which I believe is the case).

I'll give this optional proposal a quick try.

Comment 22

[Kai Engert (:KaiE:)]

Yes! Moving the 4 header files over to freebl/softoken indeed works, and allows to avoid all changes in coreconf.

Comment 23

[Kai Engert (:KaiE:)]

Attachment: Alternative patch v8 (patch does not list moved files)

In addition to this patch, the following move operation is required:

mv cryptohi/sechash.h freebl/
mv cryptohi/hasht.h freebl/
mv pk11wrap/secmodt.h softoken/
mv pk11wrap/pk11init.h softoken/

This patch is for ease of review.
I'll attach another version of this patch that includes the diff for the move operation.

Comment 24

[Kai Engert (:KaiE:)]

Attachment: Alternative patch v8 (showing the moved files)

Comment 25

[Kai Engert (:KaiE:)]

Should we take patch v7 or patch v8?

Your decision.

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

If you want to move those 4 files on the trunk, I would suggest that you 
use the bugzilla CVS move facility, rather than doing a CVS add and 
committing the tip revision as the new base revision in the new directories.
But that's just a suggestion.

Comment 27

[Kai Engert (:KaiE:)]

(In reply to comment #26)
> If you want to move those 4 files on the trunk, I would suggest that you 
> use the bugzilla CVS move facility, rather than doing a CVS add and 
> committing the tip revision as the new base revision in the new directories.
> But that's just a suggestion.

Sure, we can try to do that, IIUC it involves help from a cvs admin, is that right?

Comment 28

[glen beasley]

kaie while your patch allows for separate building of softoken how will the 
release engineering be able to configure imports of already built 
releases of softoken? 

should we not move softoken and freebl out of the mozilla/security/nss tree? Say to mozilla/security/nsscrypto 

and then have 

mozilla/security/nsscrypto/lib/util
mozilla/security/nsscrypto/lib/freebl
mozilla/security/nsscrypto/lib/softoken
mozilla/security/nsscrypto/cmd/pk11mode
mozilla/security/nsscrypto/cmd/shlibsign
mozilla/security/nsscrypto/tests
mozilla/security/nsscrypto/pkg

then in the nss tree one could choose to build or import and existing
release?

Comment 29

[Kai Engert (:KaiE:)]

I'm afraid answering comment 28 starts a lot more questions and answers, and I would prefer to do things incrementally. If you agree that your additional proposal could be done in a separate step, we might consider to file a separate bug for that additional work.


(In reply to comment #28)
> kaie while your patch allows for separate building of softoken how will the 
> release engineering be able to configure imports of already built 
> releases of softoken? 

I did not attempt to solve this problem in this patch.


> should we not move softoken and freebl out of the mozilla/security/nss tree?
> Say to mozilla/security/nsscrypto 
> 
> and then have 
> 
> mozilla/security/nsscrypto/lib/util
> mozilla/security/nsscrypto/lib/freebl
> mozilla/security/nsscrypto/lib/softoken
> mozilla/security/nsscrypto/cmd/pk11mode
> mozilla/security/nsscrypto/cmd/shlibsign
> mozilla/security/nsscrypto/tests
> mozilla/security/nsscrypto/pkg
> 
> then in the nss tree one could choose to build or import and existing
> release?

Sounds good to me, but this is a more radical change, that I didn't dare to work on (yet).

I think your proposed additional changes could be done on top of the existing patches, in a separate step. (Unless you think the first step doesn't make sense, if we're heading towards your direction.)

While moving the "lib" and "cmd" portions seems rather trivial, I don't know which strategy should be used to split the "tests" and "pkg" directories into separate "security/nsscrypto" and "security/nss" areas. I think I can't help here.

Another detail, even with separating stuff into new subdirectory "security/nsscrypto", binary output would still be placed into mozilla/dist, unless you make more changes to the build rules. Do you consider to make such changes, too? If you don't, does the separate nsscrypto directory still have a benefit?

Comment 30

[Kai Engert (:KaiE:)]

Hmm, I guess the benefit of a completely separate security/nsscrypto area is: Simplifcation when checking out from cvs, and when tagging snapshots.

Comment 31

[Nelson Bolyard (seldom reads bugmail)]

Attachment: how to move RCS files in CVS repository

In reply to comment 27, the attached file explains all about moving/renaming 
RCS files in the CVS repository.

Comment 32

[glen beasley]

(In reply to comment #29)

> > kaie while your patch allows for separate building of softoken how will the 
> > release engineering be able to configure imports of already built 
> > releases of softoken? 
> 
> I did not attempt to solve this problem in this patch.

I agree it could done in another patch after your patch is approved and checked in.

> 
> Another detail, even with separating stuff into new subdirectory
> "security/nsscrypto", binary output would still be placed into mozilla/dist,

NSPR uses the same mozilla/dist output directories. So we do not have new dist subdirectory if we follow the existing build procedures. 

Release engineer would just co security/nsscrypto and build then package the 
release. Then we building NSS can import NSPR NSSCRYPTO release 


the benefit of security/crypto 

follows existing cvs/build/release process as NSPR
Simplification when checking out from cvs, and when tagging snapshots.
Simplification for developers in the future, the code boundary will be clear, and will have less chance of dependencies getting mixed.

Comment 33

[Robert Relyea]

In general like really like patch 8, but there is one thing that does bother me.... the changes to manifest.mn in lib.

Today, once I've built a tree I can go to either security/nss or security/nss/lib and type 'make' or 'make clean ; make' and get a fresh build. The manifest changes will break those. I'm not sure they are strictly needed.

Ideally the knowledge of which directories are softoken, which are NSS should probably be pushed up into that directory (probably as targets in 
security/nss/lib, either Makefile or config.mk).

The latter ideal is getting more involved, so I'd be happy to get patch 8 without the manifest.mn changes.

bob

Comment 34

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 344134 [details] [diff] [review]
Patch v7

I'm trying to understand the *intended* differences between v7 and v8.

a) It appears to me that the BIG difference is that v8 moves some files 
from one directory to another, and moves the entries for those files 
from one manifest.mn to another.  

But some other differences include:

b) v7 defines a bunch of cryptcore_ targets, some of which were defined 
   conditionally. v8 defines only one, namely build_cryptcore_exports.

c) v7 defines DEBUG_kaiexxx and v8 defines DEBUG_kaie.  I suspect this
   difference is unintentional.

Bob likes patch 8, and I'd guess that's because it moves some files into
the softoken and/or freebl directories, rather than complicating the 
makefiles to export some files for softoken from non-softoken/freebl 
directories.  I like that too, and so on that basis, I will give r- to 
v7, so that we can focus on v8.   

If there was a separate patch, that ONLY moved those files and the 
manifest entries for those files, I would give that patch an r+.

I'd like to suggest that you do that, Kai, because I have a number 
of other issues with both the v7 and v8 patches.  
I will write about them in my next comment.

Comment 35

[Kai Engert (:KaiE:)]

(In reply to comment #34)
> (From update of attachment 344134 [details] [diff] [review])
> I'm trying to understand the *intended* differences between v7 and v8.

v7 does not move files

v8 moves files

v7 needs the cryptcore targets, in order to export from cryptohi/pk11wrap

v8 does not need those cryptcore targets, because we're moving files.


> a) It appears to me that the BIG difference is that v8 moves some files 
> from one directory to another, and moves the entries for those files 
> from one manifest.mn to another.  
> 
> But some other differences include:
> 
> b) v7 defines a bunch of cryptcore_ targets, some of which were defined 
>    conditionally. v8 defines only one, namely build_cryptcore_exports.

we still need this single target in order to export headers from freebl and softoken. As I had said before in this bug, building lib/util depends on headers from freebl/softoken.


> c) v7 defines DEBUG_kaiexxx and v8 defines DEBUG_kaie.  I suspect this
>    difference is unintentional.

yes

Comment 36

[Kai Engert (:KaiE:)]

Attachment: Patch v9, move headers and update manifest entries (not fixing this bug)

(In reply to comment #34)
> If there was a separate patch, that ONLY moved those files and the 
> manifest entries for those files, I would give that patch an r+.

This sounds like a reasonable preparation for the other work, so here you are.


(In reply to comment #31)
> In reply to comment 27, the attached file explains all about moving/renaming 
> RCS files in the CVS repository.

This sounds like a non-trivial administration task that must be done with quite some diligence, I'd be grateful if I could avoid doing this myself and rather focus on engineering work, maybe someone else could help getting this done? (I'd personally be happy to have a pointer to the old files in the header of the new files, and point people to cvs history of those old files). (FYI, hg makes moving files trivial, while keeping history)

Comment 37

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 344139 [details] [diff] [review]
Alternative patch v8 (patch does not list moved files)

Both patches v7 and v8 move all the knowledge about the subdirs of nss/lib 
into the makefile for nss.  I object to that.  This is essentially the 
same issue that Bob expressed, losing the ability to do a make (of any 
and all targets) in lib.  It's not necessary.  The knowledge of those 
DIRS needs to go back into nss/lib.

They also have the effect that it is no longer possible to check out just 
a few of the directories under nss/lib and then do a gmake libs to build 
just those directories.  All the directories must now be present and have 
Makefiles, or the make steps will fail.  The old scheme, which used 
$(LOOP_OVER_DIRS) had the property that if any of the DIRS were missing, 
make simply skipped them.  It didn't error out.  

This patch changes the behavior of the clean, export, libs and all targets.
It makes it impossible to make the "libs" target without also building 
the "export" target.  

I think the requirements for this bug are to make it POSSIBLE to build
softoken separately from the rest of NSS< but not to make it REQUIRED.
The patch should make it possible to continue to build the same targets
we've always had, with the same results.  It should add NEW ways to build
new combinations of things, without lessening what we had before.  

I think we can and should keep the elegance and flexibility (and 
maintainability) of the LOOP_OVER_DIRS macro in the makefiles in both 
nss and nss/lib.

Comment 38

[Kai Engert (:KaiE:)]

Nelson, as you are objecting the current approach, do you have a constructive proposal on how to fix this bug and still achieve your requirements? Did you think about Glen's proposal to move all util/freebl/softoken related code to a new separate security/nsscrypto directory?

I think I might have to stop my attempt now. I thought fixing this bug would be a low hanging fruit, but I'm learning, it's not.

Comment 39

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 36, 
Kai, Moving the CVS repository files for the 4 source files is as simple as 
writing a tiny text file, known as a "copy script" containing 4 lines of text, 
one line for each file to be moved, attaching it to this bug and seeking a 
review.   Then you file a new bug  against product "mozilla.org", component 
"CVS: Copy" requesting the copies, with a comment pointing to the already 
reviewed copy script. Then when the copy is done, you commit the other 
changes and do the cvs remove of the old copies on the trunk. 

Total time to do that, should be an hour or less, excluding the time while
that new bug waits to be done by mozilla.org operations staff.

Comment 40

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 344371 [details] [diff] [review]
Patch v9, move headers and update manifest entries (not fixing this bug)

(Sorry, I thought I gave this r+ with my last comment.)
r+, with the understanding that the files to be moved will be moved with Mozilla's cvs file moving facility, described in a previous attachment.

Comment 41

[Julien Pierre]

How do you address the problem that lib/ssl depends on the freebl loader ?

Even with two separate targets for NSS and softoken, it will not be the case that any version of softoken built separately will build with any version of NSS. You will have to match it carefully with an NSS build whose libssl shares the same loader, or a sufficiently similar one. In particular it needs to try to load the same freebl library names. Otherwise, the SSL PKCS#11 bypass will be broken in libssl.

Comment 42

[glen beasley]

Attachment: patch v10 update manifest and delete old headers

the files to be moved were moved with mozilla's cvs file moving facility, by bug 463344. 
This patch completes the move by cvs removing the old files. 
The old pk11wrap/secmodt.h was updated by bug 453234 and I have updated the new softoken/secmodt.h version. 
This patch also removes the unnecessary include of nss.h from pkcs11.c

Comment 43

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 353497 [details] [diff] [review]
patch v10 update manifest and delete old headers

r=nelson

Comment 44

[glen beasley]

/cvsroot/mozilla/security/nss/lib/cryptohi/hasht.h,v  <--  hasht.h
new revision: delete; previous revision: 1.7
done
Checking in lib/cryptohi/manifest.mn;
/cvsroot/mozilla/security/nss/lib/cryptohi/manifest.mn,v  <--  manifest.mn
new revision: 1.7; previous revision: 1.6
done
Removing lib/cryptohi/sechash.h;
/cvsroot/mozilla/security/nss/lib/cryptohi/sechash.h,v  <--  sechash.h
new revision: delete; previous revision: 1.8
done
Checking in lib/freebl/manifest.mn;
/cvsroot/mozilla/security/nss/lib/freebl/manifest.mn,v  <--  manifest.mn
new revision: 1.55; previous revision: 1.54
done
Checking in lib/pk11wrap/manifest.mn;
/cvsroot/mozilla/security/nss/lib/pk11wrap/manifest.mn,v  <--  manifest.mn
new revision: 1.21; previous revision: 1.20
done
Removing lib/pk11wrap/pk11init.h;
/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11init.h,v  <--  pk11init.h
new revision: delete; previous revision: 1.6
done
Removing lib/pk11wrap/secmodt.h;
/cvsroot/mozilla/security/nss/lib/pk11wrap/secmodt.h,v  <--  secmodt.h
new revision: delete; previous revision: 1.39
done
Checking in lib/softoken/manifest.mn;
/cvsroot/mozilla/security/nss/lib/softoken/manifest.mn,v  <--  manifest.mn
new revision: 1.35; previous revision: 1.34
done
Checking in lib/softoken/pkcs11.c;
/cvsroot/mozilla/security/nss/lib/softoken/pkcs11.c,v  <--  pkcs11.c
new revision: 1.157; previous revision: 1.156
done
Checking in lib/softoken/secmodt.h;
/cvsroot/mozilla/security/nss/lib/softoken/secmodt.h,v  <--  secmodt.h
new revision: 1.39; previous revision: 1.38
done

Comment 45

[glen beasley]

Attachment: patch v11. hasht.h and sechash.h need to be public headers

I incorrectly made hasht.h and sechash.h private 

the original cryptohi manifest.mn file:

RCS file: /cvsroot/mozilla/security/nss/lib/cryptohi/manifest.mn,v
retrieving revision 1.6
diff -4 -d -u -p -r1.6 manifest.mn
--- lib/cryptohi/manifest.mn	15 Aug 2007 15:29:53 -0000	1.6
+++ lib/cryptohi/manifest.mn	17 Dec 2008 19:45:00 -0000
@@ -44,14 +44,12 @@ LIBRARY_NAME = cryptohi
 
 EXPORTS = \
 	cryptohi.h \
 	cryptoht.h \
-	hasht.h   \
 	key.h     \
 	keyhi.h   \
 	keyt.h    \
 	keythi.h  \
-	sechash.h \
 	$(NULL)

Comment 46

[glen beasley]

Attachment: shell script to allow checkout and building of libfreebl, libsoftoken, shlibsign, and pk11mode

shell script to demostrate checkout and building of NSPR, libfreebl, libsoftoken, shlibsign, and pk11mode 

we could choose to create a cvs module which would allow for 
cvs co NSPR 
cvs co SOFTOKEN

but is this necessary? Release engineering could just do the correct check out.

While this script shows how to build only libfreebl/libsoftoken I am not sure on the best way for a full nss co as in "cvs co NSS" and then have a way that the build import older libfreebl/libsoftoken.

My guess is release engineering would co all of NSS out except libfreebl/libsoftoken then specify an gmake import of libfreebl/softoken 
then build. I believe that could work with out much work.

Comment 47

[Christophe Ravel]

(In reply to comment #46)
> cvs co SOFTOKEN
> but is this necessary? Release engineering could just do the correct check out.

I think it is. Doing the following is definitely not fool proof (if you add
tags for example) and is not maintenance free:
cvs co mozilla/dbm mozilla/security/dbm mozilla/security/coreconf
cvs co -l mozilla/security/nss
cvs co -l mozilla/security/nss/lib
cvs co mozilla/security/nss/lib/util
cvs co mozilla/security/nss/lib/freebl
cvs co mozilla/security/nss/lib/softoken
cvs co -l mozilla/security/nss/cmd
cvs co mozilla/security/nss/cmd/pk11mode
cvs co mozilla/security/nss/cmd/shlibsign


> My guess is release engineering would co all of NSS out except
> libfreebl/libsoftoken then specify an gmake import of libfreebl/softoken 
> then build. I believe that could work with out much work.

How do you suggest that we do that? I don't know of any easy way to do that.
Listing each individual directory is going to be a real pain to maintain.

Comment 48

[Elio Maldonado]

The other two bugs that this one blocks (360426 and 426266) have been closed and resolved inactive. Perhaps this one should be closed as well.

Comment 49

[J.C. Jones [:jcj] (he/him)]

Yeah, thank you for the ping.