Re: undefined macro

[Jason Stover]

I just upgraded math.gcsu.edu to GNU m4 1.4.9 and that fixed the
problem.  Should we mention it as a requirement in README.CVS?

-Jason

On Wed, Mar 28, 2007 at 08:37:20PM -0700, address@hidden wrote:
> On Wed, Mar 28, 2007 at 04:08:30PM -0400, Jason Stover wrote:
> 
> > make -f Smake is failing to expand AM_INTL_SUBDIR.  I've been
> > struggling with this problem for a while now.  My lack of
> > understanding of aclocal and autoconf is hindering progress.
> 
> Jason kindly gave me a login on the system that was exhibiting
> the problem.  I think I tracked down the problem.  My analysis
> follows.
> 
> AM_GNU_GETTEXT does the following, in part:
> 
>   define([gt_included_intl],
>     ifelse([$1], [external],
>       ifdef([AM_GNU_GETTEXT_][INTL_SUBDIR], [yes], [no]),
>       [yes]))
> ...
>   ifelse(gt_included_intl, yes, [
>     AC_REQUIRE([AM_INTL_SUBDIR])dnl
>   ])
> 
> Thus, if AM_GNU_GETTEXT is passed "external" as its first
> argument, and AM_GNU_GETTEXT_INTL_SUBDIR is defined, then
> gt_included_intl will be set to "yes" and AM_INTL_SUBDIR will be
> invoked.  Nothing in PSPP causes AM_GNU_GETTEXT_INTL_SUBDIR to be
> defined, so AM_INTL_SUBDIR should not be invoked.  Yet some
> testing revealed that the ifdef was taking the "yes" path.
> 
> I eventually figured out that the trace on
> AM_GNU_GETTEXT_INTL_SUBDIR was causing m4 to think that it was
> defined.  It turns out that GNU m4 1.4.3 believes that any macro
> being traced is defined:
> 
>     $ gm4 --version
>     GNU M4 1.4.3
>     Written by Rene' Seindal.
> 
>     Copyright (C) 2005 Free Software Foundation, Inc.
>     This is free software; see the source for copying conditions.  There is NO
>     warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
>     $ which gm4
>     /usr/local/bin/gm4
>     $ uname -a
>     OpenBSD math.gcsu.edu 4.0 GENERIC#1 i386
>     $ cat foo.m4
>     ifdef(`foo',`yes',`no')
>     $ gm4 foo.m4
>     no
>     $ gm4 --trace=foo foo.m4
>     yes
> 
> But m4 1.4.8 does not share this belief:
> 
>     $ m4 --version
>     GNU M4 1.4.8
>     Copyright (C) 2006 Free Software Foundation, Inc.
>     This is free software; see the source for copying conditions.  There is NO
>     warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
>     Written by Rene' Seindal.
>     $ which m4
>     /usr/bin/m4
>     $ uname -a
>     Linux blp 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 GNU/Linux
>     $ cat > foo.m4
>     ifdef(`foo',`yes',`no')
>     $ m4 foo.m4
>     no
>     $ m4 --trace=foo foo.m4
>     no
>     $ 
> 
> Conclusions:
> 
> 1. Jason: I think you can fix the problem by upgrading to the
>    latest version of GNU m4.
> 
> 2. I don't understand why m4 behavior changed.  It doesn't seem
>    to be mentioned explicitly anywhere in NEWS.  I guess it must
>    be related to this item for version 1.4.4b, though:
> 
>     * Tracing a macro by name is now persistent, even if the
>       macro is subsequently undefined or redefined.  The traceon
>       and traceoff macros no longer warn about undefined symbols.
>       This solves a crash when using indir on an undefined macro
>       traced with the -t option, as well as an incorrect result
>       of ifdef.  Furthermore, tracing is no longer transferred
>       with builtins, solving the bug of "m4 -tm4_eval" failing to
>       give trace output on the input
>       "define(`m4_eval',defn(`eval'))m4_eval(1)".
> 
>    The new behavior, where tracing a macro doesn't make it appear
>    to be defined, is certainly better, though.
> 
> 3. It seems that Autoconf should more strongly recommend, or even
>    test for and require, a recent version of m4, since older
>    versions can cause such bizarre, difficult-to-debug problems.
> -- 
> Ben Pfaff
> address@hidden