> > Strange. First of all, gram.y should not be processed since gram.c is > > in the CVS Repository. Second, the problem you are having with bison > > seemed to be caused by @YFLAFS@ not replaced but I don't have @YFLAGS@ > > at all in my environment(in my environment, bison -y -d gram.y runs). > > > > Just for temporary solution, could you touch gram.c to avoid run bison > > or get ride of @YFLAGS@ (just remove it from the Makefile)? > > > > No worries I will try that out once I get a chance .. hopefully this > weekend :)
Thanks! > > For long term solution, I need help from expert of build system > > (autoconf etc. stuff). Current build system was made by someone who > > has already left pgpool development. I think I need to over hole or > > rewrite the build system but for this I need help... > > I would be more than glad to help you out in anything I can. I'm > though a bit confused about what you mean by > build system. Are you referring to up-to-date servers where one would > build pgpool for different platform ? > Or are you taking about making changes to Makefiles and making sure > pgpool builds properly on systems ? Yes, this one! > Please give me some more insight in what you are looking for so that I > can have a better idea. > >> I also have an older working copy of CVS where the > >> "pool_process_query.c" was revision: 1.114 which does compile ok > >> although I do get some warnings about yacc but I do remember always > >> getting those. > > > > It seems newer verison of flex produces these annoying things. I > > remember same kind of discussions were on the pgsql-hackers list and > > there may be solutions there, but I am not sure... > > cool > _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
