Automake yacc support, GNU bison, and non-standard generated headers (was: Re: bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton)

[Stefano Lattarini]

[adding automake list in CC]

Recovering an oldish thread, as it seems we might be near to the
solution of this (only apparently simple) bug ...

For reference, see:
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648>

On Wednesday 05 January 2011, Stefano Lattarini wrote:
> On Wednesday 05 January 2011, James Bostock wrote:
> > On Tue, Jan 4, 2011 at 11:36 PM, Stefano Lattarini wrote:
> > >
> > > JFTR, here is how that happens.  The ylwrap script works by doing a
> > > chdir into a temporary directory, calling yacc from there, renaming
> > > and editing the generated files, and then moving them back to the
> > > original directory.  In your case, since ylwrap knows nothing about
> > > the bison-generated 'stack.hh' and 'location.hh' header files, it
> > > doesn't copy them back in the original directory, so that they are
> > > lost when the temporary directory is removed.  D'oh!
> > >
> > > I'm still undecided if at this point we should just (try to) rewrite
> > > the messy ylwrap script, or if it would be better to teach automake
> > > to recognize when it's using bison as $(YACC), and take advantage of
> > > more bison features in this case -- which would probably allow to
> > > bypass the use of ylwrap altogether.
> > 
> > For what it's worth, I think the preferable solution would be to add
> > an AM_BISON macro to detect the presence of bison and, if it is
> > present, not use ylwrap at all as, unless in compatability mode,
> > bison's output files are named after the input grammar file anyway,
> > obviating the need for ylwrap.
> >
Well, not quite.  The ylwrap script has the nifty feature of avoiding to
update the timestamp of generated headers if their content hasn't changed
(to avoid unnecessary recompilation), while bison seems to update them
unconditionally.  I hadn't thought about this originally; luckily this
behaviour is covered by the testsuite, which saved me from introducing a
regression.

Also, the Makefile fragments generated by the Yacc support in Automake have
the ability to deal with the "deleted header problem" automatically for the
standard "y.tab.h" file.  It would be nice if they were able to do so also
for non-standard headers (with as small help from the developer as possible).

> Hmm... I agree, especially because most of the problems of ylwrap derive
> anyway from the use of bison-specific flags and features.
>
Now I don't agree with myself anymore :-)

I decided that, after all, the best thing to do was to rewrite the messy
ylwrap script; after some work, I've now reached a point where I think
we could safely add, without too much hassle, a new feature, that will
allow the developer to specify a list of extra headers generated by a
yacc call.

I'm not yet sure about the syntax to use for this new feature, though;
I was thinking about sometinh on the lines of:

  bin_PROGRAMS = zardoz
  zardoz_SOURCES = zardoz.yy
  zardoz_YFLAGS = -d --skeleton lalr1.cc
  EXTRA_zardoz_YACC_HEADERS = stack.hh location.hh position.hh

but I'd like to hear more ideas and opinions on this matter before
proceeding.

-*-*-

JFTR, the git branch where the work on the ylwrap rewrite is taking
place can be found here:

 <http://git.savannah.gnu.org/cgit/automake.git/log/?h=ylwrap-refactor>

-*-*-

Regards,
  Stefano