bug#19311: regression: 1.14 may use ac_aux_dir before defined (again)

[Stefano Lattarini]

retitle 19311 AC_PROG_CC can force wrong $ac_aux_dir definition in automake 1.14
severity 19311 minor
thanks

On 12/08/2014 06:15 PM, Jan Engelhardt wrote:
> When AC_SYSTEM_EXTENSIONS precedes AM_INIT_AUTOMAKE, it used to throw an
> error - which has been fixed in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15981 .
>
> I have here another instance of what appears to be a similar issue. This
> one is also a regression (used to work in 1.13.4), and the regression is
> still present in {automake 1.14.1 + patch from #15981}. The problem
> originates in libmemcached/configure.ac, and I have produced the
> following reduced testcase that exhibits the issue:
>
> $ cat <<EOF >configure.ac
> AC_INIT([foo], [0])
> AC_PROG_CC([cc gcc clang])
> AC_CONFIG_AUX_DIR([build-aux])
> AC_CONFIG_MACRO_DIR([m4])
> AM_INIT_AUTOMAKE([1.11 subdir-objects foreign])
> AC_OUTPUT([Makefile])
> EOF
> $ echo '' >Makefile.am
> $ md m4
> $ autoreconf -fi
> configure.ac:2: installing 'build-aux/compile'
> configure.ac:5: installing 'build-aux/install-sh'
> configure.ac:5: installing 'build-aux/missing'
> $ ./configure
> checking for cc... cc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether cc accepts -g... yes
> checking for cc option to accept ISO C89... none needed
> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.."
> "./../.."
>
> With automake-1.13.4, configure would succeed through to the end
> ("config.status: creating Makefile").
This is due to the fact that automake actually rewrite AC_PROG_CC
in order to integrate it with the 'compile' script, and to do so, it
needs the $am_aux_dir variable to be defined.  That in turns requires
AC_CONFIG_AUX_DIR to be called beforehand.  If that macro isn't
called explicitly before the AC_PROG_CC invocation, then the code in
AM_AUX_DIR_EXPAND will force-expand it with its default behavior,
which is to have configure look into '.', '..' and '../..' for the
required auxiliary scripts, and bail out if they are not found.
Which is what is causing your issue.

The issue can be solved by moving the AC_CONFIG_AUX_DIR call before
the AC_PROG_CC call.  Arguably, a more user-friendly behavior would
be to automake patch AC_CONFIG_AUX_DIR so that it fails hard and with
a clear error message if it gets invoked after AM_AUX_DIR_EXPAND has
been called (explicitly or implicitly).  Patches welcome (either for
code or docs).

An even better solution *might* be to shuffle the expansion of
AC_CONFIG_AUX_DIR so that it goes immediately after the AC_INIT
explansion, but that requires more m4 magic than my rusty brain
can grasp at the momwnt; and in addition, I'm not sure whether
such a change could cause new backward incompatibilities (possibly
subtle ones).  Looping in Eric,Blake explicitly, who, being the m4
maintainer and one of the main Autoconf devs, is probably the best
person to give feedback.

Thanks,
  Stefano