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. I can apply a patch later if this is the way we want to go. Btw, HACKING in m4's latest git sources says it depends on Automake 1.10.1, which does not appear to provide the pkglibexecdir feature you requested a couple of years ago. That stumped me for a while. > At any rate, I'm > debating about making bison a show-stopper for the release of m4 1.6 (ie. I'm > reluctant to release m4 1.6 today, since it would mean the latest released > versions of bison and m4 would be incompatible). If I just patch Bison as I described above and then push Bison 2.4 out, you could then release m4 1.6. However, I had hoped to wait longer before 2.4 for several reasons: more user feedback on 2.3b, documenting XML support, and fixing some internationalization problems (the error messages we moved/added to the skeletons are the most difficult problem). Maybe these things (except the recent internationalization bug report) will just have to wait for 2.5. > Also, I'm considering making m4 1.6 treat the -d command-line option in a > position-dependent manner. Sure, we can fix that too. But why not give it a different name in order not to break backward compatibility? Just a thought. I'm not too concerned for Bison here because --trace is undocumented for users. > Meanwhile, bison uses a check for m4 1.3's ability to use frozen files > (m4/m4.m4, also borrowed from autoconf), even though bison itself does not > appear to use frozen files. I don't know how well the current BSD m4 would > fare with bison's m4 usage patterns Bison's README says Bison requires GNU M4. (But I've been meaning to update it to say 1.4.6 as we've been saying in release announcements.) > I am willing to file copyright papers and help in the effort of updating > bison's usage of m4sugar, if you would like, since I maintain GNU m4 and made > the bulk of the autoconf m4sugar improvements over the past 3 years. Thanks! Actually, we probably need to do copyright papers for you anyway because of your previous patch. However, of the issues you've mentioned, updating m4sugar seems like the least pressing. We can handle it gradually if it turns out to be difficult.
