Re: Bison and automake together

2010-11-06 Thread Paulo J. Matos
Andrew W. Nosenko andrew.w.nose...@gmail.com writes:


 Therefore, there is no need neither AC_PROG_YACC nor ylwrap.  Just
 need move them away, don't use them.  Anyway, if byacc (for example)
 will be found and cough, it won't process GLR-targeted .y source
 anyway.  Just threat bison like would be threated any another custom
 (unsupported especially by autoconf/automake) preprocessing tool.

 The same related to the classic Lex vs. Flex.

I understand your opinion, unfortunately it then means that there's no
support for Bison in C++ mode from the automake side which is
unfortunate. :-/

-- 
PMatos




Re: Bison and automake together

2010-11-06 Thread Paulo J. Matos
pocma...@gmail.com (Paulo J. Matos) writes:


 I understand your opinion, unfortunately it then means that there's no
 support for Bison in C++ mode from the automake side which is
 unfortunate. :-/

I decided to forget automake support and instead go for my own:
So, I removed AC_PROG_YACC from configure.ac and added:
,
| AC_PATH_PROG([BISON], [bison])
`

Then in Makefile.am:
,
| BISON_HEADER = scgparser.tab.hh
| BISON_GENERATED = scgparser.tab.cc $(BISON_HEADER)
| COMMON_OBJS = scgparser-driver.cc scgparser.yy scglexer.l \
|   $(BISON_GENERATED)
| 
| bin_PROGRAMS = scgc scgdoc scgmc
| 
| scgc_SOURCES = scgc.cc $(COMMON_OBJS)
| 
| $(BISON_GENERATED): scgparser.yy
|   $(BISON) --defines=$(BISON_HEADER) $
`


