dumpdef output destination

[Eric Blake]

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