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  (Michael Meskes <Michael.Meskes@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [HACKERS] DEC OSF1 Compilation problems
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] DEC OSF1 Compilation problems