VS2022: Support Visual Studio 2022 on Windows - Mailing list pgsql-hackers

From Hans Buschmann
Subject VS2022: Support Visual Studio 2022 on Windows
Date
Msg-id 1633101364685.39218@nidsa.net
Whole thread Raw
Responses Re: VS2022: Support Visual Studio 2022 on Windows  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
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
supportto 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
changeallways 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
separatelychoosable as compile environment. 

Compilation time and file sizes are almost identical, but the GUI promises a native 64bit implementation, so it may
appealingto 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
anotherthread (if the Windows 32bit Version is still important to support on newer VS Versions) 

Thanks for looking at it

Hans Buschmann


Attachment

pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Multi-Column List Partitioning
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file