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

[Akim Demaille]

Hi all,

Le 25 juin 2012 à 11:30, Stefano Lattarini a écrit :

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

But in any case, ylwrap must also be fixed, if people still
want to stick to it.  And, BTW, glr parsers, C++ parsers
etc. are broken by ylwrap currently as they all use a
header and depend upon it.

A future version of bison will use it too for plain parsers.
People stuck with an old Automake can make a "y.tab.h" file
that just #includes "the-right-header.h" to work around the
issue.

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

[Stefano Lattarini]

Reference:


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