Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors

> > gmake[2]: Entering directory `/usr/local/NetBSD/pkgsrc/databases/postgresql/work/pgsql/src/backend/parser'
> > /usr/bin/yacc -d gram.y
> > /usr/bin/yacc: f - maximum table size exceeded
> > gmake[2]: *** [parse.h] Error 2
> > /usr/bin/yacc -d gram.y
> > /usr/bin/yacc: f - maximum table size exceeded
> > gmake[2]: *** [gram.c] Error 2
>
> Requires bison to be installed instead of yacc...
>
> > Both sets of problems seem to relate to processing parsers with yacc.
> > Do I need bison instead? If so, perhaps this should be listed as a
> > requirement in the INSTALL docs.
>
> It doesn't appear to be a seperate requirement on all systems...

Stan Brown suggested trying a -N switch (not sure which system he got this from):

-N<secondary><n>
Allow the sizes of certain internal yacc tables to
be reset. secondary is one of the letters from
the set {B a m s p n e c l w} and specifies the
table; n is the new size. Tables that can be
reset by using secondary letters are as follows:
a a-array size; default is 12000.
m mem array size; default is 12000
s number of states; default is 1000.
p number of productions; default is
800
n number of non-terminals; default is
600.
e temp-space size; default is 1250.
c name-space size; default is 5000.
l look-ahead set table size; default i
650.
w working set table size; default is
650.

It would be great if someone would show exactly what is needed for the BSD yacc systems to avoid a requirement for bison. The problem is that in the last
couple of weeks the parser finally grew to exceed some internal limit in BSD yacc. Any solution might be applicable to other yacc'ers...

Also, if this fails we can try packaging "gram.c" with the distribution; I think that bison is similar to flex in generating library-independent C code. Would
like to resolve this in the next few days...

- Tom