-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [dropping m4-discuss, bug-bison]
According to Joel E. Denny on 7/15/2008 1:40 AM: | * data/m4sugar/m4sugar.m4 (m4_symbols): Rename from either symbols or | m4symbols, depending on which is already defined. Here, I'd copy this section from the recent autoconf patch (changeword is also a candidate that needs special handling, but it occurs alphabetically before ifdef, hence I had to also hoist m4_if*): http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=5fb9f9c#patch2 | (m4_wrap): Eliminate by moving wrapped code, which dealt with cleaning | up the diversion stack, to... | * data/cleanup.m4: ... this new file. Again, rather than creating a new file, I'd copy what autoconf does (it makes it easier to merge bison and autoconf's m4sugar back into a common file). Either this older patch, which also fixes m4sugar to only use one m4wrap: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=66931ce Or this newer patch series, which makes sure m4_wrap is FIFO regardless of m4: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=39ed7a3 http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=3c108e5 Or all three. Would you like me to propose a patch? | * src/output.c (output_skeleton): For the m4 invocation, pass | ../data/cleanup.m4, pass -dV first because it may become | position-independent, and unset POSIXLY_CORRECT so Bison's skeletons s/in\(dependent\)/$1/ | have access to GNU M4 extensions. Add comments explaining these | issues in more detail. | @@ -1764,11 +1765,6 @@ m4_define([m4_init], | # for sake of simplicity. | m4_pattern_forbid([^_?m4_]) | m4_pattern_forbid([^dnl$]) | - | -# Check the divert push/pop perfect balance. | -m4_wrap([m4_ifdef([_m4_divert_diversion], | - [m4_fatal([$0: unbalanced m4_divert_push:]_m4_divert_n_stack)])[]]) | - | m4_divert_push([KILL]) | -m4_wrap([m4_divert_pop([KILL])[]]) | +# Bison pops KILL in ../close.m4. If you keep cleanup.m4 rather than syncing from autoconf, then this is a typo. | + /* When POSIXLY_CORRECT is set, some future versions of GNU M4 (most likely | + 2.0) may drop some of the GNU extensions that Bison's skeletons depend | + upon. So that the next release of Bison is forward compatible with those | + future versions of GNU M4, we unset POSIXLY_CORRECT here. | + | + FIXME: A user might set POSIXLY_CORRECT to affect processes run from | + macros like m4_sycmd in a custom skeleton. For now, Bison makes no s/m4_sycmd/m4_syscmd/ | + promises about the behavior of custom skeletons, so this scenario not a | + concern. However, we eventually want to eliminate this shortcoming. The | + next release of GNU M4 (1.4.12 or 1.6) will accept the -g command-line I'm still not sure whether 1.4.12 will be necessary... | + option, which in a later release will indicate that POSIXLY_CORRECT should | + be ignored. Once the GNU M4 that accepts -g is pervasive, Bison should | + use -g instead of unsetting POSIXLY_CORRECT. | + | + See the thread starting at | + <http://lists.gnu.org/archive/html/bug-bison/2008-07/msg00000.html> | + for details. */ | + unsetenv ("POSIXLY_CORRECT"); Good comment. But now you need to do 'gnulib-tool --import unsetenv'. - -- 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 iEYEARECAAYFAkh8lPsACgkQ84KuGfSFAYB6rwCg2QMbZaFfsY+V5S059N1+Bgwi msIAoNNqoqhltvXf0oKm0NEY0lu0g97I =gioR -----END PGP SIGNATURE-----
