headers
Eric Blake | 10 Jul 22:43
Gravatar

outdated m4sugar

Right now, the latest bison sources are incompatible with the latest m4 
sources.  When I built bison with the latest m4.git (will become m4 1.6), the 
change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX) trips up 
a fresh build of bison:

$ m4 --version | head -n1
m4 (GNU M4) 1.5.89a.15-21859
$ sed -n '1,4 { s/<.*>/<...>/; p }' ChangeLog 
2008-05-27  Joel E. Denny  <...>

	* NEWS (2.3b+): New section, empty for now.
	* configure.ac (AC_INIT): 2.3b -> 2.3b+.
$ make
...
make[2]: Entering directory `/home/eblake/bison/examples/calc++'
../../tests/bison -d -ra -S lalr1.cc -o ./calc++-parser.cc \
	  ./calc++-parser.yy
stdin:1: error: m4_init: unbalanced m4_divert_push:
stdin:1: m4_divert_push: KILL
stdin:1: the top level
/home/eblake/bison/src/bison: subsidiary program `/usr/local/bin/m4' failed 
(exit status 1)

I tracked it to the fact that bison's m4sugar.m4 is three years old (it is 
newer than the m4sugar shipped with autoconf 2.59, but older than 2.59c), which 
means it relies on non-POSIX LIFO m4wrap semantics (autoconf 2.60 was the first 
non-beta release that works regardless of LIFO vs. FIFO m4wrap).  ChangeLog-
wise, bison's version looks like it forked from autoconf commit 
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=cf3b3ede, 
then added the macro m4_prepend (which autoconf should also consider adding).
(Continue reading)

Permalink | Reply | 10 comments |
headers
Akim Demaille | 11 Jul 10:38
Picon
Picon
Picon
Gravatar

Re: outdated m4sugar


Le 10 juil. 08 à 22:43, Eric Blake a écrit :

Hi Eric,

> Right now, the latest bison sources are incompatible with the latest  
> m4
> sources.  When I built bison with the latest m4.git (will become m4  
> 1.6),

Yay!

> the
> change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX)

I have not understood why they made that choice :(

> trips up
> a fresh build of bison:
>
> $ m4 --version | head -n1
> m4 (GNU M4) 1.5.89a.15-21859
> $ sed -n '1,4 { s/<.*>/<...>/; p }' ChangeLog
> 2008-05-27  Joel E. Denny  <...>
>
> 	* NEWS (2.3b+): New section, empty for now.
> 	* configure.ac (AC_INIT): 2.3b -> 2.3b+.
> $ make
> ...
> make[2]: Entering directory `/home/eblake/bison/examples/calc++'
(Continue reading)

Permalink | Reply | 5 comments |
headers
Akim Demaille | 11 Jul 10:59
Picon
Picon
Picon
Gravatar

Re: outdated m4sugar


I would love 1.6 to show the location of the openings
that are not closed instead of the location of... the
end of file :(  Something to speed up the understanding
of errors like the following.

m4debug:/Users/akim/src/urbi/2.0/kernel/bison/_build/i386-apple- 
darwin9.4.0/../../data/c++-skel.m4:26: input exhausted
/opt/local/bin/gm4:/Users/akim/src/urbi/2.0/kernel/bison/_build/i386- 
apple-darwin9.4.0/../../data/lalr1.cc:1075: ERROR: end of file in  
argument list
/Users/akim/src/urbi/2.0/kernel/bison/_build/i386-apple-darwin9.4.0/ 
src/bison: subsidiary program `/opt/local/bin/gm4' failed (exit status  
1)

This is 1.4.6.
Permalink | Reply | 2 comments |
headers
Joel E. Denny | 11 Jul 11:00

Re: outdated m4sugar

Hi Eric,

On Thu, 10 Jul 2008, Eric Blake wrote:

> Right now, the latest bison sources are incompatible with the latest m4 
> sources.  When I built bison with the latest m4.git (will become m4 1.6), the 
> change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX) trips up 
> a fresh build of bison:

> stdin:1: error: m4_init: unbalanced m4_divert_push:
> stdin:1: m4_divert_push: KILL
> stdin:1: the top level
> /home/eblake/bison/src/bison: subsidiary program `/usr/local/bin/m4' failed 
> (exit status 1)

Patching Bison so that it works with either LIFO or FIFO m4wrap is 
straight-forward.  I just removed the code in m4_wrap in m4_init and 
rewrote Bison to invoke it after processing the skeletons.  Only one use 
of m4wrap remains, and so order no longer matters.  Bison's make check 
then passes for m4 1.4.6 or m4 built from today's git sources.

For the new m4, I had to update m4sugar.m4 for the rename of symbols to 
m4symbols.  I haven't figured out why, but this change doesn't hurt with 
m4 1.4.6.

I also had to make Bison pass -g to m4 just in case POSIXLY_CORRECT is 
set.  This does not work with m4 1.4.6, but Bison could just unset 
POSIXLY_CORRECT when invoking m4 if we need to support m4 1.4.6 for some 
reason.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 11 Jul 13:59
Gravatar

m4 EOF behavior [was: outdated m4sugar]


According to Akim Demaille on 7/11/2008 2:59 AM:
|
| I would love 1.6 to show the location of the openings
| that are not closed instead of the location of... the
| end of file :(

I thought I've already done that.

| ERROR: end of file in argument list
|
/Users/akim/src/urbi/2.0/kernel/bison/_build/i386-apple-darwin9.4.0/src/bison:

| subsidiary program `/opt/local/bin/gm4' failed (exit status 1)
|
| This is 1.4.6.

