VS2022: Support Visual Studio 2022 on Windows
During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.
The x64 version built without error!.
Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the support to Postgres msvc tools directory.
I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.
The only thing that will change later in the first non-preview release is the exact version number, which seems to change allways on every minor VS upgrade and is not used explicitely:
$self->{VisualStudioVersion} = '17.0.31717.71';
The patch is not invasive, so it should follow the practice of backpatching it to (most) supported versions.
I have tested the x64 compile and install with the release source code of PG14.0 from 2021-09-30.
Due to bad development environment I did not a full run of all tests afterwords.
Visual Studio is co-installable to an already existing VS version on the same machine (I had VS2019 installed) and is separately choosable as compile environment.
Compilation time and file sizes are almost identical, but the GUI promises a native 64bit implementation, so it may appealing to use the new version.
HELP NEEDED:
Please could somebody test the patch and enter it to the next commit fest?
(Only my second patch, not much experience with the tool chain :-( )
Another point is the failure of using VS2019/VS2022 for building the 32bit version, but this has to be discussed in another thread (if the Windows 32bit Version is still important to support on newer VS Versions)
Thanks for looking at it
Hans Buschmann
Attachments:
0001_support_vs2022.patchapplication/octet-stream; name=0001_support_vs2022.patchDownload
diff --git a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgml
index 312edc6..940836a 100644
--- a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml
+++ b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgml
@@ -20,9 +20,9 @@
<para>
There are several different ways of building PostgreSQL on
<productname>Windows</productname>. The simplest way to build with
- Microsoft tools is to install <productname>Visual Studio 2019</productname>
+ Microsoft tools is to install <productname>Visual Studio 2022</productname>
and use the included compiler. It is also possible to build with the full
- <productname>Microsoft Visual C++ 2013 to 2019</productname>.
+ <productname>Microsoft Visual C++ 2013 to 2022</productname>.
In some cases that requires the installation of the
<productname>Windows SDK</productname> in addition to the compiler.
</para>
@@ -69,7 +69,7 @@
<productname>Microsoft Windows SDK</productname>. If you do not already have a
<productname>Visual Studio</productname> environment set up, the easiest
ways are to use the compilers from
- <productname>Visual Studio 2019</productname> or those in the
+ <productname>Visual Studio 2022</productname> or those in the
<productname>Windows SDK 10</productname>, which are both free downloads
from Microsoft.
</para>
@@ -78,7 +78,7 @@
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
32-bit PostgreSQL builds are possible with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>,
+ <productname>Visual Studio 2022</productname>,
as well as standalone Windows SDK releases 8.1a to 10.
64-bit PostgreSQL builds are supported with
<productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
@@ -86,7 +86,7 @@
is supported down to <productname>Windows 7</productname> and
<productname>Windows Server 2008 R2 SP1</productname> when building with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>.
+ <productname>Visual Studio 2022</productname>.
<!--
For 2013 requirements:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
@@ -96,6 +96,8 @@
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
For 2019 requirements:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements
+ For 2022 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/releases/2022/system-requirements
-->
</para>
diff --git a/postgresql-14.0_orig/src/tools/msvc/MSBuildProject.pm b/postgresql-14.0_vs2022/src/tools/msvc/MSBuildProject.pm
index ebe6530..52f8ec2 100644
--- a/postgresql-14.0_orig/src/tools/msvc/MSBuildProject.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/MSBuildProject.pm
@@ -508,4 +508,30 @@ sub new
return $self;
}
+
+package VC2022Project;
+
+#
+# Package that encapsulates a Visual C++ 2022 project file
+#
+
+use strict;
+use warnings;
+use base qw(MSBuildProject);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{vcver} = '17.00';
+ $self->{PlatformToolset} = 'v143';
+ $self->{ToolsVersion} = '17.0';
+
+ return $self;
+}
+
1;
diff --git a/postgresql-14.0_orig/src/tools/msvc/README b/postgresql-14.0_vs2022/src/tools/msvc/README
index f154759..34ea4d5 100644
--- a/postgresql-14.0_orig/src/tools/msvc/README
+++ b/postgresql-14.0_vs2022/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
==========
This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2019. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
the libpq frontend library. For more information, see the documentation
chapter "Installation on Windows" and the description below.
@@ -89,10 +89,10 @@ These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
implementing the Solution interface (this could be either VS2013Solution,
-VS2015Solution, VS2017Solution or VS2019Solution, all in Solution.pm,
+VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in Solution.pm,
depending on the user's build environment) and adding objects implementing
the corresponding Project interface (VC2013Project, VC2015Project,
-VC2017Project or VC2019Project from MSBuildProject.pm) to it.
+VC2017Project,VC2019Project or VC2022Project from MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
The final step of starting the appropriate build program (msbuild) is
diff --git a/postgresql-14.0_orig/src/tools/msvc/Solution.pm b/postgresql-14.0_vs2022/src/tools/msvc/Solution.pm
index cfda5ac..a95754d 100644
--- a/postgresql-14.0_orig/src/tools/msvc/Solution.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/Solution.pm
@@ -1315,6 +1315,34 @@ sub new
return $self;
}
+package VS2022Solution;
+
+#
+# Package that encapsulates a Visual Studio 2022 solution file
+#
+
+use Carp;
+use strict;
+use warnings;
+use base qw(Solution);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{solutionFileVersion} = '12.00';
+ $self->{vcver} = '17.00';
+ $self->{visualStudioName} = 'Visual Studio 2022';
+ $self->{VisualStudioVersion} = '17.0.31717.71';
+ $self->{MinimumVisualStudioVersion} = '10.0.40219.1';
+
+ return $self;
+}
+
sub GetAdditionalHeaders
{
my ($self, $f) = @_;
diff --git a/postgresql-14.0_orig/src/tools/msvc/VSObjectFactory.pm b/postgresql-14.0_vs2022/src/tools/msvc/VSObjectFactory.pm
index 61e83f5..f78e08c 100644
--- a/postgresql-14.0_orig/src/tools/msvc/VSObjectFactory.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/VSObjectFactory.pm
@@ -61,6 +61,16 @@ sub CreateSolution
{
return new VS2019Solution(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VS2022Solution(@_);
+ }
else
{
croak
@@ -105,6 +115,16 @@ sub CreateProject
{
return new VC2019Project(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VC2022Project(@_);
+ }
else
{
croak
@@ -134,7 +154,7 @@ sub DetermineVisualStudioVersion
else
{
# fake version
- return '16.00';
+ return '17.00';
}
}
@@ -143,13 +163,13 @@ sub _GetVisualStudioVersion
my ($major, $minor) = @_;
# The major visual studio that is supported has nmake
- # version <= 14.30, so stick with it as the latest version
+ # version < 14.40, so stick with it as the latest version
# if bumping on something even newer.
- if ($major >= 14 && $minor >= 30)
+ if ($major >= 14 && $minor >= 40)
{
carp
"The determined version of Visual Studio is newer than the latest supported version. Returning the latest supported version instead.";
- return '14.20';
+ return '14.30';
}
elsif ($major < 12)
{
On Fri, 2021-10-01 at 15:15 +0000, Hans Buschmann wrote:
During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.
The x64 version built without error!.Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the support to Postgres msvc tools directory.
I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.
[...]
HELP NEEDED:
Please could somebody test the patch and enter it to the next commit fest?
Thanks for that work; help with Windows is always welcome.
Please go ahead and add the patch to the commitfest yourself.
Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.
Yours,
Laurenz Albe
On 10/4/21 6:13 AM, Laurenz Albe wrote:
On Fri, 2021-10-01 at 15:15 +0000, Hans Buschmann wrote:
During testing of the new Visual Studio 2022 Preview Version 4.1 from Microsoft I also tried PG14.0 on it.
The x64 version built without error!.Even when this is only a preview version (the real thing is to expected soon) it seems appropriate to include the support to Postgres msvc tools directory.
I followed the guideline of the patch msvc-2019-support-v4.patch for VS2019 support. New patch attached.
[...]
HELP NEEDED:
Please could somebody test the patch and enter it to the next commit fest?
Thanks for that work; help with Windows is always welcome.
Please go ahead and add the patch to the commitfest yourself.
Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.
I think we'll want to wait for the official release before we add
support for it.
cheers
andew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Mon, Oct 04, 2021 at 08:21:52AM -0400, Andrew Dunstan wrote:
I think we'll want to wait for the official release before we add
support for it.
Agreed. I am pretty sure that the version strings this patch is using
are going to change until the release happens.
--
Michael
During October Patchday 2021 the Visual Studio components where upraded too.
Now VS2022 Preview 5 is out, also Visual Studio 2022 RC is available to be used for production use (seems like our RC with respect to features).
In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see
This date is just some hours after the wrapup for our minor release on November 11.
Barring any objections I suggest to apply the patch just before this weekend in November to have the support for Microsofts Developer Suite for the following 3 months available. (PS: no one is OBLIGUED to use the new version of VS, the interest for PG14 will grow with PG14.1 and this support effects only experienced users self-compiling on windows).
I will watch the development in the first week of November and will update the patch to include the latest version number.
It seems clear that VS2022 will take the 14.30 range as Version number (seen from the VC runtime versions installed)
Only the VisualStudioVersion (17.0.31717.71) will be changed like on EVERY update of a Visual Studio installation/upgrade.
VS2019 is now on 16.11.5, Postgres never upgrades this number for older versions and always uses the initial number when introduced (here 16.0.28729.10 for VS2019).
So it seems safe to use a number of a version which can be used for building PG without errors.
Thanks
Hans Buschmann
________________________________________
Von: Michael Paquier <michael@paquier.xyz>
Gesendet: Montag, 11. Oktober 2021 08:03
An: Andrew Dunstan
Cc: Laurenz Albe; Hans Buschmann; pgsql-hackers@postgresql.org
Betreff: Re: VS2022: Support Visual Studio 2022 on Windows
On Mon, Oct 04, 2021 at 08:21:52AM -0400, Andrew Dunstan wrote:
I think we'll want to wait for the official release before we add
support for it.
Agreed. I am pretty sure that the version strings this patch is using
are going to change until the release happens.
--
Michael
Hans Buschmann <buschmann@nidsa.net> writes:
In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see
https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
This date is just some hours after the wrapup for our minor release on November 11.
Ugh, bad timing.
Barring any objections I suggest to apply the patch just before this weekend in November to have the support for Microsofts Developer Suite for the following 3 months available.
Immediately before a release is the worst possible time to be applying
non-critical patches. I think better options are to
(1) commit now, using the RC release's version as the minimum, or
(2) wait till just after our release cycle.
Of course, if we only plan to commit to HEAD and not back-patch,
this is all moot.
regards, tom lane
On 10/13/21 3:49 PM, Tom Lane wrote:
Hans Buschmann <buschmann@nidsa.net> writes:
In the long of this process Microsoft announced the general availability of VS200 for Monday, November 8, see
https://devblogs.microsoft.com/visualstudio/join-us-november-8th-for-the-launch-of-visual-studio-2022/
This date is just some hours after the wrapup for our minor release on November 11.Ugh, bad timing.
Barring any objections I suggest to apply the patch just before this weekend in November to have the support for Microsofts Developer Suite for the following 3 months available.
Immediately before a release is the worst possible time to be applying
non-critical patches. I think better options are to
(1) commit now, using the RC release's version as the minimum, or
(2) wait till just after our release cycle.Of course, if we only plan to commit to HEAD and not back-patch,
this is all moot.
No, we always try to backpatch these so that we can have buildfarm
animals that build all live branches.
I really don't see that we need to be in a hurry with this. There is no
requirement that we support VS2022 on day one of its release. Three
months really won't matter. Impatience doesn't serve us well here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Now it is three days before release of VS2022.
I updated to the latest Preview 7 (= RC3) and recompiled PG14 64bit Release without issues.
There seem to be not many internal differences from previous versions in the tools used for building Postgres.
My intention for an early support is to catch the momentum for signalling to any user: "We support current tools".
The risks seem non-existent.
Updated the patch to reflect the VisualStudioVersion for Preview 7, which is the version number compiled into the main devenv.exe image.
This version number seems to be of no interest elsewhere in the postgres source tree.
I will reflect any updates after official release on monday, November 8
Hans Buschmann
Attachments:
0001_support_vs2022_v2.patchapplication/octet-stream; name=0001_support_vs2022_v2.patchDownload
diff --git a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgml
index 312edc6..940836a 100644
--- a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml
+++ b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgml
@@ -20,9 +20,9 @@
<para>
There are several different ways of building PostgreSQL on
<productname>Windows</productname>. The simplest way to build with
- Microsoft tools is to install <productname>Visual Studio 2019</productname>
+ Microsoft tools is to install <productname>Visual Studio 2022</productname>
and use the included compiler. It is also possible to build with the full
- <productname>Microsoft Visual C++ 2013 to 2019</productname>.
+ <productname>Microsoft Visual C++ 2013 to 2022</productname>.
In some cases that requires the installation of the
<productname>Windows SDK</productname> in addition to the compiler.
</para>
@@ -69,7 +69,7 @@
<productname>Microsoft Windows SDK</productname>. If you do not already have a
<productname>Visual Studio</productname> environment set up, the easiest
ways are to use the compilers from
- <productname>Visual Studio 2019</productname> or those in the
+ <productname>Visual Studio 2022</productname> or those in the
<productname>Windows SDK 10</productname>, which are both free downloads
from Microsoft.
</para>
@@ -78,7 +78,7 @@
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
32-bit PostgreSQL builds are possible with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>,
+ <productname>Visual Studio 2022</productname>,
as well as standalone Windows SDK releases 8.1a to 10.
64-bit PostgreSQL builds are supported with
<productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
@@ -86,7 +86,7 @@
is supported down to <productname>Windows 7</productname> and
<productname>Windows Server 2008 R2 SP1</productname> when building with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>.
+ <productname>Visual Studio 2022</productname>.
<!--
For 2013 requirements:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
@@ -96,6 +96,8 @@
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
For 2019 requirements:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements
+ For 2022 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/releases/2022/system-requirements
-->
</para>
diff --git a/postgresql-14.0_orig/src/tools/msvc/MSBuildProject.pm b/postgresql-14.0_vs2022/src/tools/msvc/MSBuildProject.pm
index ebe6530..52f8ec2 100644
--- a/postgresql-14.0_orig/src/tools/msvc/MSBuildProject.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/MSBuildProject.pm
@@ -508,4 +508,30 @@ sub new
return $self;
}
+
+package VC2022Project;
+
+#
+# Package that encapsulates a Visual C++ 2022 project file
+#
+
+use strict;
+use warnings;
+use base qw(MSBuildProject);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{vcver} = '17.00';
+ $self->{PlatformToolset} = 'v143';
+ $self->{ToolsVersion} = '17.0';
+
+ return $self;
+}
+
1;
diff --git a/postgresql-14.0_orig/src/tools/msvc/README b/postgresql-14.0_vs2022/src/tools/msvc/README
index f154759..34ea4d5 100644
--- a/postgresql-14.0_orig/src/tools/msvc/README
+++ b/postgresql-14.0_vs2022/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
==========
This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2019. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
the libpq frontend library. For more information, see the documentation
chapter "Installation on Windows" and the description below.
@@ -89,10 +89,10 @@ These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
implementing the Solution interface (this could be either VS2013Solution,
-VS2015Solution, VS2017Solution or VS2019Solution, all in Solution.pm,
+VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in Solution.pm,
depending on the user's build environment) and adding objects implementing
the corresponding Project interface (VC2013Project, VC2015Project,
-VC2017Project or VC2019Project from MSBuildProject.pm) to it.
+VC2017Project,VC2019Project or VC2022Project from MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
The final step of starting the appropriate build program (msbuild) is
diff --git a/postgresql-14.0_orig/src/tools/msvc/Solution.pm b/postgresql-14.0_vs2022/src/tools/msvc/Solution.pm
index cfda5ac..a95754d 100644
--- a/postgresql-14.0_orig/src/tools/msvc/Solution.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/Solution.pm
@@ -1315,6 +1315,34 @@ sub new
return $self;
}
+package VS2022Solution;
+
+#
+# Package that encapsulates a Visual Studio 2022 solution file
+#
+
+use Carp;
+use strict;
+use warnings;
+use base qw(Solution);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{solutionFileVersion} = '12.00';
+ $self->{vcver} = '17.00';
+ $self->{visualStudioName} = 'Visual Studio 2022';
+ $self->{VisualStudioVersion} = '17.0.31825.309';
+ $self->{MinimumVisualStudioVersion} = '10.0.40219.1';
+
+ return $self;
+}
+
sub GetAdditionalHeaders
{
my ($self, $f) = @_;
diff --git a/postgresql-14.0_orig/src/tools/msvc/VSObjectFactory.pm b/postgresql-14.0_vs2022/src/tools/msvc/VSObjectFactory.pm
index 61e83f5..f78e08c 100644
--- a/postgresql-14.0_orig/src/tools/msvc/VSObjectFactory.pm
+++ b/postgresql-14.0_vs2022/src/tools/msvc/VSObjectFactory.pm
@@ -61,6 +61,16 @@ sub CreateSolution
{
return new VS2019Solution(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VS2022Solution(@_);
+ }
else
{
croak
@@ -105,6 +115,16 @@ sub CreateProject
{
return new VC2019Project(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VC2022Project(@_);
+ }
else
{
croak
@@ -134,7 +154,7 @@ sub DetermineVisualStudioVersion
else
{
# fake version
- return '16.00';
+ return '17.00';
}
}
@@ -143,13 +163,13 @@ sub _GetVisualStudioVersion
my ($major, $minor) = @_;
# The major visual studio that is supported has nmake
- # version <= 14.30, so stick with it as the latest version
+ # version < 14.40, so stick with it as the latest version
# if bumping on something even newer.
- if ($major >= 14 && $minor >= 30)
+ if ($major >= 14 && $minor >= 40)
{
carp
"The determined version of Visual Studio is newer than the latest supported version. Returning the latest supported version instead.";
- return '14.20';
+ return '14.30';
}
elsif ($major < 12)
{
On 6 Nov 2021, at 10:29, Hans Buschmann <buschmann@nidsa.net> wrote:
Updated the patch to reflect the VisualStudioVersion for Preview 7, which is the version number compiled into the main devenv.exe image.
This version number seems to be of no interest elsewhere in the postgres source tree.
This patch fails to apply as it's anchored beneath the root of the source tree,
please create the patch from inside the sourcetree such that others (and the CF
patch tester) can apply it without tweaking:
--- a/postgresql-14.0_orig/doc/src/sgml/install-windows.sgml
+++ b/postgresql-14.0_vs2022/doc/src/sgml/install-windows.sgmlAlso note that patches should be against Git HEAD unless fixing a bug only
present in a backbranch.
I will reflect any updates after official release on monday, November 8
Any updates on this following the November 8 release?
--
Daniel Gustafsson https://vmware.com/
Hello Daniel,
Thank you for looking into it.
My skills with git are minmal yet and I am working on a correct development platform, so sorry for any inconveniances from my side .
When upgraded Microsoft jumped directly from Preview 7 to Preview 7.1 of VS2022 by skipping the release version of 7.0.
I had to install it on a different machine to test it with the final VS2022 version from november 8.
On both platforms the build of snapshot from 19.11.2021 is successfull but gives the following warnings which seem not correlated to the proposed patch:
Der Buildvorgang wurde erfolgreich ausgeführt.
"C:\pgdev\postgresql-15devel\pgsql.sln" (Standardziel) (1) ->
"C:\pgdev\postgresql-15devel\postgres.vcxproj" (Standardziel) (2) ->
(ClCompile Ziel) ->
C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(858,18): warning C4101: "htup": Unreferenzierte lokale Variable [C:\pgdev\postgresql-15devel\postgres.vcxproj]
C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(870,11): warning C4101: "tolp": Unreferenzierte lokale Variable [C:\pgdev\postgresql-15devel\postgres.vcxproj]
2 Warnung(en)
0 Fehler
(Meaning 2 unreferenced local variables in pruneheap.c)
The build produced .vcxproj files with ToolsVersion="17.0", so it recognized the new environment correctly.
I corrected some ommissions in _GetVisualStudioVersion in VSObjectFactory.pm.
Please find attached the corrected patch version v4.
Due to my restricted devlopment environment I appreciate if anybody can test the resulting binaries (but MS seems not have changed much on the C Build environment internally).
Thanks
Hans Buschmann
Attachments:
0001_support_vs2022_v4.patchapplication/octet-stream; name=0001_support_vs2022_v4.patchDownload
diff --git a/postgresql-15devel_orig/doc/src/sgml/install-windows.sgml b/postgresql-15devel_vs2022/doc/src/sgml/install-windows.sgml
index ba794b8..940836a 100644
--- a/postgresql-15devel_orig/doc/src/sgml/install-windows.sgml
+++ b/postgresql-15devel_vs2022/doc/src/sgml/install-windows.sgml
@@ -20,9 +20,9 @@
<para>
There are several different ways of building PostgreSQL on
<productname>Windows</productname>. The simplest way to build with
- Microsoft tools is to install <productname>Visual Studio 2019</productname>
+ Microsoft tools is to install <productname>Visual Studio 2022</productname>
and use the included compiler. It is also possible to build with the full
- <productname>Microsoft Visual C++ 2013 to 2019</productname>.
+ <productname>Microsoft Visual C++ 2013 to 2022</productname>.
In some cases that requires the installation of the
<productname>Windows SDK</productname> in addition to the compiler.
</para>
@@ -69,7 +69,7 @@
<productname>Microsoft Windows SDK</productname>. If you do not already have a
<productname>Visual Studio</productname> environment set up, the easiest
ways are to use the compilers from
- <productname>Visual Studio 2019</productname> or those in the
+ <productname>Visual Studio 2022</productname> or those in the
<productname>Windows SDK 10</productname>, which are both free downloads
from Microsoft.
</para>
@@ -78,7 +78,7 @@
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
32-bit PostgreSQL builds are possible with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>,
+ <productname>Visual Studio 2022</productname>,
as well as standalone Windows SDK releases 8.1a to 10.
64-bit PostgreSQL builds are supported with
<productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
@@ -86,7 +86,7 @@
is supported down to <productname>Windows 7</productname> and
<productname>Windows Server 2008 R2 SP1</productname> when building with
<productname>Visual Studio 2013</productname> to
- <productname>Visual Studio 2019</productname>.
+ <productname>Visual Studio 2022</productname>.
<!--
For 2013 requirements:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
@@ -96,6 +96,8 @@
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
For 2019 requirements:
https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements
+ For 2022 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/releases/2022/system-requirements
-->
</para>
@@ -299,7 +301,7 @@ $ENV{MSBFLAGS}="/m";
<term><productname>LZ4</productname></term>
<listitem><para>
Required for supporting <productname>LZ4</productname> compression
- method for compressing table or WAL data. Binaries and source can be
+ method for compressing the table data. Binaries and source can be
downloaded from
<ulink url="https://github.com/lz4/lz4/releases"></ulink>.
</para></listitem>
diff --git a/postgresql-15devel_orig/src/tools/msvc/MSBuildProject.pm b/postgresql-15devel_vs2022/src/tools/msvc/MSBuildProject.pm
index fdd22e8..cc68400 100644
--- a/postgresql-15devel_orig/src/tools/msvc/MSBuildProject.pm
+++ b/postgresql-15devel_vs2022/src/tools/msvc/MSBuildProject.pm
@@ -505,4 +505,29 @@ sub new
return $self;
}
+package VC2022Project;
+
+#
+# Package that encapsulates a Visual C++ 2022 project file
+#
+
+use strict;
+use warnings;
+use base qw(MSBuildProject);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{vcver} = '17.00';
+ $self->{PlatformToolset} = 'v143';
+ $self->{ToolsVersion} = '17.0';
+
+ return $self;
+}
+
1;
diff --git a/postgresql-15devel_orig/src/tools/msvc/README b/postgresql-15devel_vs2022/src/tools/msvc/README
index f154759..34ea4d5 100644
--- a/postgresql-15devel_orig/src/tools/msvc/README
+++ b/postgresql-15devel_vs2022/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
==========
This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2019. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
the libpq frontend library. For more information, see the documentation
chapter "Installation on Windows" and the description below.
@@ -89,10 +89,10 @@ These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
implementing the Solution interface (this could be either VS2013Solution,
-VS2015Solution, VS2017Solution or VS2019Solution, all in Solution.pm,
+VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in Solution.pm,
depending on the user's build environment) and adding objects implementing
the corresponding Project interface (VC2013Project, VC2015Project,
-VC2017Project or VC2019Project from MSBuildProject.pm) to it.
+VC2017Project,VC2019Project or VC2022Project from MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
The final step of starting the appropriate build program (msbuild) is
diff --git a/postgresql-15devel_orig/src/tools/msvc/Solution.pm b/postgresql-15devel_vs2022/src/tools/msvc/Solution.pm
index a013951..b0726c2 100644
--- a/postgresql-15devel_orig/src/tools/msvc/Solution.pm
+++ b/postgresql-15devel_vs2022/src/tools/msvc/Solution.pm
@@ -1316,6 +1316,34 @@ sub new
return $self;
}
+package VS2022Solution;
+
+#
+# Package that encapsulates a Visual Studio 2022 solution file
+#
+
+use Carp;
+use strict;
+use warnings;
+use base qw(Solution);
+
+no warnings qw(redefine); ## no critic
+
+sub new
+{
+ my $classname = shift;
+ my $self = $classname->SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self->{solutionFileVersion} = '12.00';
+ $self->{vcver} = '17.00';
+ $self->{visualStudioName} = 'Visual Studio 2022';
+ $self->{VisualStudioVersion} = '17.0.31903.59';
+ $self->{MinimumVisualStudioVersion} = '10.0.40219.1';
+
+ return $self;
+}
+
sub GetAdditionalHeaders
{
my ($self, $f) = @_;
diff --git a/postgresql-15devel_orig/src/tools/msvc/VSObjectFactory.pm b/postgresql-15devel_vs2022/src/tools/msvc/VSObjectFactory.pm
index 61e83f5..a865604 100644
--- a/postgresql-15devel_orig/src/tools/msvc/VSObjectFactory.pm
+++ b/postgresql-15devel_vs2022/src/tools/msvc/VSObjectFactory.pm
@@ -61,6 +61,16 @@ sub CreateSolution
{
return new VS2019Solution(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VS2022Solution(@_);
+ }
else
{
croak
@@ -105,6 +115,16 @@ sub CreateProject
{
return new VC2019Project(@_);
}
+
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VC2022Project(@_);
+ }
else
{
croak
@@ -134,7 +154,7 @@ sub DetermineVisualStudioVersion
else
{
# fake version
- return '16.00';
+ return '17.00';
}
}
@@ -143,13 +163,13 @@ sub _GetVisualStudioVersion
my ($major, $minor) = @_;
# The major visual studio that is supported has nmake
- # version <= 14.30, so stick with it as the latest version
+ # version <= 14.40, so stick with it as the latest version
# if bumping on something even newer.
- if ($major >= 14 && $minor >= 30)
+ if ($major >= 14 && $minor >= 40)
{
carp
"The determined version of Visual Studio is newer than the latest supported version. Returning the latest supported version instead.";
- return '14.20';
+ return '14.30';
}
elsif ($major < 12)
{
On Sat, Nov 20, 2021 at 05:54:30PM +0000, Hans Buschmann wrote:
My skills with git are minmal yet and I am working on a correct
development platform, so sorry for any inconveniances from my side.
No need to worry here. We all learn all the time. I have been able
to apply your patch with a "patch -p2", which is fine enough. If you
want to generate cleaner diffs, you could use a "git diff" or a "git
format-patch". Folks around here rely on those commands heavily when
generating patches.
On both platforms the build of snapshot from 19.11.2021 is
successfull but gives the following warnings which seem not
correlated to the proposed patch:
That's fine by me.
Der Buildvorgang wurde erfolgreich ausgeführt.
"C:\pgdev\postgresql-15devel\pgsql.sln" (Standardziel) (1) ->
"C:\pgdev\postgresql-15devel\postgres.vcxproj" (Standardziel) (2) ->
(ClCompile Ziel) ->
C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(858,18): warning C4101: "htup": Unreferenzierte lokale Variable [C:\pgdev\postgresql-15devel\postgres.vcxproj]
C:\pgdev\postgresql-15devel\src\backend\access\heap\pruneheap.c(870,11): warning C4101: "tolp": Unreferenzierte lokale Variable [C:\pgdev\postgresql-15devel\postgres.vcxproj]2 Warnung(en)
0 Fehler(Meaning 2 unreferenced local variables in pruneheap.c)
Those warnings are knows. A commit from Peter G is at the origin of
that but nothing has been done about these yet:
/messages/by-id/YYTTuYykpVXEfnOr@paquier.xyz
So don't worry about that :)
Glad to see that we should have nothing to do about locales this
time. I have not tested, but I think that you covering all the areas
that need a refresh here. Nice work.
+ # The version of nmake bundled in Visual Studio 2022 is greater
+ # than 14.30 and less than 14.40. And the version number is
+ # actually 17.00.
+ elsif (
+ ($visualStudioVersion ge '14.30' && $visualStudioVersion lt '14.40')
+ || $visualStudioVersion eq '17.00')
+ {
+ return new VS2022Solution(@_);
+ }
Wow, really? MSVC has not yet simplified their version numbering with
nmake.+VC2017Project,VC2019Project or VC2022Project from MSBuildProject.pm) to it.
Nit: you should use a space when listing elements in a comma-separated
list.
- method for compressing table or WAL data. Binaries and source can be
+ method for compressing the table data. Binaries and source can be
Diff unrelated to your patch. I'll double-check your patch later, but that looks rather good to me.
Will try to apply and back-patch, and it would be better to check the
version numbers assigned in the patch, as well.
--
Michael
On Sun, Nov 21, 2021 at 10:41:17AM +0900, Michael Paquier wrote:
I'll double-check your patch later, but that looks rather good to me.
Will try to apply and back-patch, and it would be better to check the
version numbers assigned in the patch, as well.
I have spent a couple of hours on that today, and applied that down to
10 so as all branches benefit from that. There was a hidden problem
in 10 and 11, where we need to be careful to use VC2012Project as base
in MSBuildProject.pm.
Thanks, Hans!
--
Michael
Hello Michael,
thanks for your hard work and quick response!
It is very convenient to only use VS2022 for Windows from now on...
Diff unrelated to your patch.
Sorry for the copysoft problem from the first version.
Glad to see that we should have nothing to do about locales this
time. I have not tested, but I think that you covering all the areas
that need a refresh here. Nice work.
I think it is almost impossible to overestimate the value of such support from experienced hackers to others starting their journey right now...
I hope I can motivate you (and other experienced hackers) to give me some more support on my real project arriving anytime soon. It addresses hex_encoding (and more) targetting mostly pg_dump, but requires also some deeper knowledge of general infrastructure and building (also on Windows). Stay tuned!
PS: Does anybody have good relations to EDB suggesting them to target VS2022 as the build environment for the upcoming PG15 release?
postgres=# select version ();
version
------------------------------------------------------------
PostgreSQL 14.1, compiled by Visual C++ build 1931, 64-bit
(1 row)
Thanks!
Hans Buschmann
Hi
On Wed, Nov 24, 2021 at 9:12 AM Hans Buschmann <buschmann@nidsa.net> wrote:
Hello Michael,
thanks for your hard work and quick response!
It is very convenient to only use VS2022 for Windows from now on...Diff unrelated to your patch.
Sorry for the copysoft problem from the first version.
Glad to see that we should have nothing to do about locales this
time. I have not tested, but I think that you covering all the areas
that need a refresh here. Nice work.I think it is almost impossible to overestimate the value of such support
from experienced hackers to others starting their journey right now...I hope I can motivate you (and other experienced hackers) to give me some
more support on my real project arriving anytime soon. It addresses
hex_encoding (and more) targetting mostly pg_dump, but requires also some
deeper knowledge of general infrastructure and building (also on Windows).
Stay tuned!PS: Does anybody have good relations to EDB suggesting them to target
VS2022 as the build environment for the upcoming PG15 release?
That would be me...
postgres=# select version ();
version
------------------------------------------------------------
PostgreSQL 14.1, compiled by Visual C++ build 1931, 64-bit
(1 row)
It's extremely unlikely that we'd shift to such a new version for PG15. We
build many components aside from PostgreSQL, and need to use the same
toolchain for all of them (we've had very painful experiences with mix n
match CRT versions in the past) so it's not just PG that needs to support
VS2022 as far as we're concerned - Perl, Python, TCL, MIT Kerberos,
OpenSSL, libxml2, libxslt etc. are all built with the same toolchain for
consistency.
--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake
On Wed, Nov 24, 2021 at 10:00:19AM +0000, Dave Page wrote:
It's extremely unlikely that we'd shift to such a new version for PG15. We
build many components aside from PostgreSQL, and need to use the same
toolchain for all of them (we've had very painful experiences with mix n
match CRT versions in the past) so it's not just PG that needs to support
VS2022 as far as we're concerned
Yes, I can understand that upgrading the base version of VS used is a
very difficult exercise. I have been through that, on Windows for
Postgres.. As well as for the compilation of all its dependencies.
- Perl, Python, TCL, MIT Kerberos,
OpenSSL, libxml2, libxslt etc. are all built with the same toolchain for
consistency.
Dave, do you include LZ4 in 14? Just asking, as a matter of
curiosity.
--
Michael
Hi
On Wed, Nov 24, 2021 at 11:36 AM Michael Paquier <michael@paquier.xyz>
wrote:
On Wed, Nov 24, 2021 at 10:00:19AM +0000, Dave Page wrote:
It's extremely unlikely that we'd shift to such a new version for PG15.
We
build many components aside from PostgreSQL, and need to use the same
toolchain for all of them (we've had very painful experiences with mix n
match CRT versions in the past) so it's not just PG that needs to support
VS2022 as far as we're concernedYes, I can understand that upgrading the base version of VS used is a
very difficult exercise. I have been through that, on Windows for
Postgres.. As well as for the compilation of all its dependencies.- Perl, Python, TCL, MIT Kerberos,
OpenSSL, libxml2, libxslt etc. are all built with the same toolchain for
consistency.Dave, do you include LZ4 in 14? Just asking, as a matter of
curiosity.
Yes we do :-)
C:\Program Files\PostgreSQL\14\bin>pg_config
BINDIR = C:/PROGRA~1/POSTGR~1/14/bin
DOCDIR = C:/PROGRA~1/POSTGR~1/14/doc
HTMLDIR = C:/PROGRA~1/POSTGR~1/14/doc
INCLUDEDIR = C:/PROGRA~1/POSTGR~1/14/include
PKGINCLUDEDIR = C:/PROGRA~1/POSTGR~1/14/include
INCLUDEDIR-SERVER = C:/PROGRA~1/POSTGR~1/14/include/server
LIBDIR = C:/Program Files/PostgreSQL/14/lib
PKGLIBDIR = C:/Program Files/PostgreSQL/14/lib
LOCALEDIR = C:/PROGRA~1/POSTGR~1/14/share/locale
MANDIR = C:/Program Files/PostgreSQL/14/man
SHAREDIR = C:/PROGRA~1/POSTGR~1/14/share
SYSCONFDIR = C:/Program Files/PostgreSQL/14/etc
PGXS = C:/Program Files/PostgreSQL/14/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = --enable-thread-safety --enable-nls --with-ldap
--with-ssl=openssl --with-uuid --with-libxml --with-libxslt --with-lz4
--with-icu --with-tcl --with-perl --with-python
CC = not recorded
CPPFLAGS = not recorded
CFLAGS = not recorded
CFLAGS_SL = not recorded
LDFLAGS = not recorded
LDFLAGS_EX = not recorded
LDFLAGS_SL = not recorded
LIBS = not recorded
VERSION = PostgreSQL 14.1
--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake