[Fedora-directory-devel] Re: Fedora-directory-devel Digest, Vol 16, Issue 14

[Howard Chu]

Welcome to autotools hell...

fedora-directory-devel-request(a)redhat.com 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] Re: Please review: [Bug 212098] Use autoconf to generate task perl script templates

[Howard Chu]

Howard Chu wrote:
>  Welcome to autotools hell...
>  
>  fedora-directory-devel-request(a)redhat.com 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. 
One more note - it will make your lives easier if you standardize on a 
single version of each tool, so that when you check in newly generated 
files the diffs will be small and meaningful. Otherwise you get a lot of 
noise, as Andrew already pointed out.

In the past we had things set up so that only a single maintainer was 
permitted to regenerate and check in configure script and associated 
files, to avoid the issue of having many tool versions in use. Also 
there were fixes in our blessed tool versions that the upstream 
maintainers hadn't rolled out yet, so we had to keep tarballs of the 
specific tools available for download as well.

I think we still have a minor patch in our autoconf tool that the 
upstream guys haven't adopted yet - redirecting stderr from the conftest 
programs into the logfile instead of /dev/null (which stock autoconf 
does), so that it's actually possible to diagnose why a config test 
fails. It never fails to amaze me how incredibly un-useful these tools 
are out of the box, and how long it takes to get them fixed.
-- 
   -- 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/