GNU bug report logs - #19539
AC_CONFIG_AUX_DIR should be called early

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 19539 in the body.
You can then email your comments to 19539 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: Pavel Raiskup <praiskup <at> redhat.com>
To: Automake Bugs <bug-automake <at> gnu.org>
Subject: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Thu, 08 Jan 2015 16:43:02 +0100

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

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

Pavel

[bug_sample-1.0.tar.gz (application/x-compressed-tar, attachment)]

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

From: Pavel Raiskup <praiskup <at> redhat.com>
To: 19539 <at> debbugs.gnu.org
Cc: autoconf-patches <autoconf-patches <at> gnu.org>
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Fri, 30 Jan 2015 17:49:49 +0100

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

[+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 <at> 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

Pavel

[0001-autoconf-warn-about-late-AC_CONFIG_AUX_DIR-call.patch (text/x-patch, attachment)]

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: 19539-done <at> debbugs.gnu.org, autoconf-patches <autoconf-patches <at> gnu.org>
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Mon, 7 Feb 2022 23:18:13 -0500

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

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 <at> 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 <at> panix.com>
Date:   Tue Oct 20 13:27:22 2020 -0400

Improve handling of missing aux scripts.
-mike

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

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

From: Glenn Morris <rgm <at> gnu.org>
To: vapier <at> gentoo.org
Cc: 19539 <at> debbugs.gnu.org, autoconf-patches <at> gnu.org
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Tue, 08 Feb 2022 11:03:23 -0500

I see this bug, and a few others, were reassigned to autoconf.
autoconf does not use debbugs to track bugs, so the autoconf package has
no maintainer address, causing mails to end up on the help-debbugs list.

https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=autoconf

Ref eg https://lists.gnu.org/r/help-debbugs/2017-11/msg00001.html

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19539 <at> debbugs.gnu.org, autoconf-patches <at> gnu.org
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Tue, 8 Feb 2022 19:03:17 -0500

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

On 08 Feb 2022 11:03, Glenn Morris wrote:
> I see this bug, and a few others, were reassigned to autoconf.
> autoconf does not use debbugs to track bugs, so the autoconf package has
> no maintainer address

i'm aware of this.  Zach was debating migrating, but until then, seemed
better to park it as such.  no one would be looking at them from any other
project POV since they are autoconf issues.

> causing mails to end up on the help-debbugs list.

i was not aware of this default behavior.  what can we do to suppress the
notifications ?  can we set the maintainer address to /dev/null for a few
known packages like autoconf & libtool ?

> https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=autoconf
> 
> Ref eg https://lists.gnu.org/r/help-debbugs/2017-11/msg00001.html

this one wasn't me ;)
-mike

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

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

From: Glenn Morris <rgm <at> gnu.org>
To: 19539 <at> debbugs.gnu.org
Cc: autoconf-patches <at> gnu.org
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Tue, 08 Feb 2022 22:11:31 -0500

Mike Frysinger wrote:

> what can we do to suppress the notifications ? can we set the
> maintainer address to /dev/null for a few known packages like autoconf
> & libtool ?

I'm not sure if /dev/null works. But I think it would be better to
simply close the issue, ideally with instructions on where to actually
report it.

I see autoconf uses savannah for bug reports.
So long as simply sending a mail to bug-autoconf doesn't open a savannah issue,
I can set the autoconf maintainer to bug-autoconf, so that mails go to
the right place. (It tends not to work well if two bug trackers talk to
each other.)

libtool is actually set up with proper debbugs integration;
although bugs hardly ever seem to get closed; ref
https://debbugs.gnu.org/rrd/libtool.html

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19539 <at> debbugs.gnu.org, autoconf-patches <at> gnu.org,
 Zack Weinberg <zackw <at> panix.com>
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Wed, 9 Feb 2022 01:02:44 -0500

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

On 08 Feb 2022 22:11, Glenn Morris wrote:
> Mike Frysinger wrote:
> > what can we do to suppress the notifications ? can we set the
> > maintainer address to /dev/null for a few known packages like autoconf
> > & libtool ?
> 
> I'm not sure if /dev/null works. But I think it would be better to
> simply close the issue, ideally with instructions on where to actually
> report it.
> 
> I see autoconf uses savannah for bug reports.
> So long as simply sending a mail to bug-autoconf doesn't open a savannah issue,
> I can set the autoconf maintainer to bug-autoconf, so that mails go to
> the right place. (It tends not to work well if two bug trackers talk to
> each other.)

Zach: do you know if there's an e-mail<->savannah gateway ?
-mike

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

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

From: Bob Proulx <bob <at> proulx.com>
To: Glenn Morris <rgm <at> gnu.org>, 19539 <at> debbugs.gnu.org,
 Zack Weinberg <zackw <at> panix.com>, autoconf-patches <at> gnu.org,
 Mike Frysinger <vapier <at> gentoo.org>
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Thu, 10 Feb 2022 18:14:46 -0700

Mike Frysinger wrote:
> Glenn Morris wrote:
> > I see autoconf uses savannah for bug reports.
> > So long as simply sending a mail to bug-autoconf doesn't open a savannah issue,
> > I can set the autoconf maintainer to bug-autoconf, so that mails go to
> > the right place. (It tends not to work well if two bug trackers talk to
> > each other.)
> 
> Zach: do you know if there's an e-mail<->savannah gateway ?

Not Zach but as far as I know bug-autoconf is just a plain and simple
mailing list.  As far as I know there are no Savannah bug tracker
gateways from mail of any type.  Therefore setting bug-autoconf as the
maintainer seems like an excellent idea to me. :-)

Bob

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

From: Glenn Morris <rgm <at> gnu.org>
To: 19539 <at> debbugs.gnu.org
Cc: Mike Frysinger <vapier <at> gentoo.org>, autoconf-patches <at> gnu.org,
 Zack Weinberg <zackw <at> panix.com>
Subject: Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early
Date: Fri, 11 Feb 2022 12:19:54 -0500

Done.

Previous Next

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