Re: Clean up some old cruft related to Windows - Mailing list pgsql-hackers

From Juan José Santamaría Flecha
Subject Re: Clean up some old cruft related to Windows
Date
Msg-id CAC+AXB0F99J7G+ttpTAzjAd=Nex3PNR++w8swDNCeV3CpSoCqQ@mail.gmail.com
Whole thread Raw
In response to Re: Clean up some old cruft related to Windows  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Clean up some old cruft related to Windows
List pgsql-hackers

On Thu, Feb 20, 2020 at 4:23 AM Michael Paquier <michael@paquier.xyz> wrote:

+  You can change certain build options, such as the targeted CPU
+  architecture, build type, and the selection of the SDK by using either
+  <command>VSVARS32.bat</command> or <command>VsDevCmd.bat</command> depending
+  on your <productname>Visual Studio</productname> release. All commands
+  should be run from the <filename>src\tools\msvc</filename> directory.
 
I think more parts of this paragraph need tuning, like:

"In Visual Studio, start the Visual Studio Command Prompt. If you wish to build a 64-bit version, you must use the 64-bit version of the command, and vice versa."

This is what VsDevCmd.bat does, seting up the Visual Studio Command Prompt, but from the command-line.

Also the following:

"In the Microsoft Windows SDK, start the CMD shell listed under the SDK on the Start Menu."

This is not the case, you would be working in the CMD setup previously from Visual Studio.
 
 And I am not actually sure which
environment variable to touch when using VSVARS32.bat or
VSVARSALL.bat with MSVC <= 2017.

Actually, you can still use the vcvars% scripts to configure architecture, platform_type and winsdk_version with current VS [1].

Both commands have different ways of doing things, and don't really
shine with their documentation

I hear you.

Please find attached a new version that addresses these issues.


Regards,

Juan José Santamaría Flecha
Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Minor improvement to partition_bounds_copy()
Next
From: Thomas Munro
Date:
Subject: Re: Experimenting with transactional memory for SERIALIZABLE