322618 - Enable RPM build

Status: RESOLVED FIXED

(Directory :: LDAP C SDK, defect)

Description

[Rich Megginson]

We need to be able to produce RPM builds and be able to build using the RPM installed versions of nspr, nss, and svrcore.

Comment 1

[Rich Megginson]

Attachment: list of new files

List of new files

Comment 2

[Rich Megginson]

Attachment: List of modified files

Comment 3

[Rich Megginson]

Attachment: diffs for fix

Comment 4

[Rich Megginson]

Can I get a review, please?

The diffs exclude configure (but include configure.in)

The new files are the .spec file, the mozldap-config file (analogous to nspr-config), and the pkg-config file mozldap.pc, and a couple of .m4 files to help with nss and svrcore building.

With configure, the basic strategy with nspr, nss, and svrcore is to first check to see if the user has explicitly disabled them.  If not, the user can pass in either the base directory for the component (which should have lib and include subdirs) or individual include and lib directories.  If the user has passed in the --with-system-xxx flag, configure will only look for the system versions of those components using xxx-config or pkg-config xxx.  If the user did not specify to use anything, configure will first attempt to find the "in-tree" components and, failing that, will look for the system version of the components.

I had to change the makefiles to be able to change the nspr, nss, and svrcore include and lib locations. 

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

> mozilla/directory/c-sdk/mozldap-config.in

We should not add new foo-config files.  The nspr/nss ones are there for backcompat; we had them ages ago.  We should make the push to pkg-config files instead.

Comment 6

[Mark Smith [:mcs]]

Comment on attachment 207778 [details]
diffs for fix

R.e. the comment you added in mozilla/directory/c-sdk/build.mk:  I agree that there is no reason for the LDAP C SDK to package up NSPR, NSS, etc. any more.  If some vendor needs that, they can easily implement it themselves anyway.

In mozilla/directory/c-sdk/ldap/clients/tools/Makefile.in: does WINNT need $(SVRCORE_LINK) like the other platforms seem to?

I am not very well versed in configure, so those changes are hard for me to review.

Can you attach the contents of the new files also?  cvs diff -N ... ?

Comment 7

[Rich Megginson]

1) Ok.  I will work on removing the nspr, nss, etc. packaging.  I'll probably just open another bug for that work.

2) Yes, Windows will need svrcore too.  I'll add that.

3) The contents of which new files?  You mean, if there is a filename.in which produces filename, you want to see the diffs for filename from its previous version?  Note that the diffs for configure are quite large.

Comment 8

[Rich Megginson]

Attachment: diffs for configure

These are the diffs for configure

Comment 9

[Rich Megginson]

Mark, attached are the diffs for configure - what other files did you want to see?

Comment 10

[Mark Smith [:mcs]]

Sorry... been a busy day.  I was looking for the contents of files such as these:

mozilla/directory/c-sdk/mozldap-config.in
mozilla/directory/c-sdk/mozldap.pc.in
mozilla/directory/c-sdk/mozldap.spec
mozilla/directory/c-sdk/config/autoconf/nss.m4
mozilla/directory/c-sdk/config/autoconf/svrcore.m4

Or did I miss them somewhere?

Comment 11

[Rich Megginson]

Attachment: pkg-config file for mozldap

Comment 12

[Rich Megginson]

Attachment: RPM .spec file for mozldap

Comment 13

[Rich Megginson]

Attachment: autoconf helper for finding NSS paths

Comment 14

[Rich Megginson]

Attachment: autoconf helper for finding Svrcore paths

Comment 15

[Rich Megginson]

Those are all new files.  I have attached them.  I got rid of mozldap-config - caillon says we should not use them anymore, we should use mozldap.pc with pkg-config instead.

Comment 16

[Mark Smith [:mcs]]

Thanks for posting the new files.

In mozilla/directory/c-sdk/mozldap.spec, please replace "U-Mich" with "University of Michigan" (unless that makes the whole thing too long).

Hopefully all of these changes will work if someone builds Thunderbird or the Mozilla Suite using the LDAP C SDK trunk (currently those products still use ldapcsdk_50_client_branch).  Reassigning to you Rich.  If you have a review of the autoconf changes, I say check this in when you feel ready.

Comment 17

[Rich Megginson]

Who is in charge of the branch used by mozilla?  Chris Aillon pointed me to http://lxr.mozilla.org/mozilla/source/configure.in#7440 - from that, it doesn't look as though my changes will break the mozilla build.  But I'd like to find out who is charge of that branch so I can see if I need to port my changes there.