Huh?  The NEWS for 1.4.6 claims that this was the release where I fixed
that particular bug:

| ** The error message when end of file is encountered now uses the
| file and line where the dangling construct started, rather than
| `NONE:0:'.

At any rate, I'd be more interested in seeing the same results with the
latest stable release, m4 1.4.11.

--
Don't work too hard, make some time for fun as well!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 11 Jul 14:57
Picon
Picon
Picon
Gravatar

Re: m4 EOF behavior [was: outdated m4sugar]


Le 11 juil. 08 à 13:59, Eric Blake a écrit :

> | ** The error message when end of file is encountered now uses the
> | file and line where the dangling construct started, rather than
> | `NONE:0:'.
>
> At any rate, I'd be more interested in seeing the same results with  
> the
> latest stable release, m4 1.4.11.

Thanks, I'll give it a try.  Meanwhile I found M-x check-parens,
and I live happily again :)
Permalink | Reply | 0 comments |
headers
Eric Blake | 11 Jul 15:14
Gravatar

Re: outdated m4sugar


[adding m4-discuss]

According to Joel E. Denny on 7/11/2008 3:00 AM:
| Hi Eric,
|
|
| Patching Bison so that it works with either LIFO or FIFO m4wrap is
| straight-forward.  I just removed the code in m4_wrap in m4_init and
| rewrote Bison to invoke it after processing the skeletons.  Only one use
| of m4wrap remains, and so order no longer matters.  Bison's make check
| then passes for m4 1.4.6 or m4 built from today's git sources.

It sounds like you built the master branch (will become m4 2.0) rather
than branch-1.6 (will become 1.6).  There are even more changes on the
master branch that might need attention, but that branch is not as stable,
so I'm not as worried about it at the moment, when compared with 1.6.

|
| For the new m4, I had to update m4sugar.m4 for the rename of symbols to
| m4symbols.  I haven't figured out why, but this change doesn't hurt with
| m4 1.4.6.

m4symbols is a new addition on the 2.0 branch.  It was previously named
symbols (if you use the alpha-quality 1.4o release), but the introduction
of a new builtin macro that matches an English word and has an effect when
used without arguments was ill-advised, so we renamed it to m4symbols.  I
haven't decided yet whether I should add it to the 1.6 branch (after all,
1.6 is a version bump, making it an opportune time to add some useful
features, even though it certainly won't have all the bells and whistles
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 11 Jul 21:57
Gravatar

Re: outdated m4sugar


According to Akim Demaille on 7/11/2008 2:38 AM:
|
|> the
|> change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX)
|
| I have not understood why they made that choice :(

"they" being me (as m4 maintainer) or the Austin group (as the POSIX folks
who documented m4wrap as FIFO)?  At any rate, both the Solaris and BSD m4
implementations (and I'm assuming the older SysV, on which Solaris was
based), did FIFO; GNU m4 1.4.x was the odd man out for doing LIFO.
Fortunately, along with making the change, I also documented how to
restore the 1.4.x LIFO behavior by defining the appropriate wrapper around
m4wrap (and m4sugar, as of autoconf 2.62, uses that wrapper), such that it
is possible to get portable and known wrap semantics (of either variety)
regardless of whether the underlying m4 is FIFO or LIFO.

|> ChangeLog-
|> wise, bison's version looks like it forked from autoconf commit
|>
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=cf3b3ede,
|>
|> then added the macro m4_prepend (which autoconf should also consider
|> adding).
|
| It would be very nice, indeed, that m4sugar be unified again.

I've just committed a patch to autoconf to add m4_prepend, such that all
macros used by bison's fork are now present in autoconf's fork.  Next I'll
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric Blake | 12 Jul 03:34
Gravatar

cygwin testsuite failure


With cygwin 1.5.25 and all pre-built cygwin packages installed, I get the
following failure on bison 2.3b+ and m4 1.4.11: (full log attached,
relevant portion clipped here)

## ---------------------- ##
## Detailed failed tests. ##
## ---------------------- ##

#                             -*- compilation -*-
49. output.at:188: testing ...
./output.at:188: bison -o "\`~!@#\$%^&*()-=_+{}[]|\\:;<>, .'.c"
--defines="\`~!@
#\$%^&*()-=_+{}[]|\\:;<>, .'.h" glr.y
Not enabling shell tracing (command contains a `...` command substitution)
--- /dev/null   2006-11-30 17:00:00.000000000 -0700
+++ /home/eblake/bison/tests/testsuite.dir/at-groups/49/stderr  2008-07-11
14:54
:18.921875000 -0600
@@ -0,0 +1 @@
+/home/eblake/bison/src/bison: cannot open file
``~!@#$%^&*()-=_+{}[]|\:;<>, .'.
c': No such file or directory
./output.at:188: exit code was 1, expected 0
49. output.at:188: 49. Output file name: `~!@#$%^&*()-=_+{}[]|\:;<>, .'
(output.
at:188): FAILED (output.at:188)

On cygwin, \ is an (alternate) directory separator, and since
"`~!@#$%^&*()-=_{}[]|" isn't a directory, that explains the ENOENT failure
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Blake | 12 Jul 03:38
Gravatar

bison.1 in version control?


It looks like bison generally tries to avoid generated files in version
control (for example, configure or Makefile.in).  Any reason that
doc/bison.1 is an exception to this rule?  Also, I noticed that
.prev-version is NOT in version control, which means builds start out with
this message:

cat: .prev-version: No such file or directory

In comparison, coreutils keeps .prev-version under control, while using a
copy of help2man to avoid keeping .1 under control.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 12 comments |

Gmane