-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Akim Demaille on 4/24/2008 3:22 AM:
|> -m4_define([m4_expand], [_$0(($1))])
|> +m4_define([m4_expand], [_$0(-=(=-$1-=)=-)])
|> m4_define([_m4_expand],
|> -[m4_changequote([(],
[)])$1m4_changequote`'m4_changequote(`[', `]')])
|> +[m4_changequote([-=(=-],
|> [-=)=-])$1m4_changequote`'m4_changequote(`[', `]')])
|
| Does the --traces mechanism support this properly?
| I tried to avoid changequote for many reasons, including
| --trace.
Yes. You are correct that the m4 --trace mechanism uses the
current
quoting for outputting the trace of macros that are
expanded, but the
autom4te --trace mechanism assumes that all traces will be
output with
only [] quoting. So, here's the effect of all autoconf
locations that use
m4_changequote: No one uses m4_noquote. In the case of
_m4_split, there
is a single macro invocation done with the changed quotes
(m4_bpatsubst),
making it next to impossible to trace m4_bpatsubst reliably
(I noticed
this when I was profiling regular expression handling in m4
last year, to
figure out how to improve speed on both m4 and autoconf's
side of the
fence). The _m4_split use of changequote is a pre-existing
issue, not
affected by this week's patches. Finally, in the case of
_m4_expand, no
macro expansions occur during the time the quotes are
changed (unless you
count m4_changequote itself, but tracing that is inherently
difficult), so
trace output is not impacted by this patch. (The list of
changequote
clients is small, so autoconf has done well at avoiding
unnecessary
changequote).
Perhaps we could add _m4_bpatsubst as a synonym for
m4_bpatsubst, and use
_m4_bpatsubst anywhere that tracing is dangerous (_m4_split)
and
m4_bpatsubst everywhere else. User code should not be
calling
_m4_bpatsubst, as an undocumented internal macro; the end
result would be
that tracing m4_bpatsubst is less likely to fail, because it
no longer
traces during changed quotes. This would mean the
m4_bpatsubst trace is
no longer an accurate picture of how many regular
expressions are being
processed by m4, but I'm okay with that. Besides, when I
was tuning m4's
regex performance last year, I ended up adding the
capability to define
DEBUG_REGEX before building m4 to output an independent
trace file of
regular expression cache behavior, which I then used to tune
the caching
parameters that I had added to m4 (use m4 1.4.10b or git m4
to see the
speed improvements; regular expression caching won't be in a
stable
release until m4 1.6). When it comes to tracing overall
regex behavior,
m4's trace proved more useful than trying to make autom4te
do it.
It is probably also technically possible to change autom4te
to always
trace m4_changequote, and use that knowledge that quotes
have changed and
adjust its trace parsing of intermediate traced macros
accordingly.
However, there are autoconf macros in the wild (particularly
Bruno
Haible's macros in gnulib) where the author has
intentionally disregarded
our advice against m4_changequote, which use
m4_changequote(,) to disable
quotes around certain blocks of text; I don't know if it is
possible to
make autom4te behave nicely in the face of disabled quotes
if it were to
be modified to track all quoting changes.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9 byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgQevIACgkQ84KuGfSFAYA3rACfbJU6L37dUq7KyBlM+YH2
gxzr
VPcAoJ8e7J7Mo9J18oBKhnisKAG6sWjX
=iz0Z
-----END PGP SIGNATURE-----
|
