GNU bug report logs - #61828
aclocal warns when specifying the m4 macro dirs through AC_CONFIG_MACRO_DIRS

Previous Next

To reply to this bug, email your comments to 61828 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Bruno Haible <bruno <at> clisp.org>
To: bug-automake <at> gnu.org
Subject: aclocal warns when specifying the m4 macro dirs through
 AC_CONFIG_MACRO_DIRS
Date: Sun, 26 Feb 2023 23:07:30 +0100

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

According to the Autoconf documentation
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Input.html
  "Packages that use aclocal to generate aclocal.m4 should declare where
   local macros can be found using AC_CONFIG_MACRO_DIRS."
and
  "Note that if you use aclocal from an Automake release prior to 1.13 to
   generate aclocal.m4, you must also set
     ACLOCAL_AMFLAGS = -I dir1 [-I dir2 ... -I dirN]
   in your top-level Makefile.am."

it sounds like

1) specifying the m4 macro dirs through AC_CONFIG_MACRO_DIRS is
   equivalent to specifying them through 'aclocal' command-line options
   or ACLOCAL_AMFLAGS.

2) specifying them through AC_CONFIG_MACRO_DIRS is better than through
   'aclocal' command-line options because is allows 'autoreconf' to
   see which -I options to pass to 'aclocal'.

3) specifying them through AC_CONFIG_MACRO_DIRS is better than through
   ACLOCAL_AMFLAGS. Citing automake/NEWS:
     "- The special make variable ACLOCAL_AMFLAGS is deprecated; future
        Automake versions will warn about its use, and later version will
        remove support for it altogether."

So, this is what I'm trying to do. In the attached hello.tar.gz you find
  - a 'hello1' directory which uses ACLOCAL_AMFLAGS (old style),
  - a 'hello2' directory which uses AC_CONFIG_MACRO_DIRS (new style).

In both cases, the generated aclocal.m4 files are the same.

The problem is that migrating from hello1 to hello2 introduces an
undesired warning:

hello1$ aclocal -I m4
(no warning)

hello2$ aclocal
configure.ac:13: warning: macro 'AM_GNU_GETTEXT' not found in library

$ diff hello1/aclocal.m4 hello2/aclocal.m4
(no differences)

For reference:

$ aclocal --version
aclocal (GNU automake) 1.16.5
...
$ autoconf --version
autoconf (GNU Autoconf) 2.71
...

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

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

From: Bruno Haible <bruno <at> clisp.org>
To: 61828 <at> debbugs.gnu.org
Subject: Re: aclocal warns when specifying the m4 macro dirs through
 AC_CONFIG_MACRO_DIRS
Date: Sun, 26 Feb 2023 23:09:25 +0100

I don't understand what's happening in the 'aclocal' program. There is
a variable @user_includes with a comment

# @user_includes can be augmented with -I or AC_CONFIG_MACRO_DIRS.

So, from this comment, it sounds strange that specifying the m4 macro dirs
through AC_CONFIG_MACRO_DIRS produces a different behaviour than through
-I options.

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

From: Karl Berry <karl <at> freefriends.org>
To: bruno <at> clisp.org
Cc: 61828 <at> debbugs.gnu.org
Subject: Re: bug#61828: aclocal warns when specifying the m4 macro dirs through
 AC_CONFIG_MACRO_DIRS
Date: Tue, 28 Feb 2023 14:39:05 -0700

Hi Bruno,

    I don't understand what's happening in the 'aclocal' program. 

Me either.  Sorry to be such a failure as a maintainer, but it's not
like I've ever looked at that program, or could do so any better than
you.  Any chance you could check into it and maybe find a patch for the
undesired/incorrect warning?

     "- The special make variable ACLOCAL_AMFLAGS is deprecated; future
        Automake versions will warn about its use, and later version will
        remove support for it altogether."

FWIW, I personally have no intention of ever warning, let alone
removing, ACLOCAL_AMFLAGS. Doing so would cause endless trouble with
little benefit, as far as I can see.  Not that I control anything, but
since that message has been there for 10+ years and nothing has been
done, I guess whatever problems it was seen to cause are not
insurmountable. I changed the wording in NEWS to be closer to the
wording in NEWS-2.0, which talks about a warning, but not removing. (2.0
itself is fully mythical, as far as I know.) --thanks, karl.

Previous Next

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