Created attachment 138468 [details]
Top-level Automake Makefile

This is the new top-level Automake Makefile.  The new build system will only
use this one makefile instead of doing a recursive make.

Created attachment 138469 [details]
configure.ac script

This is the new configure.ac script.  I am not going to attach the generated
configure script as it will be huge and unreadable.

Created attachment 138470 [details]
Berkeley DB m4 file

This is the m4 file for locating Berkeley DB.  This and other m4 files will be
placed in the "ldapserver/m4" directory in the source tree.

Created attachment 138471 [details]
ICU m4 file

This is the m4 file for locating ICU.

Created attachment 138472 [details]
Mozldap m4 file

This is the m4 file for locating Mozldap.

Created attachment 138473 [details]
Net-SNMP m4 file

This is the m4 file for locating Net-SNMP.

Created attachment 138474 [details]
NSPR m4 file

This is the m4 file for locating NSPR.

Created attachment 138475 [details]
NSS m4 file

This is the m4 file for locating NSS.

Created attachment 138476 [details]
Cyrus-SASL m4 file

This is the m4 file for locating Cyrus-SASL.

Created attachment 138477 [details]
Svrcore m4 file

This is the m4 file for locating Svrcore.

Created attachment 138478 [details]
CVS Diffs

These changes are needed for the new build system to work.  The changes are:

- Modify buildnum.pl to just return the build number if the platform argument 
  is not supplied.  The new build system generated the build number at
configure
  time and puts it in the generated Makefile instead of a buildnum.dat file.

- The include line for ldap-agent.h was formatted for a system header file,
  would cause the new build system to not locate it when compiling the SNMP
  subagent.

The above attachments comprise the first phase of implementing the new build
system.  There are a number of files generated by autoconf that will need to be
checked in as well, but they are all generated from the above attachments.

The second phase will need to clean up some of the conditional defines as well
as add configure options for things like an optimized build and 64-bit.  All of
this is possible with the current implementation by using CFLAGS, CXXFLAGS, etc.

Re: comment #1 - looks good.  Some minor points
ns-slapd.properties is a bin_PROGRAM?  I think it should be a nodist_DATA or
something like that.
I think we should just get rid of keyupg and liblitekey.  And do we still need
libldif?  Can't we just use mozldap?
The sources for some of the libraries include the sources for libavl, libldif,
etc. Is that necessary?  Shouldn't we just build/link the lib/prog that uses
them with -lavl etc.?

re: comment#2 - looks good.  We'll have to make the platform_defs for hpux
figure out if using parisc or ipf.

Your new autotool files/scripts look good.
One question and one request:
I guess it would be independent from the autotoolize itself, but how the
branding script is run with this new way of building?
A favor I'd like to ask you...  When all the job is done, could you write down
Howto 1) add/delete a source file to the server, 2) add/delete linking a
component, 3) add a new plugin?  It'd be a great help not just for me, but for
the community. ;)

(In reply to comment #13)
> ns-slapd.properties is a bin_PROGRAM?  I think it should be a nodist_DATA or
> something like that.

It probably shouldn't be a bin_PROGRAM, but we do distribute the properties file
in "bin/slapd/property", so it's not a nodist.

> I think we should just get rid of keyupg and liblitekey.  And do we still need
> libldif?  Can't we just use mozldap?

It's possible that we can use mozldap instead, but I tried not to change the way
things are built for the first phase too much.  We need to look into this for
phase 2.

> The sources for some of the libraries include the sources for libavl, libldif,
> etc. Is that necessary?  Shouldn't we just build/link the lib/prog that uses
> them with -lavl etc.?

Libtool warns that linking static libraries to shared libraries is not portable,
and it in fact doesn't link them on HP-UX.  We could make them shared libraries
instead if that seems to be a better approach.

For the m4 file for db, we should try to figure out where db4.2 is on the
system, if the user doesn't specify --with-db or if they specify --with-db
(which is passed as --with-db=yes to configure).  For example, on RHEL4, it
should just work if you omit --with-db - it should find -ldb-4.2 in the default
lib path, and db.h in the default include path.

icu looks good

mozldap looks good

net-snmp looks good

for nspr and nss, we might want to look for dirsec-nspr and dirsec-nss in
pkg-config if nspr or nss is not found.  This will make it easier to support
RHEL4 and other platforms where we have to use the dirsec-nspr and dirsec-nss.

sasl looks good

svrcore looks good

One thing we can use is AC_CHECK_LIB/FUNC and the related macros.  This will
attempt to do a compile/link.  This is the usual way to see if a particular
library is in the default link path and contains some symbol you're interested
in.  We use this in the mozldap sasl.m4 to find libsasl2.

(In reply to comment #14)
> re: comment#2 - looks good.  We'll have to make the platform_defs for hpux
> figure out if using parisc or ipf.
> 

The $host variable contains the cpu arch in configure.ac, so this will be pretty
easy to do.

(In reply to comment #16)
>> ns-slapd.properties is a bin_PROGRAM?  I think it should be a nodist_DATA or
>> something like that.

> It probably shouldn't be a bin_PROGRAM, but we do distribute the properties file
> in "bin/slapd/property", so it's not a nodist.

In autotool-speak, the dist_ prefix means source distribution - it denotes files
which you want to be included in the source distribution.  I think all sources
mentioned in the Makefile are distributed by default unless you mark them as
nodist_.  The inst_ prefix is used to denote files which are to be installed. 
By default, files mentioned in targets such as bin_, lib_ etc. are installed in
those locations (e.g. bin == /usr/bin, lib == /usr/lib).  Using noinst_ means
not to install those files.

> It's possible that we can use mozldap instead, but I tried not to change the way
> things are built for the first phase too much.  We need to look into this for
phase 2.

Ok.

>> The sources for some of the libraries include the sources for libavl, libldif,
>> etc. Is that necessary?  Shouldn't we just build/link the lib/prog that uses
>> them with -lavl etc.?

> Libtool warns that linking static libraries to shared libraries is not portable,
> and it in fact doesn't link them on HP-UX.  We could make them shared libraries
> instead if that seems to be a better approach.

Hmm - ok.  Linking a static library is exactly the same as including those .o
files in the shared library/program, so I guess what you have is ok.  Linking a
static lib into a shared lib should be portable - I wonder why it isn't?  Just
leave it as is for now.

Created attachment 138631 [details]
New configure.ac script

This new version of configure.ac addresses the HP-UX cpu architecture issue
raised in comment #14.

Created attachment 138633 [details]
New top-level Automake Makefile

This new Makefile.am addresses the issues raised in Comemnt #13.  I got rid of
litlitekey and keyupg.	I also changed ns-slapd.properties to be a
nodist_data_DATA file.

Created attachment 138634 [details]
New Berkeley DB m4 file

The new db.m4 file addresses the issues brought up in comment #17 about finding
libdb.	It will now check the system locations without needing to specify
"--with-db" when running configure.

Created attachment 138636 [details]
New Net-SNMP m4 file

I ran into some issues where the include path was set incorrectly for locating
the Net-SNMP headers.  This new file fixes these issues.  Basically, our source
files contain the "net-snmp" directory in the include statements (like
<net-snmp/net-snmp-includes.h>.  This means the "$netsnmp_inc" variable needed
to have the "net-snmp" directory removed from the include path.

Looks good.

Created attachment 138699 [details]
CVS Commit Message

Checked into the ldapserver trunk.  Thanks to Rich and Noriko for their
reviews!

*** Bug 159371 has been marked as a duplicate of this bug. ***

We have been using the autotools based build-system for some time now.  Marking
as VERIFIED.