Should aclocal warn when picking up system-wide installed macros?

[Stefano Lattarini]

Severity: wishlist

On 09/25/2012 02:08 AM, Peter Johansson wrote:
> Hi,
>
Hi Peter.  I'm moving this discussion to bug-automake so that we
won't forget about the issue.

> I just helped a co-developer who experienced a mysterious
> 
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: adding subdirectory c++ to autoreconf
> autoreconf: Entering directory `c++'
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /opt/local/bin/autoconf --force
> configure.ac:43: error: possibly undefined macro: AC_MSG_FAILURE
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /opt/local/bin/autoconf failed with exit status: 1
> 
> 
> Line 43 in c++/configure.ac contained
> 
> YAT_CHECK_YAT([0.9.1], [], [AC_MSG_FAILURE([no yat found])])
> 
> which is a macro defined in c++/m4/yat.m4. After some investigation I
> realized the problem is that aclocal doesn't find 'yat.m4' and adding
> 
>     ACLOCAL_AMFLAGS = -I m4
> 
> in c++/Makefile.am solved the problem as expected. The annoying thing
> is that I did not see this problem because my aclocal finds yat.m4
> under /usr/local. I'm not sure what I'm asking for here, but it would
> be nice if I could have aclocal complain somehow in this scenario. Is
> it possible to tell aclocal to only pick up local files that it can
> m4_include into aclocal.m4? Only time I really wanna pick up installed
> m4 files is when I issue 'aclocal --install -I m4', or am I misusing
> aclocal?
>
I believe your request makes lot of sense.  We could add a new warning
'-Wglobal-macros' (say) that reports any picked-up m4 file that cannot
be 'm4_include'd into aclocal.m4.  And that warning could become active
by default in Automake 1.14 (assuming there will be a simple way to
disable it from 'autoreconf').  Of course, such a warning should be
disabled whenever the '--install' is used.

Also, having a way to turn that warning (and that warning only) into a
fatal error would allow us to enhance the 'distcheck' target to verify
that no non-distributed third-party m4 file is required to re-bootstrap
the package.

Not sure when I'll have time and will to pursue this though; in the
meantime, as usual, feedback and patches welcome.

And BTW, to save us from potentially wasted effort: can anyone think
of real-word use cases that would be hampered or broken by the proposal
above?

Regards,
  Stefano