Re: [HACKERS] DEC OSF1 Compilation problems

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Michael Meskes <Michael_Meskes(at)topmail(dot)de>
Cc: pgsql-hackers(at)hub(dot)org, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Subject: Re: [HACKERS] DEC OSF1 Compilation problems
Date: 1999-02-05 14:02:20
Message-ID: 36BAF9EC.3D264EBC@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-02-05 17:20:51 Re: SELECT INTO TABLE busted?
Previous Message Thomas G. Lockhart 1999-02-05 13:51:20 Re: [HACKERS] DEC OSF1 Compilation problems