GNU bug report logs - #15593
unnecessarily created autom4ate.cache directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15593 in the body.
You can then email your comments to 15593 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ondřej Bílka <neleai <at> seznam.cz>
To: bug-automake <at> gnu.org
Subject: unnecessarily created autom4ate.cache directory
Date: Fri, 11 Oct 2013 18:24:43 +0200

Hi, A glibc supports builds only from separate build directory than source
directory. In source directory a autom4ate.cache is created.

See following bug entry.
https://sourceware.org/bugzilla/show_bug.cgi?id=14120

Message #12 received at 15593-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Ondřej Bílka <neleai <at> seznam.cz>,
 15593-done <at> debbugs.gnu.org
Subject: Re: bug#15593: unnecessarily created autom4ate.cache directory
Date: Fri, 11 Oct 2013 17:22:12 -0600

[Message part 1 (text/plain, inline)]

tag 15593 notabug
thanks

On 10/11/2013 10:24 AM, Ondřej Bílka wrote:
> Hi, A glibc supports builds only from separate build directory than source
> directory. In source directory a autom4ate.cache is created.
> 
> See following bug entry.
> https://sourceware.org/bugzilla/show_bug.cgi?id=14120

How is this an automake bug?  Automake doesn't create autom4te.cache;
that's autoconf (via the autom4te program shipped as part of the
autoconf package).  But such a directory is only created if you are
actually running one or more of the autotools; you should be figuring
out what in glibc's configure script is running autotools during
configure (the normal configure script is intentionally independent of
autotools, where only the maintainer has a cache file when they ran
autoreconf, but where end users do NOT get a cache file by just running
path/to/configure).

Looking at glibc's configure.in (eww, outdated name; these days
autotools prefer configure.ac), I see:

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

That's your culprit.

It is also possible to create a ./.autom4te.cfg file to explicitly
request that autom4te always use the --no-cache option to avoid creating
a cache directory (this is documented in the autoconf manual [1]).

[1]
https://www.gnu.org/software/autoconf/manual/autoconf.html#Customizing-autom4te

I'm closing this as not an automake bug, although do feel free to
continue asking questions in this thread.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.