[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tracing output [was: 2.62 AT_SETUP limitations]

From: Eric Blake
Subject: tracing output [was: 2.62 AT_SETUP limitations]
Date: Thu, 24 Apr 2008 06:20:02 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

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

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             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]