-----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 [EMAIL PROTECTED] -----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+YH2gxzr VPcAoJ8e7J7Mo9J18oBKhnisKAG6sWjX =iz0Z -----END PGP SIGNATURE-----