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
