Creating that directory can be disabled by putting this in .autom4te.cfg in the source directory:

begin-language: "Autoconf-without-aclocal-m4"
args: --nocache
end-language: "Autoconf-without-aclocal-m4"

Obviously, that disables its creation altogether...   I don't think it can be configured to create the directory in the build directory.

IMHO we should just remove that check.

(In reply to comment #2)
> IMHO we should just remove that check.

Post a patch? I'll review it.

Running 'autoconf' normally creates autom4te.cache, but running 'configure' does not, at least not for configure files generated by autoconf.

From a fresh git checkout, running "../glibc/configure --prefix=/usr" in a build directory leaves this directory:

$ ls ../glibc/autom4te.cache/
output.0t  requests  traces.0t

All those files have zero size.

(In reply to Allan McRae from comment #5)
> From a fresh git checkout, running "../glibc/configure --prefix=/usr" in a
> build directory leaves this directory:
> 
> $ ls ../glibc/autom4te.cache/
> output.0t  requests  traces.0t
> 
> All those files have zero size.

That's odd, configure should not touch anything in the source directory. We should support read-only source trees with the ability to have multiple builds going from one source tree.

I wonder what's changed... bug in autotools?

Here's the culprit in your configure.in (by the way, newer autotools recommend the name configure.ac, not .in):

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
if test "x$AUTOCONF" = xno; then
  aux_missing="$aux_missing autoconf"
fi

Fix that macro to quit trying to run autoconf in $(srcdir) as part of configure, and you will no longer be stuck with a cache file in $(srcdir).

On Fri, 11 Oct 2013, eblake at redhat dot com wrote:

> Here's the culprit in your configure.in (by the way, newer autotools recommend
> the name configure.ac, not .in):

As far as I can see, Mike's patch to move to .ac was approved by Carlos 
over a month ago (subject to a wiki update) and no-one objected; I'm not 
sure what's delaying the commit.

Testing for autoconf in a configure script...  interesting!

Looking into the history of this, it appears to have been introduced so that when the old "--with-cvs" flag was used, calling make would regenerate configure and friends when their source file was updated.  When building with "--without-cvs" this check was not performed and make would not update any of these files.

Can I just kill this check?  It does not seem something that should be done during configure and make.

(In reply to Allan McRae from comment #9)
> Testing for autoconf in a configure script...  interesting!
> 
> Looking into the history of this, it appears to have been introduced so that
> when the old "--with-cvs" flag was used, calling make would regenerate
> configure and friends when their source file was updated.  When building
> with "--without-cvs" this check was not performed and make would not update
> any of these files.
> 
> Can I just kill this check?  It does not seem something that should be done
> during configure and make.

I think the check should get removed since it's clearly leading to problems. Regenerating these files is an independent and conscious step. Mike's patch to change the file name should also get checked in.

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  8894bad34cc9c11e89ee2594f2d75893edb1d96c (commit)
      from  73616a74274223356c99dda66234f54932bb8c16 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8894bad34cc9c11e89ee2594f2d75893edb1d96c

commit 8894bad34cc9c11e89ee2594f2d75893edb1d96c
Author: Allan McRae <allan@archlinux.org>
Date:   Mon Dec 16 11:25:04 2013 +1000

    Add --enable-maintainer-mode configure option
    
    Autoconf is tested for and run if needed only when --enable-maintainer-mode
    is used on configure.  This results in the autom4te.cache directory only
    being written in the source directory during configure if automatic
    autoconf usage is requested.
    
    Fixes BZ #14120.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog    |    5 +++++
 configure    |   46 ++++++++++++++++++++++++++++++----------------
 configure.ac |   40 ++++++++++++++++++++++++----------------
 3 files changed, 59 insertions(+), 32 deletions(-)

The autom4te.cache directory is now only created when using --enable-maintainer-mode.