Rob Crittenden wrote:
Nathan Kinder wrote:Richard Megginson wrote:As I just very recently found out, we also need a very specific version of libtool (1.5.22) to generate ltmain.sh if we want to be able to build a 64-bit Directory Server on Solaris. Running "autoreconf -fvi" will generate a new ltmain.sh that may be a version that we don't want to check in if we expect to be able to immediately run "configure; make install" after checking out the code.Andrew Bartlett wrote:I've found that using autoreconf usually does the right thing. When I change configure.ac/in or Makefile.am or an .m4 file, I always runOn Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:Andrew Bartlett wrote:Our current policy is to generate these files for release tarballs, andfor our 'unpacked' tree on samba.org (current SVN checked out).OTOH they are required in order to do: cvs co ./configure makeYeah, projects typically end up with an ./autogen.sh to make the right innovation of the configure generation tool.autoreconf -vfi -v, --verbose verbosely report processing -f, --force consider all files obsolete -i, --install copy missing auxiliary filesIt takes a little longer, but I almost never have conflict or timestamp problems. Plus, it's part of the standard autotools package, and it is the way the autoconf/automake manuals recommend rebuilding the autotool files. For some projects, this won't work (e.g. for mozldap, you have to just use autoconf-2.13, not autoreconf or autoreconf-2.13).-NGKThe real pain is when not all of the files have changed and you check in only those that did. This can cause an unwanted auto* rebuild.I've taken to checking everything in at once whenever one thing changes with:cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure This preserves the proper timestamp/dependency order (at least for me).
If autoreconf doesn't work for directory server, do we need to create an autogen.sh script that "does the right thing"? I would rather not, but if that is the only way to preserve the correct version of ltmain.sh, then we need to do it. For example, we won't be able to use libtool on RHEL4 (with the standard RH updates anyway) because the bundled version of libtool is 1.5.6. However, Fedora Core 5 (and probably RHEL5) are ok because they use 1.5.22. I fear this may not be the only problem with autotool compatability - we also had a problem with hpux 11.23 ia64.
So, some options:1) Only use autoreconf, and only run it on systems that use recent versions of autotools (e.g. fc5) - do not allow the use of autotools on RHEL4 or other less recent platforms. 2) Create an autogen.sh that first looks at the versions of the tools on the system and bails out if it finds an incompatible version - note that we would still have to run it on a modern system in order to actually update the autoconf files 2a) Have autogen.sh "patch" ltmain.sh when run on less recent systems, to allow us to use it on RHEL4 etc. 3) Make ltmain.sh (and possibly other files) somehow read-only with respect to autoreconf
rob ------------------------------------------------------------------------ -- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
