Red Hat Bugzilla – Bug 210736
Implement autotools build system
Last modified: 2015-12-07 12:16:36 EST
We need to make the Directory Server build system use GNU Autoconf and GNU Automake. The build system needs to support RHEL/FC systems, Solaris 9, and HP-UX IPF systems at a minimum for the first cut. Other platform support can be added in as needed. Implementing the new build system is going to be done in multiple phases. We need to leave the existing Makefiles around for a while until the new build system stabilizes.
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.