Thread: flex
Maybe this has been discussed before my time, but why exactly is it that we don't distribute lex'ed files, as with yacc'ed files? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Maybe this has been discussed before my time, but why exactly is it that > we don't distribute lex'ed files, as with yacc'ed files? Not sure. Are they more platform-dependent or lexer-dependent? Doesn't the lexer call a lexer-specific library? Not sure. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut <peter_e@gmx.net> writes:
> Maybe this has been discussed before my time, but why exactly is it that
> we don't distribute lex'ed files, as with yacc'ed files?
No particularly good reason I suppose... if we did that, we could get
rid of that whole 'lextest' business, too.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Maybe this has been discussed before my time, but why exactly is it that
>> we don't distribute lex'ed files, as with yacc'ed files?
> Not sure. Are they more platform-dependent or lexer-dependent? Doesn't
> the lexer call a lexer-specific library? Not sure.
flex has a lexer-specific library (libfl.a), but as far as I can tell
our scanners don't call it. In fact our build process has no provision
for adding -lfl to the link, which I used to think was an oversight, but
now it's starting to seem like a good idea. We could ship scan.c et al
in the same way we handle the yacc/bison output files, and it should
work everywhere.
If we were going to do this, I'd vote for making sure that *all* the
yacc files are pregenerated (currently, we only take care of the larger
ones), and then most people wouldn't need either flex or bison to build.
regards, tom lane
Added to TODO list. > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Maybe this has been discussed before my time, but why exactly is it that > >> we don't distribute lex'ed files, as with yacc'ed files? > > > Not sure. Are they more platform-dependent or lexer-dependent? Doesn't > > the lexer call a lexer-specific library? Not sure. > > flex has a lexer-specific library (libfl.a), but as far as I can tell > our scanners don't call it. In fact our build process has no provision > for adding -lfl to the link, which I used to think was an oversight, but > now it's starting to seem like a good idea. We could ship scan.c et al > in the same way we handle the yacc/bison output files, and it should > work everywhere. > > If we were going to do this, I'd vote for making sure that *all* the > yacc files are pregenerated (currently, we only take care of the larger > ones), and then most people wouldn't need either flex or bison to build. > > regards, tom lane > > ************ > -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
I've made the necessary changes to release_prep, makefiles, and documentation (not sure how the INSTALL file proper is made from the sgml docs, though). lextest is removed. configure now gives a friendly warning if it finds flex 2.5.3. (In fact it seems like some lex files were already generated for distribution, but now it's all of them.) On 2000-01-15, Bruce Momjian mentioned: > > Added to TODO list. > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> Maybe this has been discussed before my time, but why exactly is it that > > >> we don't distribute lex'ed files, as with yacc'ed files? > > > > > Not sure. Are they more platform-dependent or lexer-dependent? Doesn't > > > the lexer call a lexer-specific library? Not sure. > > > > flex has a lexer-specific library (libfl.a), but as far as I can tell > > our scanners don't call it. In fact our build process has no provision > > for adding -lfl to the link, which I used to think was an oversight, but > > now it's starting to seem like a good idea. We could ship scan.c et al > > in the same way we handle the yacc/bison output files, and it should > > work everywhere. This puzzles me a bit still, but it seems to work. GNU suggests putting yacc and lex files in distributions, so I can't imagine why they would do that if you need to have lib[f]l.a anyway. $ nm /usr/lib/libfl.a libmain.o: 00000000 t gcc2_compiled. 00000000 T main U yylex libyywrap.o: 00000000 t gcc2_compiled. 00000000 T yywrap > > > > If we were going to do this, I'd vote for making sure that *all* the > > yacc files are pregenerated (currently, we only take care of the larger > > ones), and then most people wouldn't need either flex or bison to build. > > > > regards, tom lane > > > > ************ > > > > > -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
>>>> flex has a lexer-specific library (libfl.a), but as far as I can tell
>>>> our scanners don't call it. In fact our build process has no provision
>>>> for adding -lfl to the link, which I used to think was an oversight, but
>>>> now it's starting to seem like a good idea. We could ship scan.c et al
>>>> in the same way we handle the yacc/bison output files, and it should
>>>> work everywhere.
> This puzzles me a bit still, but it seems to work.
I suppose that libfl.a is only needed to support some flex features that
we don't use --- but I haven't bothered to dig in and find out what.
Thanks for taking care of that task; it'd been hanging around on the
"good ideas to get to someday" list for quite a while.
regards, tom lane
On Sun, Jan 16, 2000 at 09:13:03PM +0100, Peter Eisentraut wrote:
>
> This puzzles me a bit still, but it seems to work. GNU suggests putting
> yacc and lex files in distributions, so I can't imagine why they would do
> that if you need to have lib[f]l.a anyway.
>
> $ nm /usr/lib/libfl.a
>
> libmain.o:
> 00000000 t gcc2_compiled.
> 00000000 T main
> U yylex
>
> libyywrap.o:
> 00000000 t gcc2_compiled.
> 00000000 T yywrap
I think those are defaults for the case where you just have a lex file, but
didn't bother with defining a main() after the last %% eg:
%%
A putchar('b');
%%
When linked with -lfl, you get an executable. In the postgresql case, life
is more complicated and the parser calls yylex rather than a fake main(), so
-lfl isn't needed.
Cheers,
Patrick
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> >>>> flex has a lexer-specific library (libfl.a), but as far as I can tell
> >>>> our scanners don't call it. In fact our build process has no provision
> >>>> for adding -lfl to the link, which I used to think was an oversight, but
> >>>> now it's starting to seem like a good idea. We could ship scan.c et al
> >>>> in the same way we handle the yacc/bison output files, and it should
> >>>> work everywhere.
>
> > This puzzles me a bit still, but it seems to work.
>
> I suppose that libfl.a is only needed to support some flex features that
> we don't use --- but I haven't bothered to dig in and find out what.
AFAIK, flex's libfl.a only contains a main() and a noop variant of yywrap(). The main() in there only calls
yylex()repeatedly so you can write a scan.l that does text replacement etc. and simply compile the generated C
sourceinto a standalone executable. Our backend already contains a yywrap() (and a main() of course), so there are
nosymbols that libfl.a could potentially resolve. Thus, it's not needed.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #