Re: Release stamping (Was: [CORE] Schedule for release?) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Release stamping (Was: [CORE] Schedule for release?)
Date
Msg-id 8112.1161697948@sss.pgh.pa.us
Whole thread Raw
In response to Release stamping (Was: [CORE] Schedule for release?)  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Release stamping (Was: [CORE] Schedule for release?)  (Peter Eisentraut <peter_e@gmx.net>)
Re: Release stamping (Was: [CORE] Schedule for release?)  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-hackers
"Dave Page" <dpage@vale-housing.co.uk> writes:
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
>> The pg_config.h.win32 file is intended to support building in an
>> environment where you can't run automake/autoconf, or indeed much of
>> anything else. 

> That doesn't matter does it? Marc runs the bootstrap, which inserts the
> version numbers into the right place and runs autoconf, then he commits
> the changed files (configure, pg_config.h.win32 etc) to CVS. Only he (or
> you or Bruce) should ever need to run it.

Hmm, so manufacture pg_config.h.win32 during tarball build and insert
the version numbers at that point?  Yeah, that would work.  Actually the
easiest thing would likely be to have configure build it the same way it
builds pg_config.h, and then not remove it in "make distclean".
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Release stamping (Was: [CORE] Schedule for release?)
Next
From: "Simon Riggs"
Date:
Subject: Re: New CRC algorithm: Slicing by 8