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: | 6BCB9D8A16AC4241919521715F4D8BCEA3582F@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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).
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2006-10-24 14:56:31 | Conference materials (Was: [HACKERS] pdfs of the conference) |
Previous Message | Tom Lane | 2006-10-24 14:37:12 | Re: New CRC algorithm: Slicing by 8 |