Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c' - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
Date
Msg-id 36DD68D2.E5583B4B@alumni.caltech.edu
Whole thread Raw
In response to Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'
List pgsql-hackers
> I don't think it's cvs' fault.
> I'm using cvs 1.10 here, but I don't think its behavior has changed
> in this respect in any recent version.  If it did not timestamp 
> updates with time of retrieval, it would create synchronization bugs 
> with respect to locally created files, which'd be no fun either.

I use CVSup, and it seems to keep the creation date of files consistant
with the source cvs tree. Does anonymous cvs not do that? Again, I
*don't* see the behavior that you do, at least given my CVSup/cvs-1.9
system.

> PS: treating gram.c as a derived file that is made while building
> a tarball would also eliminate our recurring problem with gram.c
> appearing to be out-of-date in releases, when it really isn't.

Sure. Who wants to work that out?

btw, could all of this be traced to bad dependencies on parse.h? Our
current Makefile system does not do this correctly. I applied some small
patches recently to help, but it did not fix the fundamental problem
that all the backend/* directories refer to backend/parse.h, but they do
not know that backend/parse.h is a copy of backend/parser/parse.h.
                       - Tom


pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] palloc.h again
Next
From: Kaare Rasmussen
Date:
Subject: Re: [HACKERS] NUMERIC and Perl