bison-patches
[Top][All Lists]
Advanced

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

Re: outdated m4sugar


From: Eric Blake
Subject: Re: outdated m4sugar
Date: Tue, 15 Jul 2008 06:15:56 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666

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




reply via email to

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