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

"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

Tom Lane wrote:

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".

The libpq makefile contains ample precedent for preparing Windows
specific files during tarball building.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: 24 October 2006 15:56
To: Tom Lane; Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Release stamping (Was: [CORE] Schedule
for release?)

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.

Regards, Dave.

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

"Magnus Hagander" <mha@sollentuna.net> writes:

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.

Why not? The shipped tarball would contain exactly the same
pg_config.h.win32 it does today; the only difference is that the
version info would've been inserted automatically instead of manually.
(The start of this discussion was my observation that pg_config.h.win32
contains multiple copies of the version info, and sooner or later
somebody would miss one while stamping a release.)

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.

That's great if you're using msvc, but what about borland?

regards, tom lane

Tom Lane wrote:

Why not? The shipped tarball would contain exactly the same
pg_config.h.win32 it does today; the only difference is that the
version info would've been inserted automatically instead of
manually.

I suggest you do it in a makefile as part of the distprep target.

distprep: pg_config.h.win32

pg_config.h.win32: pg_config.h.win32.in
sed 's/@VERSION@/$(VERSION)/g' $< >$@

maintainer-clean:
rm -f pg_config.h.win32

That way we don't bother every configure runner with the issue.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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.

Why not? The shipped tarball would contain exactly the same
pg_config.h.win32 it does today; the only difference is that
the version info would've been inserted automatically instead
of manually.
(The start of this discussion was my observation that
pg_config.h.win32 contains multiple copies of the version
info, and sooner or later somebody would miss one while
stamping a release.)

Right. And then you can only build from tarball and not from CVS, right?
Because the pg_config.h.win32 with version is actually in cvs. Or an I
missing something here?

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.

That's great if you're using msvc, but what about borland?

Good point. But we could always make that part of the script a separate
one that can be run for Borland as welll.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Why not? The shipped tarball would contain exactly the same
pg_config.h.win32 it does today; the only difference is that
the version info would've been inserted automatically instead
of manually.

Right. And then you can only build from tarball and not from CVS, right?

But isn't that true for borland already? We've got the .def files
for libpq and the help-file for psql that we don't expect a borland
environment to be able to build.

regards, tom lane

On 24/10/06 21:59, "Magnus Hagander" <mha@sollentuna.net> wrote:

Right. And then you can only build from tarball and not from CVS, right?
Because the pg_config.h.win32 with version is actually in cvs. Or an I
missing something here?

I suggested checking the result into CVS, per the configure script.

Regards, Dave.

Why not? The shipped tarball would contain exactly the same
pg_config.h.win32 it does today; the only difference is that the
version info would've been inserted automatically instead of
manually.

Right. And then you can only build from tarball and not

from CVS, right?

But isn't that true for borland already? We've got the .def
files for libpq and the help-file for psql that we don't
expect a borland environment to be able to build.

Borland, yes. MSVC, no. So I guess we could hav ethe MSVC bulid script
generate it for MSVC, and then stick it in the tarball for borland. It's
two different ways to do the same thing, but I guess we can do that..

//Magnus