MSVC Build: Support VS2017 or VS2015 compiler tools

[jeffhostetler]

Teach Makefile to use whatever VS compiler tool chain
is installed on the system.

Previously I had hard-coded paths to VS2015. This change
uses the new VsWhere.exe and VsDevCmd.bat in a background
Command Prompt process to compute the proper environment
variables for bash and make.

If VS2017u2 or higher is installed, it will use the
compiler, linker, libaries associated with it.

It will fall back to the previous configuration using
VS2015. It should be fairly easy to extend the fallback
section in the "find_vs_env.bat" script to support older
compilers.

I have tested this with VS2017.3 (Dev15.3) and the V140
command line tools (distributed with VS2015).

Signed-off-by: Jeff Hostetler jeffhost@microsoft.com

Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
bug reports. Nevertheless, you can use submitGit to conveniently send your Pull
Requests commits to our mailing list.

Please read the "guidelines for contributing" linked above!

[mfriedrich74]

Each Visual Studio version creates an environment variable pointing somewhere into its installation folder. That can be used derive correct settings or to call its vcvars.bat. Best regards, Mike

…

On Sat, Aug 19, 2017, 11:30 AM Danila Malyutin ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In compat/vcbuild/find_vs_env.bat <#1273 (comment)>: > +REM ------ +REM Visual Studio 2015 uses the traditional VcVarsAll. +REM +REM Earlier Versions +REM ---------------- +REM TODO +REM +REM ================================================================ +REM Note: Throughout this script we use "dir <path> && <cmd>" rather +REM than "if exist <path>" because of script problems with pathnames +REM containing spaces. +REM ================================================================ + +REM Sanitize PATH to prevent git-sdk paths from confusing "wmic.exe" +REM (called internally in some of the system BAT files). +SET PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; Sorry if I misunderstood something but is this scripted is to be used by the git developers (not build bots)? If so, It doesn't look like a good idea to hard-code drive C everywhere. For instance, on my PC windows is installed on drive G and IRC starting from VS2017 visual studio is not bound to a system drive either (I'm not sure whether vswhere is still installed to the default %programfiles(x86)%) . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1273 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHJ-yOQoS9VgGKkntRo2kiUt5mEn3b3hks5sZv9-gaJpZM4O60Ht> .

[danilaml]

@mfriedrich74 doesn't seem to be the case starting from VS2017 and going forward (if I understood this correctly).

[dscho]

Thanks all, in particular @jeffhostetler for the original work and @danilaml for the thorough and very helpful review!

[jeffhostetler]

@mfriedrich74 Yes, it is a bit confusing. The layout of VS2017 (and beyond) is different from the layout of VS2015 which was different from earlier layouts. Yes, the stock install does/can set an environment variable pointing at the installation directory, or adds the directory containing the vcvars to the PATH, but we want to go a little deeper here and get the proper values for the "-I" and "-L" args to CL.exe. Those change between versions. For example, VS2015 introduced the UCRT and Windows Kits changes, so builds based on it or newer, have different values from previous generations.

So my script tries to find the most recent version of VS installed and build the version-specific compiler flags.

I left the TODO at the bottom because I cannot test the earlier versions (I don't have any of them installed). Also, I've not built it with the earlier tools and there might be compiler errors and etc.,
so I didn't just want to assume it would work. The existing TODO and overall layout of the script
should make it easy for someone to extend it if/when necessary.

Thanks!

[dscho]

... because I cannot test the earlier versions (I don't have any of them installed).

@PhilipOakley maybe you are interested?

[PhilipOakley]

... because I cannot test the earlier versions (I don't have any of them installed).

@PhilipOakley maybe you are interested?

While I'm interested, unfortunately I'm rather time poor at the moment,

I will add it as part of my long todo list, but don't hold your breath just yet.