Re: [HACKERS] DEC OSF1 Compilation problems
От | geek+@cmu.edu |
---|---|
Тема | Re: [HACKERS] DEC OSF1 Compilation problems |
Дата | |
Msg-id | emacs-smtp-4042-14010-61959-112469@export.andrew.cmu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] DEC OSF1 Compilation problems ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Then <lockhart@alumni.caltech.edu> spoke up and said: > > > >2. gram.y did not compile by yacc (on FreeBSD too) > > ># woland(dms)~/postgresql-6.4.2/src/backend/parser>yacc -d gram.y > > ># yacc: f - maximum table size exceeded > > >fixed by using bison > > I had always used bison. I will add this to the DU FAQ. > > This should not be required in principle, but it is easy with cvs to > accidentally get the time tags on gram.y and gram.c out of sync, so that > a "cvs checkout" causes Make to think gram.c needs to be rebuilt. I > think that v6.4.2 ended up with the times out of sync, as have other > releases in the past. If someone with access to CVSROOT on the CVS server would be so kind, it's easy to set up a rule in commitinfo to automatically create gram.c from gram.y, thus forcing a new, properly timestamped version of gram.c to be in the archive. -- ===================================================================== | JAVA must have been developed in the wilds of West Virginia. | | After all, why else would it support only single inheritance?? | ===================================================================== | Finger geek@andrew.cmu.edu for my public key. | =====================================================================
В списке pgsql-hackers по дате отправления: