On 30 Jan 2015 17:49, Pavel Raiskup wrote:
> [+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], [maint@maint.maint])
>   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

i believe this has been addressed by Zach's patch:
http://git.savannah.gnu.org/cgit/autoconf.git/commit/?h=4c59bf27d7083088290219450c81d999431b43f1

Author: Zack Weinberg <zackw@panix.com>
Date:   Tue Oct 20 13:27:22 2020 -0400

Improve handling of missing aux scripts.
-mike