Re: [Patch 3/3] AC_PROG_YACC

[Akim Demaille]

>>>>> "Tim" == Tim Van Holder <address@hidden> writes:

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

Tim> True - though it doesn't make sense to me why a test for YACC
Tim> should look positive even if there is no yacc on the system.  If
Tim> a package requires YACC, AC_PROG_YACC would be the logical choice
Tim> to test this; but the current behaviour doesn't do so, it only
Tim> tries to prefer bison or byacc over plain yacc.  

I'd like it to be that simple.  It is not.

Tim> Anyway, this change was really made to match the lex macro; it's
Tim> easy enough to revert to the 'return yacc by default' behaviour.

Please, do.

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

Tim> Is 'missing' OK for use in autoconf now, or should it remain
Tim> automake-only?  

Unfortunately, it's Automake.  But forget about missing.  My point
applies equally to pure Autoconf.

Tim> I did make a companion to AM_PROG_LEX that looked for yacc using
Tim> 'missing bison' as fallback and then ran AC_PROG_YACC.  So for
Tim> missing-related use, it doesn't really matter what AC_PROG_YACC
Tim> uses as default; the AM_* macros override the program search
Tim> anyway.

AM sucks as much as HP does :) AC rulez!  More seriously, I cannot
accept: it is a not-so-fundamental-backward-incompatiblity.  please,
submit something equivalent, but not causing new errors.