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

From Magnus Hagander
Subject Re: Release stamping (Was: [CORE] Schedule for release?)
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA35832@algol.sollentuna.se
Whole thread Raw
In response to Re: Release stamping (Was: [CORE] Schedule for release?)  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: Release stamping (Was: [CORE] Schedule for release?)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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).
>
> Sorry - we're just talking about getting the version number
> in there automatically to avoid it getting forgotten during
> release bundling.

I can see that being a good idea. But I don't see Toms ./configure
solution working.

What we could do is have the msvc build scripts edit the file and
replace the version with something it reads from configure.in when run.
This would require that we zap the old "win32.mak" method of buildnig
win32 stuff, which we can't do just yet but IMHO can eventually do.

The other option is, I would think, to break out the version #defines
into a separate headerfile that's used on all platforms, and use that
one *instead* of configure to set it.

//Magnus


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Release stamping (Was: [CORE] Schedule for release?)
Next
From: Tom Lane
Date:
Subject: Re: Release stamping (Was: [CORE] Schedule for release?)