Dumb build behavior: autoconf

["Kaz Kylheku" <KKylheku at zeugmasystems dot com>]

The glibc build shouldn't automatically run autoconf when files are out
of
date.

People have to patch these files sometimes, and if you apply a series of
patches rapidly in succession, then you may end up with a configure.in
and
configure having the same timestamp under the granularity of the utimes
on the
filesystem.

In my OS distro build, I have some logic to touch various files to
prevent this
from happening, because it does happen.

Also I can't believe anyone would implement rules to run autoconf /and/
commit
the results into CVS automatically if there is a CVS/ directory present.
That's
moronic. Updating the configure script should be the job of some human
being
who takes responsibility for the contents. What if people downstream
keep a
glibc tree in CVS also? They get the same behavior.  They may not have
the
right version of autoconf, and it could wrongly munge their
configure scripts.

At the very least, these automatic commits should be deferred until the
build
is successful. At the end of the build, you can run a script  which can
do
a cvs diff over all of the configure scripts. If there are diffs, then
commit them (only if the build worked).  This logic does not have to be
in the glibc tree at all, but in the controlling scripts on your build
machines. Geez!


And, lastly, who is the butthead who wrote this configure check?

AC_CHECK_PROGS(AUTOCONF, autoconf, no)
case "x$AUTOCONF" in
xno|x|x:) AUTOCONF=no ;;
*)
  AC_CACHE_CHECK(dnl
whether $AUTOCONF${ACFLAGS:+ }$ACFLAGS works, libc_cv_autoconf_works,
[dnl
  if (cd $srcdir; $AUTOCONF $ACFLAGS configure.in > /dev/null 2>&1);
then
    libc_cv_autoconf_works=yes
  else
    libc_cv_autoconf_works=no
  fi])
  test $libc_cv_autoconf_works = yes || AUTOCONF=no
  ;;
esac

NO!!!    You don't run autoconf just to see whether the stupid thing
works! It
has side effects.  Running it regenerates the configure script. Another
build
going on in parallel from the same source tree will then run configure
via
config.status --recheck because suddenly it sees that configure is newer
than
its config.status file.

Autoconf is a broken GNU-isance; don't touch it at build time. You
should
not care whether or not it works, because you're not going to be running
it.
(And you already know the answer: it doesn't work 100% and never will.
Get over it). 

What if the wrong version is installed? The configure script in
glibc-2.9 was
created by autoconf 2.61.  If I need to patch configure.in, or
aclocal.m4, I
will make sure I regenerate with 2.61, and include the configure script
in the
patch.  But the build machines do not have autoconf 2.61, they are on
2.59.
That's okay because they should never, ever run autoconf. In fact, I
should
uninstall it, or move it to some location that isn't in the $PATH.

Why do we configure programs in a separate build directory,
if the build is going to perform side effects back in the source?

(Let me guess, someone will now tell me that there is some
option there in the glibc configure to disable these
auto-autoconf-ing behaviors, and I look like a moron for
not doing some RTFM).

Well, that's the end of my rant. Flame away.