Re: outdated m4sugar

[Joel E. Denny]

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.