Dump bison

[Hal Murray]

Eric said:
>  The problem with the new-parser-generator theory is that as much fun as I'd
> have doing it, the net effect on stability and maintainability would probably
> be negative.  There's that how-do-you-know-you-specced- the-same-grammar
> problem again.

Actually, I think the stability would improve.  We would probably build a test 
harness that the current setup lacks.

There used to be code to write out the parser results.  It wrote out the 
in-memory version, not from the parser callouts.  But you could diff it with 
the input if your input was in the correct order.

When we ripped that stuff out, why didn't we add something better?  I'm 
thinking of a simple module that passes in a file name and catches all the 
callouts and stubs them with simple printfs - something off to the side rather 
than cluttering up ntpd itself.



There are several ways we could fix the warnings.

One would be to patch the generated code.  Run bison.  Edit by hand until the 
compiler is happy.  Save those edits as a patch file.  Add the patch file to 
git as source code.  Teach waf to apply the patch...  As long as the patch is 
something simple like dropping in an endcase, that's probably reasonable to 
maintain.

The simplest solution is probably John Bell's suggestion.  Hack waf to filter 
the flags used to compile the parser to not use the option that generates the 
warnings.. - even if it would be used for the rest of the compiles.


> So, in sum, I think living with a warning or two is the least bad option. The
> second least bad is that I slightly customize the Bison parser skeleton to
> make the problem go away; of course then we'd have to maintain that through
> Bison upgrades. 

I agree that living with a few warnings is probably the right approach.  At 
least for now.  But I think it's good to discuss other options.

Maintaining a fixed version of Bison seems like a bad idea.  For something 
like this, I'd expect upstream would accept a patch.  That fixes the warnings 
when a new version of Bison is released and distros adopt it.

Currently, we require Bison in the build environment.  We don't really need 
that.  We only need Bison to run on some system we have access to.  Then we 
could treat the output as source and put it in git.  It adds a layer of 
complexity that I'm happy we don't have, but it is a possibility.

The approach of saving the Bison output also applies to using a modern parser. 
 If it isn't widely available, we have the option of running it on one system 
and capturing the output to use on other systems.


-- 
These are my opinions.  I hate spam.