Re: [Patch 3/3] AC_PROG_YACC

[Tim Van Holder]

> I like this idea, but it lacks proper documentation, does not need to

Documntation would've been part of revision two - this was a quick draft
in order to get comments.

> be inside an macro (IMHO, LEX is different because of history, not for
> sound reasons), and also lacks the NEWS bit.  once these details

OK - I'll make a single macro of it.

> Hm... On a second tought, it is not very corret: it is backward
> incompatible.  With your patch, yacc or bison is now required.
> Before, it was not.

True - though it doesn't make sense to me why a test for YACC should
look positive even if there is no yacc on the system.  If a package
requires YACC, AC_PROG_YACC would be the logical choice to test this;
but the current behaviour doesn't do so, it only tries to prefer
bison or byacc over plain yacc.
Anyway, this change was really made to match the lex macro; it's easy
enough to revert to the 'return yacc by default' behaviour.

> This is why LEX had two :(  And IIRC, HPSux does
> lack a proper yacc.  Think of `missing' which knows how to handle this
> situation: we are really regressing here.

Is 'missing' OK for use in autoconf now, or should it remain
automake-only?  I did make a companion to AM_PROG_LEX that looked for
yacc using 'missing bison' as fallback and then ran AC_PROG_YACC.
So for missing-related use, it doesn't really matter what AC_PROG_YACC
uses as default; the AM_* macros override the program search anyway.