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]
