[HACKERS] Release stamping (Was: [CORE] Schedule for release?)
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 24 October 2006 14:30 To: Dave Page Cc: [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
Dave Page dpage@vale-housing.co.uk writes: From: Tom Lane [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
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/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
-Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
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. 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release stamping (Was: [CORE] Schedule for release?)
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
