Re: undefined macro

[blp]

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