Welcome to autotools hell...
fedora-directory-devel-request@xxxxxxxxxx wrote:
The 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).
First: use a recent automake (1.9.x) that supports the
AM_MAINTAINER_MODE macro, and use that in your configure.ac file. This
will turn off the automatic dependency checking/regeneration of the
Makefile/configure/etc scripts unless you explicitly ask for them (using
configure --enable-maintainer-mode). As a general rule, you don't want
maintainer mode enabled. It was stupid of them to make it the default
behavior but at least it's possible to turn it off now.
Personally I disable as much of this cruft as possible, because even as
a source tree maintainer it only slows me down. (OpenLDAP uses
hand-written Makefile.in and avoids automake because older versions of
automake were just too painful to deal with.)
In source trees that we import from other projects (Heimdal and Cyrus
SASL being the prime offenders here) I always doctor up the
Makefile.in's to comment out the autoregen dependencies before importing
them. There's no reliable way to make sure the datestamps come out of
the CVS repository intact. A slight network delay during a checkout will
cause some files to be newer than expected, thus causing an unnecessary
regen cycle.
So in short: commit everything up to the configure script, so that
arbitrary people can do a checkout / configure / make. Only a very small
number of people should ever be regenerating and committing the other
auto* files, so remove the default rules that cause them to be
regenerated automatically. (I.e., use AM_MAINTAINER_MODE.)
As a further refinement, I added these rules to OpenLDAP's configure.in
to speed up libtool generation:
dnl Disable libtool 1.5 support for languages we don't use
define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl
define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
define([AC_LIBTOOL_LANG_GCJ_CONFIG], [:])dnl
Of course if you're actually using C++ you'll have to let that run as
usual. But it saves a noticable amount of time on slow build machines to
bypass checks for languages we don't need.
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.
Probably will cause more problems down the road.
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
This is probably the most workable idea, and it's not a major hardship.
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
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
