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
