[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?
- [PATCH 3/6] value type: accept "->" in type tags, (continued)
- [PATCH 3/6] value type: accept "->" in type tags, Akim Demaille, 2013/02/23
- [PATCH 2/6] style: simplify the scanning of type tags, Akim Demaille, 2013/02/23
- [PATCH 6/6] doc: api.value.type union., Akim Demaille, 2013/02/23
- [PATCH 5/6] doc: move the section about "%union" where types are discussed, Akim Demaille, 2013/02/23
- [PATCH 1/6] api.value.type: implement proper support, check, and document, Akim Demaille, 2013/02/23
- Re: [PATCH 0/6] api.value.type support (was: rename variant), Joel E. Denny, 2013/02/24