Re: ylwrap - flex filename weirdness
On Sun, Oct 31, 2010 at 11:54:04AM +0100, Jan Engelhardt wrote: > Hi, > > > While trying to utilize Autotools in a preexisting project that > previously just relied on Makefiles, I came across ylwrap failing for > some absurd, unknown reason. I couldn't help but run sh -x and debug it > piecewise. > > So what's ultimately done is running flex inside a temp directory, > > flex /home/jengelh/code/iproute2/tc/emp_ematch_lex.l > > It turns out flex produces a file called lex.ematch_.c, which is > something ylwrap so does not expect at all - it only checks for > what's in pairlist="yy.lex.c emp_ematch_lex.c". > > I can use AM_LFLAGS = -o yy.lex.c to work around it, but that feels like > an ugly hack. What's up with flex here? You added a prefix "ematch_" in your flex source file. ylwrap doesn't like that. In fact, ylwrap doesn't like multiple parsers in one project, at all... and it doesn't bother renaming flex-generated header files, either. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: ylwrap - flex filename weirdness
On Sunday 2010-10-31 16:42, Philip Herron wrote:
>>
>> While trying to utilize Autotools in a preexisting project that
>> previously just relied on Makefiles, I came across ylwrap failing for
>> some absurd, unknown reason. I couldn't help but run sh -x and debug it
>> piecewise.
>>
>> So what's ultimately done is running flex inside a temp directory,
>>
>> flex /home/jengelh/code/iproute2/tc/emp_ematch_lex.l
>>
>> It turns out flex produces a file called lex.ematch_.c, which is
>> something ylwrap so does not expect at all - it only checks for
>> what's in pairlist="yy.lex.c emp_ematch_lex.c".
>>
>> I can use AM_LFLAGS = -o yy.lex.c to work around it, but that feels like
>> an ugly hack. What's up with flex here?
>
>Ylwrap renames your Lex and Yacc files to their respective names.{c,h}> So if your lexer was foo.l it would output foo.c not
>lex.yy.c which is what your expecting.
I'm not expecting anything, ylwrap is. For this very rename that
ylwrap is supposed to do, it is expecting to see lex.yy.c or
.c from the flex subcommand it calls, but never gets
that.
Re: ylwrap - flex filename weirdness
On 31 October 2010 10:54, Jan Engelhardt wrote: > Hi, > > > While trying to utilize Autotools in a preexisting project that > previously just relied on Makefiles, I came across ylwrap failing for > some absurd, unknown reason. I couldn't help but run sh -x and debug it > piecewise. > > So what's ultimately done is running flex inside a temp directory, > > flex /home/jengelh/code/iproute2/tc/emp_ematch_lex.l > > It turns out flex produces a file called lex.ematch_.c, which is > something ylwrap so does not expect at all - it only checks for > what's in pairlist="yy.lex.c emp_ematch_lex.c". > > I can use AM_LFLAGS = -o yy.lex.c to work around it, but that feels like > an ugly hack. What's up with flex here? > Ylwrap renames your Lex and Yacc files to their respective So if your lexer was foo.l it would output foo.c not lex.yy.c which is what your expecting. Here is a Makefile.am snippet of a basic compiler i write a while back: bin_PROGRAMS= cmod$(EXEEXT) noinst_LIBRARIES = libparser.a AM_CPPFLAGS = -I$(top_srcdir)/include AM_YFLAGS = -d cmod_SOURCES = \ mm-cmod.c \ dd-util.c \ dd-vec.c \ ii-toplev.c \ ii-mod-dot.c \ bb-linux-i386.c cmod_LDADD = libparser.a libcparser_a_YFLAGS = -d libparser_a_CFLAGS = -DMOD -DPARSER libparser_a_SOURCES = ss-parser.y ss-lexer.l Hope this helps. --Phil
ylwrap - flex filename weirdness
Hi, While trying to utilize Autotools in a preexisting project that previously just relied on Makefiles, I came across ylwrap failing for some absurd, unknown reason. I couldn't help but run sh -x and debug it piecewise. So what's ultimately done is running flex inside a temp directory, flex /home/jengelh/code/iproute2/tc/emp_ematch_lex.l It turns out flex produces a file called lex.ematch_.c, which is something ylwrap so does not expect at all - it only checks for what's in pairlist="yy.lex.c emp_ematch_lex.c". I can use AM_LFLAGS = -o yy.lex.c to work around it, but that feels like an ugly hack. What's up with flex here? thanks, Jan
