Re: [HACKERS] lex/flex portability PB in version 6.3.1 - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] lex/flex portability PB in version 6.3.1
Date
Msg-id 3528E104.357B7D3D@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] lex/flex portability PB in version 6.3.1  (Andrew Martin <martin@biochemistry.ucl.ac.uk>)
List pgsql-hackers
> > > in version 6.3.1 of the file src/interfaces/ecpg/preproc/pgc.l .
> > > There are some flex specific code .
> > > like :
> > >   %option ( no fatal )
> > >   <<EOF>> ( fatal error )
> > Actually, I hate to say it, but its pretty much recommended that
> > anyone using PostgreSQL use flex/bison...in particular, we're
> > starting to find that 'stock yacc' on some systems chocks on gram.y,
> > because its just gotten to be *very* large...
> 6.3.1 now breaks under Irix lex as well.
> If we're going to REQUIRE flex rather than lex, this MUST be made
> clear in the installation docs!!!!

We do not (or should not, rather) _require_ flex for an installation. We
started shipping the flex output for the main scanner after we started
using "exclusive states" (unsupported in old AT&T lexers) to simplify
the scanner code.

Similarly, we ship the bison output for the parser.

Michael, if these flex features are not adding capability, can you
remove them? If they are very helpful, then can we start including the
pgc.c flex output in patches and into the distribution? We would need to
change the Makefile to keep it from deleting pgc.c when doing a "make
clean". We also need to be careful that the file creation times on the
files in the cvs tree are in the proper order so that make won't try
recreating the output...

                      - Tom

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Developer setup, what works?
Next
From: The Hermit Hacker
Date:
Subject: Ack...major(?) bug just found in v6.3.1...