this
behaviour is covered by the testsuite, which saved me from introducing a
regression.
Also, the Makefile fragments generated by the Yacc support in Automake have
the ability to deal with the deleted header problem automatically for the
standard y.tab.h file. It would be nice if they were able to do so
[ dropping the PR Cc: ]
* Stefano Lattarini wrote on Fri, Jan 07, 2011 at 11:50:51PM CET:
On Friday 07 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Fri, Jan 07, 2011 at 03:36:43PM CET:
Currently, automake is not smart enough to resolve variable expansions
in
* Stefano Lattarini wrote on Fri, Jan 07, 2011 at 11:50:51PM CET:
Subject: [PATCH 2/2] yacc: support variable expansions in *YFLAGS definition.
This commit fixes automake bug#7800.
OK with nits addressed.
Thanks!
Ralf
* automake.in (lang_yacc_target_hook): Use 'value_as_list_recursive
On Saturday 08 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Fri, Jan 07, 2011 at 11:50:51PM CET:
Subject: [PATCH 2/2] yacc: support variable expansions in *YFLAGS
definition.
This commit fixes automake bug#7800.
OK with nits addressed.
Thanks!
Ralf
312acec17badbf428abf3961e081004c721b5323 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 7 Jan 2011 21:52:56 +0100
Subject: [PATCH 2/2] yacc: support variable expansions in *YFLAGS definition.
This commit fixes automake bug#7800.
* automake.in (lang_yacc_target_hook): Use
312acec17badbf428abf3961e081004c721b5323 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 7 Jan 2011 21:52:56 +0100
Subject: [PATCH 2/2] yacc: support variable expansions in *YFLAGS definition.
This commit fixes automake bug#7800.
* automake.in (lang_yacc_target_hook): Use
. They are
Good Enough[tm].
IMHO they're not. See just below.
The incremental gain from more change is not worth the additional
work from you nor review from me.
Actually, lex and yacc support has *several* *real* issues, with maybe
more than a dozen reported bugs in the last few
* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 03:33:32PM CET:
On Friday 17 December 2010, Ralf Wildenhues wrote:
The *current* tests are good enough for the current code.
Yes, but not enough if we plan to modify that code
You can add tests as you go modifying the code. Doing that is
and yacc support has *several* *real* issues, with maybe
more than a dozen reported bugs in the last few years, many of them
unfixed. See the list archives. It would be really nice if somebody
who knows their ways around bison/yacc and flex/lex well (or is willing
to learn) could look into some
of such
conversions: Please don't work even more on *these* tests. They are
Good Enough[tm].
IMHO they're not. See just below.
The incremental gain from more change is not worth the additional
work from you nor review from me.
Actually, lex and yacc support has *several* *real* issues, with maybe
more
.
Actually, lex and yacc support has *several* *real* issues, with maybe
more than a dozen reported bugs in the last few years, many of them
unfixed. See the list archives.
Yes, but I woldn't dare trying to modify the Lex/Yacc related code with
the limited understanding I have of it, without having
) if
there are no objections.
Regards,
Stefano
From 020eadb092b2ab9fce4adbe89eab784b056eb0ce Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 7 May 2010 15:07:37 +0200
Subject: [PATCH] Extend, fix and improve tests on Lex and Yacc support.
* tests/lexcpp.test: New
Hi Stefano,
* Stefano Lattarini wrote on Thu, Sep 16, 2010 at 06:34:06PM CEST:
While trying to improve and extend test `mmodely.test', I stumbled
upon the bug exposed by the attached test script (weird bug, BTW:
it's triggered with GNU make and FreeBSD make, but not with Solaris
make; role
Hello Automakers.
While trying to improve and extend test `mmodely.test', I stumbled
upon the bug exposed by the attached test script (weird bug, BTW:
it's triggered with GNU make and FreeBSD make, but not with Solaris
make; role reversal for once ;-).
I suspect the bug is due to some incomplete
and Yacc support.
* tests/lexcpp.test: New test script, on support for Lex + C++.
* tests/lexvpath.test: New test script, test build and rebuild
rules for lexers in VPATH setup.
* tests/yacc1.test: New test scripte, run simple semantic
checks on basic Yacc support (similarly to what lex3.test does
this message in context:
http://www.nabble.com/Yacc-Support--tf3332417.html#a9266040
Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
== kj1nabble [EMAIL PROTECTED] writes:
Any thoughts? I think it has something to do with how I set up my bin in
Makefile.am.
You don't say how it failed...
bin_PROGRAMS = app
lc_SOURCES = l.l app.c g.y appgen.c
You either want to have 'bin_PROGRAMS = lc', or you want to name your
On Sat, Nov 09, 2002 at 01:39:16PM +0200, Alexandros Karypidis wrote:
Hi all,
[W]henever I change my bison file to add a %token, I have to run make TWICE to
get a correct build. This is because the header file with token declarations
which is generated when yacc is run, also affects the
Hi all,
I am unsatisfied with the Makefile.am I have built, due to the fact that
whenever I change my bison file to add a %token, I have to run make TWICE to
get a correct build. This is because the header file with token declarations
which is generated when yacc is run, also affects the
19 matches
Mail list logo
