bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/6] api.value.type support


From: Akim Demaille
Subject: Re: [PATCH 0/6] api.value.type support
Date: Mon, 25 Feb 2013 14:26:51 +0100

Le 25 févr. 2013 à 13:37, Stefano Lattarini <address@hidden> a écrit :

> Hi Akim.

Hi!

>> Actually, it is
>> rather Autoconf which is a PITA here, that's it that decides
>> to define 'YACC=bison -y'.
>> 
> ... but I see you already knew that :-) I think this should brought up to
> the autoconf list, to decide if, when and how the '-y' could be dropped;

We already did that a couple of time, but it seems to be stuck.

http://lists.gnu.org/archive/html/autoconf/2012-06/msg00049.html

I also reenabled a bug report on Automake about this.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11419

> Automake-based package will then automatically benefit from the Autoconf
> improvement (if it is eventually deemed to be an improvement, and not
> just a possible source for backward-incompatibilities).

Sure.

> The real question for Automake is: how would such a change interact with
> the 'ylwrap' script, which expects 'y.tab.h' and 'y.tab.c' as the names of
> the output files?  Hmm….

ylwrap should simply not be used at all with Bison.  It is creating
all sorts of problems (fewer today, but there are still issues).

>> Also, currently we have a (hidden) option which is a
>> synonym of --yacc:
>> 
>>  { "fixed-output-files", no_argument,  0,   'y' },
>>  { "yacc",               no_argument,  0,   'y' },
>> 
>> It should rather just change the output file names to be y.tab.c
>> and so forth, but not set -Wyacc.  And Autoconf should use it.
>> 
> I like this proposal, mostly because it wouldn't require any change
> in Automake ;-)

I do understand that :)

> As an aside, how long has that hidden option been present in Bison?
> If the answer is not "practically since forever",

Since the initial checkin from RMS.

struct option longopts[] =
{
  {"debug", 0, &debugflag, 1},
  {"defines", 0, &definesflag, 1},
  {"file-prefix", 1, 0, 'b'},
  {"fixed-output-files", 0, &fixed_outfiles, 1},
  {"name-prefix", 1, 0, 'a'},
  {"no-lines", 0, &nolinesflag, 1},
  {"output", 1, 0, 'o'},
  {"output-file", 1, 0, 'o'},
  {"verbose", 0, &verboseflag, 1},
  {"version", 0, 0, 'V'},
  {"yacc", 0, &fixed_outfiles, 1},
  {0, 0, 0, 0}
};


> the new Autoconf
> could will also have to check that the available bison program
> actually supports it …

Yet so far --fixed-output-file is a synonym for --yacc.
This can be changed now, for the next release.

>> Meanwhile there is one way out: have people pass -Wno-yacc to their
>> flags.

So far --yacc/--fixed-output-file triggers the following changes:
- -Werror=yacc is enabled
- we use "#define TOKEN…" in addition to "enum { TOKEN … }"
- output names are y.tab.h, y.tab.c, and y.output
- a missing `;' will not added to the end of the actions

This last "feature" is deprecated, and actually I think I will
remove it just now.  There was a deprecation message for a
while, and I had not realized that -y disabled this feature
anyway, so really there's no point in keeping it.  Bison
3.0 is already dropping support for ancient features, so now
is no worse that 3.1.


Actually I just found what could arguable called a bug in
Bison:

> $ ls f.y
> f.y
> $ bison -o y.tab.c -d -v f.y
> $ ls y.*
> y.output      y.tab.c         y.tab.h

where I would have expected "y.tab.output".  Fortunately this
is also what Automake/Autoconf expect.  So, if instead of -y
Autoconf were using '-o y.tab.c', everybody would be happy.

And then --yacc = '-Werror=yacc -o y.tab.c'.  I'd be happy
to avoid making --fixed-output-file public again, it's
useless.

WDYT?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]