[CC:ing bug-automake, so that we won't forget about the issues raised here]

Hi Akim.

On 02/15/2012 01:31 PM, Akim Demaille wrote:
> 
> Le 15 févr. 2012 à 13:18, Stefano Lattarini a écrit :
> 
>> On 02/15/2012 11:36 AM, Akim Demaille wrote:
>>> Rely on $(YACC) being the bison being built, and let Automake do the
>>> rest.  It turned out to be much more difficult than anticipated, for
>>> various reasons, including some bad behavior from Automake 1.11.2
>>> which (i) generates calc++-parser.h instead of calc++-parser.hh,
>>>
>> FYI: this will be fixed in automake 1.12 -- the patch fixing it being
>> already merged into master.
> 
> Thanks Stefano!
> 
> I can't clone automake right now (Savannah seems to be overloaded),
> so I can't check the following typo in the current documentation.
> It should take you only a couple of seconds to check.
> 
>>    ---------- Footnotes ----------
>>
>>    (1) Please note that `automake' recognizes `-d' in `AM_YFLAGS' only
>> if it is not clustered with other options; for example, it won't be
>> recognized if `AM_YFLAGS' is `-dt', but it will be if `AM_YFLAGS' is
>> `-d -t' or `-d -t'
> 
> I guess the latter is `-t -d', and the period is missing.
>
Thanks, fixed (see attached patch).

> But maybe automake no longer needs this?
>
It still need it; without that, no header file will be generated from
the '.y' files (this is a feature, not a bug).

> If it does, it would be good to recognize also --defines.
> 
Maybe; but then, it should be done right, i.e., automake should also
understand hand handle the '--defines=my-hdr.h' usage.  But I guess
this would conflict with ylwrap in some way, sigh :-(

Maybe it's truly time to introduce a new AM_PROG_BISON macro that
will cause automake to drop all the cruft related to POSIX yacc
compatibility ...  As usual, patches welcome ;-)

Regards,
  Stefano