Comment 18

[Mark Smith [:mcs]]

No one person is in charge of ldapcsdk_50_client_branch as far as I know.  Generally changes made on the branch are also checked into the trunk but not the other way around.  So when the client products switch to the trunk some things will likely break temporarily anyway.

Comment 19

[Rich Megginson]

RCS file: /cvsroot/mozilla/directory/c-sdk/README.rpm,v
done
Checking in mozilla/directory/c-sdk/README.rpm;
/cvsroot/mozilla/directory/c-sdk/README.rpm,v  <--  README.rpm
initial revision: 5.1
done
Checking in mozilla/directory/c-sdk/aclocal.m4;
/cvsroot/mozilla/directory/c-sdk/aclocal.m4,v  <--  aclocal.m4
new revision: 5.3; previous revision: 5.2
done
Checking in mozilla/directory/c-sdk/build.mk;
/cvsroot/mozilla/directory/c-sdk/build.mk,v  <--  build.mk
new revision: 5.23; previous revision: 5.22
done
Checking in mozilla/directory/c-sdk/configure;
/cvsroot/mozilla/directory/c-sdk/configure,v  <--  configure
new revision: 5.37; previous revision: 5.36
done
Checking in mozilla/directory/c-sdk/configure.in;
/cvsroot/mozilla/directory/c-sdk/configure.in,v  <--  configure.in
new revision: 5.39; previous revision: 5.38
done
RCS file: /cvsroot/mozilla/directory/c-sdk/mozldap.pc.in,v
done
Checking in mozilla/directory/c-sdk/mozldap.pc.in;
/cvsroot/mozilla/directory/c-sdk/mozldap.pc.in,v  <--  mozldap.pc.in
initial revision: 5.1
done
RCS file: /cvsroot/mozilla/directory/c-sdk/mozldap.spec,v
done
Checking in mozilla/directory/c-sdk/mozldap.spec;
/cvsroot/mozilla/directory/c-sdk/mozldap.spec,v  <--  mozldap.spec
initial revision: 5.1
done
Checking in mozilla/directory/c-sdk/config/HP-UX.mk;
/cvsroot/mozilla/directory/c-sdk/config/HP-UX.mk,v  <--  HP-UX.mk
new revision: 5.4; previous revision: 5.3
done
Checking in mozilla/directory/c-sdk/config/autoconf/nspr.m4;
/cvsroot/mozilla/directory/c-sdk/config/autoconf/nspr.m4,v  <--  nspr.m4
new revision: 5.1; previous revision: 5.0
done
RCS file: /cvsroot/mozilla/directory/c-sdk/config/autoconf/nss.m4,v
done
Checking in mozilla/directory/c-sdk/config/autoconf/nss.m4;
/cvsroot/mozilla/directory/c-sdk/config/autoconf/nss.m4,v  <--  nss.m4
initial revision: 5.1
done
RCS file: /cvsroot/mozilla/directory/c-sdk/config/autoconf/svrcore.m4,v
done
Checking in mozilla/directory/c-sdk/config/autoconf/svrcore.m4;
/cvsroot/mozilla/directory/c-sdk/config/autoconf/svrcore.m4,v  <--  svrcore.m4
initial revision: 5.1
done
Checking in mozilla/directory/c-sdk/ldap/clients/tools/Makefile.in;
/cvsroot/mozilla/directory/c-sdk/ldap/clients/tools/Makefile.in,v  <--  Makefile.in
new revision: 5.10; previous revision: 5.9
done
Checking in mozilla/directory/c-sdk/ldap/libraries/libprldap/Makefile.in;
/cvsroot/mozilla/directory/c-sdk/ldap/libraries/libprldap/Makefile.in,v  <--  Makefile.in
new revision: 5.14; previous revision: 5.13
done
Checking in mozilla/directory/c-sdk/ldap/libraries/libssldap/Makefile.in;
/cvsroot/mozilla/directory/c-sdk/ldap/libraries/libssldap/Makefile.in,v  <--  Makefile.in
new revision: 5.11; previous revision: 5.10
done

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

Mark's comment is correct.  I don't see any particular reason to land the changes you've made on the branch.  The only sorts of changes that I think would really be worth landing both places would be security fixes.  

What we (the mailnews folks) really need to do is cut a new client branch, because the one we're using is very old.  Unfortunately, there's not currently anyone who has the bandwidth to do that work.