Re: AC_PROG_YACC question

[Bob Proulx]

> > The new version of the docs or the code or both have apparently been
> > updated.  Your version might be documented accurately.  Here is what the
> > say now.
[...]
> What's the difference with the 2.13 docs ??

You are right, it is not different.  I read the 2.13 docs wrong.

> > If automake sees a .y file in your source tree it will want to see YACC
> > set to some value in your configure.ac.  If you don't care which then just
> > call AC_PROG_YACC.  But in my case I prefer a different order.  Therefore
> > instead of AC_PROG_YACC I use the following.
> > 
> >   AC_CHECK_PROGS(YACC,byacc yacc 'bison -y',[${am_missing_run} yacc])
> 
> Looks like a nice quick fix but this doesn't seem to work with autoconf 2.13
> :-(.  The generated configure script reports that bison, byacc, yacc
> are missing but happily goes on without any other warning.

Yes, but generally the generated y.tab.c et al one one system will
work on another system.  Not always, but mostly.  Therefore the
generated C files are distributed as well as the yacc and lex source
files.  If you don't change the real source then the generated C
source is still considered valid.  In that case even if you don't have
yacc and lex on your machine you can still compile the program.  So
not having it at configure time is not necessarily fatal.

If, however, you modify the real source then at the next make you will
need to have the yacc or lex programs available on your system.  They
were not found at configure time.  But who knows, you might have
installed them by then.  The missing script will give it a shot.  If
everything works then no harm no foul.  But if there is any error at
all then the missing script will print the message then.

It would certainly be possible to fail with a fatal error in the
configure script at configure time.  But normally most packages
wouldn't need that.

I have been putting the generated C source into the MAINTAINERCLEAN
variable list in Makefile.am files.  It seems appropriate to me that I
can do a 'make maintainer-clean' at the top level and then 'bootstrap'
myself completely from source on a different system than I originally
built upon to test portability.

> I probably need to upgrade, as I have found no mention of
> am_missing_run on the files owned by my current autoconf package,
> whereas it is defined in m4/missing.m4 in autoconf 2.52.

I can't say as I found it in any documentation.  I pulled it out of
other examples of its use in /usr/share/{aclocal,autoconf,automake}!
It might not be a public interface!

> > This fulfills the need to set YACC, it looks for byacc first and then yacc
> > and then finally 'bison -y' if nothing else exists.  If nothing is found
> > it will call 'missing yacc' which prints a user level message describing
> > the problem in their development environment.
> 
> Yeah, that'd suit me fine if it worked :). I still wonder why this isn't the
> DEFAULT behavior for AC_PROG_YACC.

It works for me in 2.52.  I specifically upgraded to it for all of the
nice portability improvements and bug fixes that the folks have been
making in it.  Especially those for HP-UX.  [In case no one said so
before, Thanks!]

Bob