Обсуждение: Release stamping (Was: [CORE] Schedule for release?)
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 24 October 2006 14:30 > To: Dave Page > Cc: pgsql-core@postgresql.org > Subject: Re: [CORE] Schedule for release? > > > In pgAdmin we have a simple bootstrap script the writes all > the version > > numbers into a bunch of files, and then runs > automake/autoconf et al. It > > sucks it out of one header which is all we have to modify manually. > > Any reason we can't do something similar for PosgreSQL? > > 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. > Perhaps we could require Perl or something to be > available? I know Magnus is requiring Perl for his MSVC > build support. Yes. > This is getting offtopic for -core though. Moved to -hackers... Regards, Dave.
"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.insed '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
<font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br /><br /><br /> On 24/10/06 21:59, "Magnus Hagander"<mha@sollentuna.net> wrote:<br /></span></font><blockquote><span style="font-size:12.0px"><font face="Monaco,Courier New"><br /><br /> Right. And then you can only build from tarball and not from CVS, right?<br /> Becausethe pg_config.h.win32 with version is actually in cvs. Or an I<br /> missing something here?<br /><br /></font></span></blockquote><spanstyle="font-size:12.0px"><font face="Monaco, Courier New">I suggested checking the resultinto CVS, per the configure script.<br /><br /> Regards, Dave.</font></span>
> >> 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