Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early

[Pavel Raiskup]

[+cc autoconf as this should be done in cooperation]

On Thursday 08 of January 2015 16:43:02 Pavel Raiskup wrote:
> Hi, automake-1.15 behaves differently when AC_CONFIG_AUX_DIR is specified
> after AC_USE_SYSTEM_EXTENSIONS (example attached which worked with
> automake-1.14.1):
>
>   $ autoreconf -vfi
>   $ ./configure
>   configure: error: cannot find install-sh, install.sh, or shtool in "." 
> "./.." "./../.."
>
> I think this is result of the commit:
> http://git.savannah.gnu.org/cgit/automake.git/commit/?h=minor&id=7bc592708cc65
>
> I believe that it is bad practice (and probably not-a-bug itself) and
> AC_CONFIG_AUX_DIR should be specified as soon as possible, but we do not
> have this documented (yet).  Thats why I write to bug-automake.  Maybe we
> could install some AC_BEFORE warnings into autoconf but I would like to
> discuss it here.
> And at least it is good to have documented that behavior changed upstream.
>
> Original bugreport:
> https://bugzilla.redhat.com/show_bug.cgi?id=1179182

Some more words, I was probably able to catch the real issue.  In the
failing example was done something like:

  AC_INIT([amhello], [1.0], address@hidden)
  AC_GNU_SOURCE
  AC_CONFIG_AUX_DIR([build-aux])
  AM_INIT_AUTOMAKE([foreign -Werror])
  AC_CONFIG_FILES([Makefile])
  AC_OUTPUT

For this file, autoreconf (even upstream git version) produces broken
configure file if automake-1.15 is used.  This is caused by the following
facts:

  * AC_GNU_SOURCE calls transitively AC_PROG_CC

  * aclocal redefines AC_PROG_CC in aclocal.m4 quite hacky way, but truth
    is that this has been automake doing from v1.13.  But..

  * .. the AC_PROG_CC requires AM_AUX_DIR_EXPAND, which was newly changed
    [1] to require AC_CONFIG_AUX_DIR_DEFAULT.  This is not so bad
    practice, I would say, thats actually what AC_CONFIG_AUX_DIR_DEFAULT
    exists for.

Because the example uses explicit non-default AC_CONFIG_AUX_DIR, the
AC_CONFIG_AUX_DIR_DEFAULT is called first and its check fails because all
auxiliary files (including install-sh) are installed in non-default path.

I believe that new autoconf-2.70 should warn when configure.ac calls
AC_CONFIG_AUX_DIR_DEFAULT before AC_CONFIG_AUX_DIR.  This can be done
easily by:

  AC_PROG_INSTALL
  AC_CONFIG_AUX_DIR([non-default-aux-dir])

I'm able to hack on Automake patch, but that depends on the Autoconf
maintainers opinions and whether the attached patch is OK.  The proposed
patch would be:

  If we already hack some macro (namely AC_PROG_CC) which we make
  dependant on AC_CONFIG_AUX_DIR, we should also hack AC_CONFIG_AUX_DIR so
  it calls AC_BEFORE([AC_CONFIG_AUX_DIR], [AC_CONFIG_AUX_DIR_DEFAULT]).
  All that only if autoconf v2.69 or older is used.

At the beginning, the patch for autoconf is attached.

[1] 
http://git.savannah.gnu.org/cgit/automake.git/commit/?h=minor&id=7bc592708cc65

Pavel

0001-autoconf-warn-about-late-AC_CONFIG_AUX_DIR-call.patch
Description: Text Data