AW: VS2022: Support Visual Studio 2022 on Windows

2021-11-24 Thread Hans Buschmann
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




AW: VS2022: Support Visual Studio 2022 on Windows

2021-11-20 Thread Hans Buschmann
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


0001_support_vs2022_v4.patch
Description: 0001_support_vs2022_v4.patch


AW: VS2022: Support Visual Studio 2022 on Windows

2021-11-06 Thread Hans Buschmann
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



0001_support_vs2022_v2.patch
Description: 0001_support_vs2022_v2.patch


Re: AW: VS2022: Support Visual Studio 2022 on Windows

2021-10-13 Thread Andrew Dunstan


On 10/13/21 3:49 PM, Tom Lane wrote:
> Hans Buschmann  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





Re: AW: VS2022: Support Visual Studio 2022 on Windows

2021-10-13 Thread Tom Lane
Hans Buschmann  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




AW: VS2022: Support Visual Studio 2022 on Windows

2021-10-13 Thread Hans Buschmann
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

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.

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 
Gesendet: Montag, 11. Oktober 2021 08:03
An: Andrew Dunstan
Cc: Laurenz Albe; Hans Buschmann; pgsql-hack...@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