pgsql: Remove win32ver.rc from version_stamp.pl
Remove win32ver.rc from version_stamp.pl
This removes another relic from the old nmake-based Windows build.
version_stamp.pl put version number information into win32ver.rc. But
win32ver.rc already gets other version number information from the
preprocessor at build time, so it would make more sense if all version
number information would be handled in the same way and we don't have
two places that do it.
What we need for this is having the major version number and the minor
version number as separate integer symbols. Both configure and
Solution.pm already have that logic, because they compute
PG_VERSION_NUM. So we just keep all the logic there now. Put the
minor version number into a new symbol PG_MINORVERSION_NUM. Also, add
a symbol PG_MAJORVERSION_NUM, which is a number, alongside the
existing PG_MAJORVERSION, which is a string.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: /messages/by-id/1ee46ac4-a9b2-4531-bf54-5ec2e374634d@2ndquadrant.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/0a42a2e9ce8481a024d085f2cc526a366db8df59
Modified Files
--------------
configure | 15 +++++++++++++--
configure.in | 7 +++++--
src/include/pg_config.h.in | 6 ++++++
src/port/win32ver.rc | 4 ++--
src/tools/msvc/Solution.pm | 16 +++++++++-------
src/tools/version_stamp.pl | 14 +-------------
6 files changed, 36 insertions(+), 26 deletions(-)
On 2020-03-10 11:22, Peter Eisentraut wrote:
What we need for this is having the major version number and the minor
version number as separate integer symbols. Both configure and
Solution.pm already have that logic, because they compute
PG_VERSION_NUM. So we just keep all the logic there now. Put the
minor version number into a new symbol PG_MINORVERSION_NUM. Also, add
a symbol PG_MAJORVERSION_NUM, which is a number, alongside the
existing PG_MAJORVERSION, which is a string.
This created some seemingly unrelated build farm failures. I suspect
this must have something to do with the new shell code in configure
+PG_MINORVERSION=`expr "$PACKAGE_VERSION" : '.*\.\([0-9][0-9]*\)'`
+test -n "$PG_MINORVERSION" || PG_MINORVERSION=0ending up with some nonsense being assigned to PG_MINORVERSION, perhaps
due to a not-quite-mainstream Bourne shell being used.
Can anyone test this locally?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
This created some seemingly unrelated build farm failures. I suspect
this must have something to do with the new shell code in configure
+PG_MINORVERSION=`expr "$PACKAGE_VERSION" : '.*\.\([0-9][0-9]*\)'` +test -n "$PG_MINORVERSION" || PG_MINORVERSION=0
ending up with some nonsense being assigned to PG_MINORVERSION, perhaps
due to a not-quite-mainstream Bourne shell being used.
Looking at the configure log on gharial, the only incorrect symbol
seems to be PG_VERSION_NUM:
#define PG_MAJORVERSION "13"
#define PG_MAJORVERSION_NUM 13
#define PG_MINORVERSION_NUM 0
#define PG_VERSION "13devel"
#define PG_VERSION_STR "PostgreSQL 13devel on ia64-hp-hpux11.31, compiled by gcc (GCC) 4.6.0, 64-bit"
#define PG_VERSION_NUM
which squares with the compile error that's being thrown (it's pointing at
a macro that uses PG_VERSION_NUM).
I'd suggest reverting the change in how PG_VERSION_NUM is computed
in configure.in --- that was certainly not necessary to the patch,
and evidently you're falling foul of some weird behavior around
nesting double-quotes and backquotes.
regards, tom lane
I wrote:
I'd suggest reverting the change in how PG_VERSION_NUM is computed
in configure.in --- that was certainly not necessary to the patch,
and evidently you're falling foul of some weird behavior around
nesting double-quotes and backquotes.
Actually, you can just get rid of the nesting, because there's no
need to be picky about what white-space gets fed to awk. The
attached seems to be enough to fix it (tested on gaur).
regards, tom lane