Re: [HACKERS] DEC OSF1 Compilation problems
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] DEC OSF1 Compilation problems |
Дата | |
Msg-id | 36BAF9EC.3D264EBC@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] DEC OSF1 Compilation problems ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] DEC OSF1 Compilation problems
|
Список | pgsql-hackers |
> I have included both files in my latest patch. Great. Bruce and scrappy, whoever applies this will need to add this as a new file in cvs. At the moment the file is named y.tab.c (and y.tab.h), but we might want to consider renaming it as is done in the main parser to keep the names unique within the installation (for example, y.tab.c is probably also a temporary file in src/backend/parser/). > > Is there some way to do this fixup in the makefile? > Tell me what to do. Doing this in the local makefile is probably dangerous or at least annoying. Let's not be hasty in adopting a fix for this out of sync problem. We should remember that any heuristic like this might also mask the fact that we have forgotten to update the gram.c before a release. imho the best way to ensure sync is for Bruce, myself, and anyone else who commits parser stuff to commit gram.y and scan.l first, then gram.c and scan.c afterwards. The cvs time tags will be consistant then. Also, our pre-release checking apparently does not alway catch this problem; perhaps we should figure out a way to build with a dummy yacc/bison for this final verification, so things barf if it is actually invoked. - Tom
В списке pgsql-hackers по дате отправления: