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, [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