But then I get this annoying:
,
| Makefile.am: Yacc (C++) source seen but `YACC' is undefined
| Makefile.am:   The usual way to define `YACC' is to add `AC_PROG_YACC'
| Makefile.am:   to `configure.ac' and run `autoconf' again.
| make: *** [Makefile.in] Error 1
`

Does someone confirm that there is a bug here?
Bison in C++ mode with -y compatibility mode generates a file which
includes y.tab.h. ylwrap _cannot_ rename the file or compilation will
fail. If C++ is supported there's a problem with ylwrap. If it's not
supported then Yacc shouldn't display the error and abort the build.

Am I right?

-- 
PMatos




Re: Bison and automake together

2010-11-06 Thread Pippijn van Steenhoven
On Sat, Nov 06, 2010 at 04:37:26PM +, Paulo J. Matos wrote:
 Does someone confirm that there is a bug here?
 Bison in C++ mode with -y compatibility mode generates a file which
 includes y.tab.h. ylwrap _cannot_ rename the file or compilation will
 fail. If C++ is supported there's a problem with ylwrap. If it's not
 supported then Yacc shouldn't display the error and abort the build.

In my opinion, ylwrap should gain knowledge about the used yacc
implementation and pass a -o to it if the implementation supports it.
That way, line numbers will be correct (aids debugging), header file
inclusions will be correct (solves your problem) and it automatically
allows for multiple yacc files to coexist in one project.

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature


Re: Bison and automake together

2010-11-06 Thread Philip Herron
You can look at the problem in 2 ways, really you can say ylwrap is
too simplistic and not great which is correct but it does work for
standard-ish inputs like C parsers. But c++ and GLR doesnt work right
but you could say they dont comform to the standard way ylwrap expects
so it fails.

I do want to start to look into this problem with ylwrap and automake
support this week something i;ve been meaning to do for about a year
or so but havent had the time untill about now. I have some old
projects which had multiple lexer's and parsers and ylwrap could help
more in this regard which it doesnt there are tricks you can search
the mailing list for old posts about this though.

--Phil

On 6 November 2010 17:06, Pippijn van Steenhoven pip8...@gmail.com wrote:
 On Sat, Nov 06, 2010 at 04:37:26PM +, Paulo J. Matos wrote:
 Does someone confirm that there is a bug here?
 Bison in C++ mode with -y compatibility mode generates a file which
 includes y.tab.h. ylwrap _cannot_ rename the file or compilation will
 fail. If C++ is supported there's a problem with ylwrap. If it's not
 supported then Yacc shouldn't display the error and abort the build.

 In my opinion, ylwrap should gain knowledge about the used yacc
 implementation and pass a -o to it if the implementation supports it.
 That way, line numbers will be correct (aids debugging), header file
 inclusions will be correct (solves your problem) and it automatically
 allows for multiple yacc files to coexist in one project.

 --
 Pippijn van Steenhoven

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iEYEARECAAYFAkzVizIACgkQJc+zqGNdDgpmjgCgu153EM4ifKlkiVpb6EJdLJXx
 qigAn1HrC+EPynBJ96qty403O2aSudTO
 =r5cg
 -END PGP SIGNATURE-





Re: Bison and automake together

2010-11-02 Thread Paulo J. Matos
Philip Herron redbr...@gcc.gnu.org writes:

 Yeah this all seems like a bug to me, i dont do much C++ i prefer to
 use C so i havent used C++ bison parsers et'al . But yeah i have a few
 work arounds to get multiple bison and flex working i have some work i
 want to do to ylwrap to help it all but i really haven't got the time
 at the moment. Basically it could all be fixed with automake had more
 control over ylwrap or make ylwrap more dumb just makes things easier.

Should we get this reported as a bug for automake?
For now a workaround is not to rename the .h file at all. Use y.tab.h
and that's it. Or if you want to use scgparser.h instead then just have 
#include y.tab.h inside scgparser.h

That should do the trick. It would nice, however to get this sorted out
in automake.

Cheers,

-- 
PMatos




Re: Bison and automake together

2010-11-02 Thread Philip Herron
To be honest i think its more of a problem of the code bison is
generating, though i should look into what happens in GLR parser and
C++ i want to see for myself to judge it. But i do feel its on the
bison side of things it shouldnt assume the name of the header and
auto include. I assume though that GLR parsers and C++ parsers have
the head declarations where you would generally include this manually
yourself.

--Phil

On 2 November 2010 08:44, Paulo J. Matos pocma...@gmail.com wrote:
 Philip Herron redbr...@gcc.gnu.org writes:

 Yeah this all seems like a bug to me, i dont do much C++ i prefer to
 use C so i havent used C++ bison parsers et'al . But yeah i have a few
 work arounds to get multiple bison and flex working i have some work i
 want to do to ylwrap to help it all but i really haven't got the time
 at the moment. Basically it could all be fixed with automake had more
 control over ylwrap or make ylwrap more dumb just makes things easier.

 Should we get this reported as a bug for automake?
 For now a workaround is not to rename the .h file at all. Use y.tab.h
 and that's it. Or if you want to use scgparser.h instead then just have
 #include y.tab.h inside scgparser.h

 That should do the trick. It would nice, however to get this sorted out
 in automake.

 Cheers,

 --
 PMatos






Re: Bison and automake together

2010-11-01 Thread Pippijn van Steenhoven
On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote:
 Then thats probably a bug although i havent played with GLR prarsers
 in bison you may want to post this to bison-help and see what they
 say.

The thing is that bison does produce the y.tab.h header, which it then
assumes to exist and #includes. It doesn't know ylwrap renamed it. You
are supposed to say %defines myparser.h or pass bison a -o option so it
produces myparser.c and myparser.h in the first place.

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature


Re: Bison and automake together

2010-11-01 Thread Philip Herron
On 1 November 2010 10:08, Pippijn van Steenhoven pip8...@gmail.com wrote:
 On Mon, Nov 01, 2010 at 02:14:49AM +, Philip Herron wrote:
 Then thats probably a bug although i havent played with GLR prarsers
 in bison you may want to post this to bison-help and see what they
 say.

 The thing is that bison does produce the y.tab.h header, which it then
 assumes to exist and #includes. It doesn't know ylwrap renamed it. You
 are supposed to say %defines myparser.h or pass bison a -o option so it
 produces myparser.c and myparser.h in the first place.


Yep thing is though just like normal parsers with bison it doesn't
have any hard-coded includes, and with GLR i _think_ it should be the
same no? its for your bison head/field declarations section to do the
include no? And since this breaks automake compatibility it sounds
like a bug. Even though a work around exists.

--Phil



Re: Bison and automake together

2010-11-01 Thread Paulo J. Matos
Pippijn van Steenhoven pip8...@gmail.com writes:

 On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote:
 Your bison file shouldnt generate any code with includes y.tab.h. You
 must have it in your field delcarations for bison. Its only your lexer
 needs to see these bison definitions.

 It does for GLR parsers.

Also for C++ parsers, with
,
| %skeleton lalr1.cc
`

