More than 7 years ago, Akim changed the master m4 branch to make dumpdef print to stderr instead of the current file set by debugfile. POSIX states that dumpdef output goes to stderr, but we are technically okay to output to a debug file instead of stderr since debugfile (and the counterpart command line options) are extensions not specified by POSIX. If you don't use non-POSIX extensions, the debugfile is stderr; and if you do use extensions, you are outside the realm of POSIX such that the POSIX rules on dumpdef no longer need to apply. On the other hand, using the m4sugar macro m4_dumpdef flat out breaks autom4te in all stable release versions of autoconf, when used with m4 1.4.x, because dumpdef output in the debug file interferes with autom4te's ability to post-process m4 trace output. The situation has been improved for autoconf.git, but is still less than ideal because it does not handle builtins. So we have one of the most common clients of m4 that really wants dumpdef output to go to stderr, not the debug file.
http://lists.gnu.org/archive/html/autoconf-patches/2008-10/msg00315.html In researching this issue, it looks like Akim had some CVS commit issues; his patch to send dumpdef to stderr snuck in as part of a larger botched patch job, with no commit of its own: http://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=27589#patch5 There is no way with m4 1.4.x to make dumpdef always output to stderr without knowing the name of the debugfile, while still preserving the ability to dump builtins. And if we keep the master branch's behavior of dumpdef output to stderr, there is no way to simulate the 1.4.x behavior of having dumpdef go to the debug file instead of stderr. However, with the current state of branch- 1.6, where dumpdef currently goes to the debug file, but you can now pass builtin tokens through ifelse, there IS a way to simulate dumpdef going to stderr, but the drawback is that the wrapper m4_dumpdef is much more expensive in execution time because it must go through an m4_if that compares the macro being dumped against every known builtin token, and this wrapper does not work in m4 1.4.x. http://lists.gnu.org/archive/html/autoconf-patches/2008-12/msg00030.html I don't think it makes sense to change m4 1.4.x; that should remain a stable branch. But I do want to make m4 1.6 and m4 2.0 consistent. I also want to be nice to autoconf, as it is one of the biggest clients of m4, but without too much penalty to other m4 clients that use the debugfile extension. Finally, remember that dumpdef is primarily for debugging an m4 macro during development; it is seldom used in real scripts, since you normally don't expect output on stderr once the macro finally works, whether or not you are using the extension of a separate debugfile. So which option should I use? Option 1 - make 1.6 dumpdef always go to stderr Nicer for autoconf Potentially breaks other clients of debugfile No way to simulate older behavior POSIX wording that dumpdef goes to stderr is honored no matter what, rather than relying on technicalities that a non-POSIX extension is in effect Option 2 - make 2.0 dumpdef always go to debugfile No change in semantics for any clients that rely on dumpdef to debugfile Can still simulate dumpdef to stderr Matches BSD m4 behavior (however, that particular BSD behavior was modeled after GNU m4 1.4.x behavior, and not an independent invention, so that BSD m4 could process autoconf 2.59 files; on the other hand, BSD m4 is unable to process autoconf 2.63 files for other reasons) Harder for autoconf My personal preference is option 1, unless someone can speak up with a counter- argument soon. -- Eric Blake _______________________________________________ m4-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-discuss
