Skip site navigation (1) Skip section navigation (2)

Re: Release stamping (Was: [CORE] Schedule for release?)

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release stamping (Was: [CORE] Schedule for release?)
Date: 2006-10-24 14:56:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> >> 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".

Getting late into this discussion, so I may be completely off here :-)
How's that going to work+ pg_config.h.win32 needs to know win32 platform
specifics, right? So it has to be created, in that case, on win32. But
when you're building with MSVC, you don't run configure, because windows
can't run that (without the mingw layer).


In response to


pgsql-hackers by date

Next:From: Andrew SullivanDate: 2006-10-24 14:56:31
Subject: Conference materials (Was: [HACKERS] pdfs of the conference)
Previous:From: Tom LaneDate: 2006-10-24 14:37:12
Subject: Re: New CRC algorithm: Slicing by 8

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group