or with same results using
,
| %language C++
`

This is an annoying issue that automake should strive to either solve or
document since currently automake is not compatible with C++ bison
generated parsers it seems.

-- 
PMatos




Re: Bison and automake together

2010-11-01 Thread Paulo J. Matos
Pippijn van Steenhoven pip8...@gmail.com writes:

 I solved this problem by adding my own y.tab.h which does nothing but
 #include scgparser.h.

But unfortunately each time bison is ran, the file is overwritten it
seems. :(

-- 
PMatos




Bison and automake together

2010-10-31 Thread Paulo J. Matos
Hi,

I am slightly confused as to whether I should be posting this to the
bison or this mailing list but here it goes.

I have a bison based project which has the following definitions:
,
| BUILT_SOURCES = scgparser.h
| AM_YFLAGS = -d
| AM_LDFLAGS = -lgmpxx -lgmp
| 
| bin_PROGRAMS = scgc
| 
| scgc_SOURCES = scgc.cc scgparser-driver.cc scgparser.yy scglexer.l
`

When I ran this with ./configure  make I get:
,
| /bin/bash ./ylwrap scgparser.yy y.tab.c scgparser.cc y.tab.h \
|   scgparser.h y.output scgparser.output -- bison -y  -d
`

This is ok because bison generates y.tab.c and y.tab.h that are renamed
by ylwrap as scgparser.cc and scgparser.h respectively.

However, bison generated parser scgparser.cc includes y.tab.h (which was
the name known to bison when the file was generated). This results in
an error during compilation since there is no y.tab.h anymore when the
scgparser.cc is compiled. What am I missing here? 

Feel free to redirect me to the bison mailing list if this is not an
automake config problem.

Cheers,

-- 
PMatos




Re: Bison and automake together

2010-10-31 Thread Philip Herron
On 30 October 2010 11:46, Paulo J. Matos pocma...@gmail.com wrote:
 Hi,

 I am slightly confused as to whether I should be posting this to the
 bison or this mailing list but here it goes.

 I have a bison based project which has the following definitions:
 ,
 | BUILT_SOURCES = scgparser.h
 | AM_YFLAGS = -d
 | AM_LDFLAGS = -lgmpxx -lgmp
 |
 | bin_PROGRAMS = scgc
 |
 | scgc_SOURCES = scgc.cc scgparser-driver.cc scgparser.yy scglexer.l
 `

 When I ran this with ./configure  make I get:
 ,
 | /bin/bash ./ylwrap scgparser.yy y.tab.c scgparser.cc y.tab.h \
 |           scgparser.h y.output scgparser.output -- bison -y  -d
 `

 This is ok because bison generates y.tab.c and y.tab.h that are renamed
 by ylwrap as scgparser.cc and scgparser.h respectively.

 However, bison generated parser scgparser.cc includes y.tab.h (which was
 the name known to bison when the file was generated). This results in
 an error during compilation since there is no y.tab.h anymore when the
 scgparser.cc is compiled. What am I missing here?

 Feel free to redirect me to the bison mailing list if this is not an
 automake config problem.


Your bison generated header also gets renamed by ylwrap, and yeah this
is probably the best place to ask about this problem your bison header
(y.tab.h) will get renamed to the same name as your bla.y but changed
to bla.h.

Notice the make line you posted was scgparser.cc y.tab.h scgparser.h
See the y.tab.h then scgparser.h.

Hope this helps!

--Phil



Re: Bison and automake together

2010-10-31 Thread Pippijn van Steenhoven
Hi,

On Sat, Oct 30, 2010 at 11:46:25AM +0100, Paulo J. Matos wrote:
 However, bison generated parser scgparser.cc includes y.tab.h (which was
 the name known to bison when the file was generated). This results in
 an error during compilation since there is no y.tab.h anymore when the
 scgparser.cc is compiled. What am I missing here? 

I solved this problem by adding my own y.tab.h which does nothing but
#include scgparser.h.

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature


Re: Bison and automake together

2010-10-31 Thread Paulo J. Matos
Philip Herron redbr...@gcc.gnu.org writes:

 Your bison generated header also gets renamed by ylwrap, and yeah this
 is probably the best place to ask about this problem your bison header
 (y.tab.h) will get renamed to the same name as your bla.y but changed
 to bla.h.

 Notice the make line you posted was scgparser.cc y.tab.h scgparser.h
 See the y.tab.h then scgparser.h.


I know, but that is not the problem. The problem is that the bison
generated file includes y.tab.h but this doesn't exist since, as you
said, ylwrap renames it.

-- 
PMatos




Re: Bison and automake together

2010-10-31 Thread Paulo J. Matos
Pippijn van Steenhoven pip8...@gmail.com writes:


 I solved this problem by adding my own y.tab.h which does nothing but
 #include scgparser.h.

Thanks. This sounds like a good workaround but it's far from a perfect
solution. 

-- 
PMatos




Re: Bison and automake together

2010-10-31 Thread Philip Herron
On 31 October 2010 18:49, Paulo J. Matos pocma...@gmail.com wrote:
 Philip Herron redbr...@gcc.gnu.org writes:

 Your bison generated header also gets renamed by ylwrap, and yeah this
 is probably the best place to ask about this problem your bison header
 (y.tab.h) will get renamed to the same name as your bla.y but changed
 to bla.h.

 Notice the make line you posted was scgparser.cc y.tab.h scgparser.h
 See the y.tab.h then scgparser.h.


 I know, but that is not the problem. The problem is that the bison
 generated file includes y.tab.h but this doesn't exist since, as you
 said, ylwrap renames it.


Your bison file shouldnt generate any code with includes y.tab.h. You
must have it in your field delcarations for bison. Its only your lexer
needs to see these bison definitions.

Heres some example:

http://code.redbrain.co.uk/cgit.cgi/qub-mod-c/tree/src/ss-lexer.l
http://code.redbrain.co.uk/cgit.cgi/qub-mod-c/tree/src/ss-parser.y

--Phil



Re: Bison and automake together

2010-10-31 Thread Pippijn van Steenhoven
On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote:
 Your bison file shouldnt generate any code with includes y.tab.h. You
 must have it in your field delcarations for bison. Its only your lexer
 needs to see these bison definitions.

It does for GLR parsers.

-- 
Pippijn van Steenhoven


signature.asc
Description: Digital signature


Re: Bison and automake together

2010-10-31 Thread Philip Herron
Then thats probably a bug although i havent played with GLR prarsers
in bison you may want to post this to bison-help and see what they
say.

--Phil

On 31 October 2010 23:03, Pippijn van Steenhoven pip8...@gmail.com wrote:
 On Sun, Oct 31, 2010 at 10:55:53PM +, Philip Herron wrote:
 Your bison file shouldnt generate any code with includes y.tab.h. You
 must have it in your field delcarations for bison. Its only your lexer
 needs to see these bison definitions.

 It does for GLR parsers.

 --
 Pippijn van Steenhoven

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iEYEARECAAYFAkzN9cwACgkQJc+zqGNdDgrhqwCg4kJPoABYHKjEgSXjPd5M+5QT
 xwYAoLpUNUFTcQyVNk3U2S9uy+L7pt0P
 =rQxd
 -END PGP SIGNATURE-