Re: outdated m4sugar

[Joel E. Denny]

On Fri, 11 Jul 2008, Eric Blake wrote:

> | 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.

Ok.  The m4wrap fix works fine on that branch too.

> | 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.

> I
> haven't decided yet whether I should add it to the 1.6 branch

I've updated my m4sugar.m4 patch to rename whichever of m4symbols or 
symbols is defined, so this should work in all cases.

> | 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.
> 
> For now, -g is also not implemented in m4 1.6.  I'm opposed to having to
> make bison unset POSIXLY_CORRECT - the (masochistic) users who set it do
> so for a reason, and we shouldn't second-guess them (in particular,
> consider what happens if the user wants POSIXLY_CORRECT to affect the
> grandchild processes run via syscmd).

I agree that -g is the better solution for the long term.  However, syscmd 
only matters to Bison users who write their own skeletons.  At the moment, 
Bison makes no promises about the behavior of custom skeletons, so this 
effect is not something to worry about, I think.

> the other hand, I don't want the expense of a runtime check in every bison
> run to find out whether m4 supports -g.     

You believe the expense of an "m4 -g" invocation would be noticeable in 
comparison to the subsequent m4 invocation for a skeleton?  I haven't 
tried it yet, but I would've guessed no.

> Maybe I should just add -g as a no-op to 1.6, since POSIXLY_CORRECT is a
> no-op there.  Then, we do the following release scheduling, so that at all
> times, the latest stable release of bison and m4 are compatible:
> 
> bison 2.4 - does not use -g, always works with m4 1.4.x and 1.6, but only
> works with 2.0 when POSIXLY_CORRECT is not set, behind-the-scene upgrade
> from m4 1.4.x to 1.6 is safe but not from 1.6 to 2.0
> 
> m4 1.6 - works with bison 2.4 and newer
> 
> bison xxx - requires at least m4 1.6 and always works with 2.0, blindly
> uses -g (even when it is a no-op), behind-the-scene upgrade from m4 1.6 to
> 2.0 is safe
> 
> m4 2.0 - works with bison xxx and newer

Unsetting POSIXLY_CORRECT or checking for -g in Bison 2.4 seems simpler, 
and I'm not seeing the harm.  We would do this in anticipation of an 
m4/Bison combination that will need it.  We can switch to -g (with no 
test) in a later Bison release after m4 1.6 (or wherever you introduce -g) 
has been around for a while.

> |  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.
> 
> There's still several things I want in m4 1.6; so I'm guessing at least
> another month before I'm ready to go.

Well, we can just push out whatever we have ready by then.

BTW, what is your opinion on how Bison should handle translation of error 
messages generated by the skeletons?  Paolo Bonzini proposed the following 
patch a while back:

  http://lists.gnu.org/archive/html/bison-patches/2007-01/msg00112.html

Akim seemed to like it but felt autom4te or m4 should implement something 
like it instead of Bison.

> | 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.)
> 
> What does 1.4.6 provide that 1.4.5 doesn't?  In other words, why the
> discrepency between what autoconf requires and what bison requires, and
> should autoconf be similarly bumped to 1.4.6?  And let's fix m4/m4.m4 to
> actually require 1.4.6, rather than its (outdated) test that lets m4 1.3
> be selected.

I copied that requirement from Paul Eggert's announcements for previous 
releases of Bison.  He may be of more help here.

> |> 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.
> 
> My previous patch falls under the trivial rules,

I had forgotten it was short enough... probably because I remembered it as 
being conceptually non-trivial.

> but I'm already starting
> the paperwork process.

Great!

Thanks.