> > 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):
At least on NetBSD/i386 v1.3 yacc does not have a -N switch.
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.
This seems to be the best solution. The situation with flex and yacc
is much the same as with the configuration system. These programs
take specs and generate compilable files that should be system
independent (am I wrong about that last point?). Just as we don't
require people to have the autoconf tool to generate the configure
script, perhaps we shouldn't require flex or bison either. Of course,
the original lexer and parser files should be shipped as well for
completeness, just as configure.in is.
Just my thoughts. I'll get bison in the meantime so I can do the
testing.
Cheers,
Brook
