automake
[Top][All Lists]
Advanced

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

Re: Problems with linking multiple lex/yacc parsers into one executable


From: Hans Nieser
Subject: Re: Problems with linking multiple lex/yacc parsers into one executable
Date: Sun, 17 May 2009 14:49:38 +0200

On Sun, 2009-05-17 at 13:46 +0200, Ralf Wildenhues wrote:
> Hello,
> 
> * Philip Herron wrote on Sun, May 17, 2009 at 12:49:32PM CEST:
> > 
> > I solved this problem a while back!
> > 
> > http://lists.gnu.org/archive/html/automake/2009-04/msg00095.html
> > 
> > The trick is in each of your lexers(flex .l) add this:
> > %option prefix="prefix" outfile="lex.yy.c"
> 
> I don't see %option documented in POSIX (looking at SUSv3).
> Are you sure your solution is portable to non-flex lex?  If not, then
> please reconsider praising it as a portable solution.
> 
> > Dont change the outfile ylwrap needs it to be lex.yy.c!
> 
> If the example in the Automake manual needs fixing, then we should
> fix it, so that it really works.  However, somebody needs to do the
> work and find and test it.  It should be added to the Automake test
> suite.
> 
> I can do testing on various systems but working on the example is
> not high in my priority list because I do not know lex well.
> 
> Cheers,
> Ralf

(I am somewhat of a newbie with all these tools so don't take anything I
say below for granted)

To be completely portable (not depending on flex options) I don't think
either the prefix/outfile options or the prefix commandline option can
be given to lex (they are not mentioned in lex(1p) at least).

So then the only way then to link multiple lex/yacc parsers into a
single executable without conflicting symbols is to use the list of
defines for lex. But since you can't add these in the lex source itself
(because lex - or flex at least - emits some symbols before user code
sections), I was only able to make this method work by including the
output from lex in the yacc source and put the defines in the yacc
source. This is exactly what gdb does with their parsers as far as I can
tell.

But this conflicts with automake's idea of how to compile lex/yacc
sources, as it will try to compile the lex output to an object, without
the symbols redefined and that is where the suggested solution in the
manual breaks down for me.

One solution would be if there was a way to tell automake to only
generate the C source from the lex source (not attempt to compile it),
and that compilation of the yacc parser depends on the lex output.

In that case the manual would only need to be updated on how that is
accomplished but should otherwise still be correct. That, and maybe an
update to the listed defines since that is only really about just using
yacc, not in tandem with lex, as I had to extend the list with these
(lex?) symbols:

#define yyin                fooyy_in
#define yyout               fooyy_out
#define yywrap              fooyy_wrap
#define yylineno            fooyy_lineno
#define yy_flex_debug       fooyy_flex_debug
#define yy_create_buffer    fooyy_create_buffer
#define yy_flush_buffer     fooyy_flush_buffer
#define yy_switch_to_buffer fooyy_switch_to_buffer
#define yy_delete_buffer    fooyy_delete_buffer
#define yypush_buffer_state fooyy_push_buffer_state
#define yypop_buffer_state  fooyy_pop_buffer_state
#define yy_scan_buffer      fooyy_scan_buffer
#define yy_scan_string      fooyy_scan_string
#define yy_scan_bytes       fooyy_scan_bytes
#define yylex_destroy       fooyy_lex_destroy
#define yyget_lineno        fooyy_get_lineno
#define yyget_in            fooyy_get_in
#define yyget_out           fooyy_get_out
#define yyget_leng          fooyy_get_leng
#define yyget_text          fooyy_get_text
#define yyget_debug         fooyy_get_debug
#define yyset_lineno        fooyy_set_lineno
#define yyset_in            fooyy_set_in
#define yyset_out           fooyy_set_out
#define yyset_debug         fooyy_set_debug
#define yyrestart           fooyy_restart
#define yyalloc             fooyy_alloc
#define yyrealloc           fooyy_realloc
#define yyfree              fooyy_free







reply via email to

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