Subject: Re: ylwrap does not rename y.tab.h in y.tab.c

From: Stefano Lattarini <[email-masked]>
Date: Mon, 25 Jun 2012 11:30:18 +0200

Reference:
<http://lists.gnu.org/archive/html/bug-bison/2012-06/msg00032.html>

On 06/25/2012 10:25 AM, Akim Demaille wrote:
> 
> Le 20 juin 2012 à 07:26, Akim Demaille a écrit :
> 
>>
>> Le 15 juin 2012 à 13:34, Akim Demaille a écrit :
>>
>>> I installed it, and some more tests, in maint, as follows.
>>
>>>
>>> From 0f11eec272453d5646e5aeda135650b4fb8ac33d Mon Sep 17 00:00:00 2001
>>> From: Akim Demaille <[email-masked]>
>>> Date: Tue, 12 Jun 2012 16:15:14 +0200
>>> Subject: [PATCH 1/2] yacc.c: instead of duplicating y.tab.h inside y.tac.c, include it.
>>
>> We have a problem with this change (which can be seen if
>> you make check in master): as far as I can tell, ylwrap,
>> which goes via y.tab.c and y.tab.h, does _not_ change the
>> occurrences of y.tab.h in y.tab.c.  So in the end, the
>> parser implementation file foo.c includes y.tab.h instead of
>> foo.h.
>>
>> This is Automake 1.12.1, ylwrap 2011-08-25.18.
>>
>> Because of this, it is unclear to me whether we can leave that
>> change, users would face the same issue as bison-master :(
>> And it does not seem acceptable that Bison 2.6 mandates Automake
>> 1.12.2 or whatever.
>>
>> Any suggestion?  In particular a workaround (for Makefile.am)
>> which would work for both older and newer Automakes.
> 
> Well, I guess I must step back.  I installed what follows
> in maint.
>
Sigh, advancement on Bison kept back by the fact that Automake used to
bend over backwards to support inferior yacc implementation that today
hardly anybody is using to build an autoconfiscated package.  It's now
definitely time to implement a 'no-ylwrap' option that prevents the use
of 'ylwrap'.  IMHO this option should go in Automake 1.12.2, become the
default in Automake 1.13, and the only supported mode of operation in
Automake 1.14 (unless real users object).

Patches will follow in the next days.

> What are the versions of Automake to fix?  Should 1.11.*
> be addressed too?
>
I don't think it's worth.  People that will want their generated Makefile.in
working correctly with new Bison will upgrade to Automake 1.12.2.

> I have no idea how wide spread 1.12 is.
>
Well, if it's not much widespread, this new feature will help it become so ;-)

Thanks,
  Stefano