Re: [HACKERS] DEC OSF1 Compilation problems - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] DEC OSF1 Compilation problems
Date
Msg-id 36BAF9EC.3D264EBC@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] DEC OSF1 Compilation problems  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Responses Re: [HACKERS] DEC OSF1 Compilation problems
List 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 by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] DEC OSF1 Compilation problems
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] DEC OSF1 Compilation problems