Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: fix detection of Visual Studio 2017 #30119

Merged
merged 1 commit into from
Nov 5, 2019

Conversation

richardlau
Copy link
Member

@richardlau richardlau commented Oct 25, 2019

When run in a Visual Studio 2017 command prompt the VCINSTALLDIR
environment variable will be already set and is not cleared by the
tools/msvs/vswhere_usability_wrapper.cmd utility when it fails to
find Visual Studio 2019. This causes vcbuild.bat to incorrectly
assume Visual Studio 2019 and generate an incompatible configuration.

Clearing the value of VCINSTALLDIR before calling the utility fixes
the detection logic.

Fixes: #30118
Refs: #30022

cc @nodejs/platform-windows @nodejs/build-files @targos

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. windows Issues and PRs related to the Windows platform. labels Oct 25, 2019
@nodejs-github-bot

This comment has been minimized.

@richardlau richardlau changed the title build: fix detection of VS 2019 on Windows build: fix detection of VS 2017 on Windows Oct 25, 2019
@richardlau richardlau changed the title build: fix detection of VS 2017 on Windows build: fix detection of Visual Studio 2017 Oct 25, 2019
@targos
Copy link
Member

targos commented Oct 25, 2019

do you know why it's not found in the Look for Visual Studio 2017 block?

@targos
Copy link
Member

targos commented Oct 25, 2019

Maybe we need to change the argument to call tools\msvs\vswhere_usability_wrapper.cmd "[16.0,17.0)"

@richardlau
Copy link
Member Author

do you know why it's not found in the Look for Visual Studio 2017 block?

Because it doesn't get there. See the debug in #30118 (comment).

@richardlau
Copy link
Member Author

richardlau commented Oct 25, 2019

Or to be more specific in this block:

node/vcbuild.bat

Lines 239 to 272 in 11275dc

@rem Look for Visual Studio 2019
:vs-set-2019
if defined target_env if "%target_env%" NEQ "vs2019" goto vs-set-2017
echo Looking for Visual Studio 2019
call tools\msvs\vswhere_usability_wrapper.cmd "[16.0,17.0)"
if "_%VCINSTALLDIR%_" == "__" goto vs-set-2017
if defined msi (
echo Looking for WiX installation for Visual Studio 2019...
if not exist "%WIX%\SDK\VS2017" (
echo Failed to find WiX install for Visual Studio 2019
echo VS2019 support for WiX is only present starting at version 3.11
goto vs-set-2017
)
if not exist "%VCINSTALLDIR%\..\MSBuild\Microsoft\WiX" (
echo Failed to find the WiX Toolset Visual Studio 2019 Extension
goto vs-set-2017
)
)
@rem check if VS2019 is already setup, and for the requested arch
if "_%VisualStudioVersion%_" == "_16.0_" if "_%VSCMD_ARG_TGT_ARCH%_"=="_%target_arch%_" goto found_vs2019
@rem need to clear VSINSTALLDIR for vcvarsall to work as expected
set "VSINSTALLDIR="
@rem prevent VsDevCmd.bat from changing the current working directory
set "VSCMD_START_DIR=%CD%"
set vcvars_call="%VCINSTALLDIR%\Auxiliary\Build\vcvarsall.bat" %vcvarsall_arg%
echo calling: %vcvars_call%
call %vcvars_call%
if errorlevel 1 goto vs-set-2017
if defined DEBUG_HELPER @ECHO ON
:found_vs2019
echo Found MSVS version %VisualStudioVersion%
set GYP_MSVS_VERSION=2019
set PLATFORM_TOOLSET=v142
goto msbuild-found

On my system:

  • %VCINSTALLDIR% comes back as C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\ so the if test on L244 doesn't pass and it continues into the Looking for Visual Studio 2019 block.
  • The WiX test passes because apparently WiX uses the 2017 directory for 2019 too.
  • The test on L258 doesn't pass because %VisualStudioVersion% is 15.0.
  • The call %vcvars_call% on L265 succeeds so the if errorlevel test on the next line doesn't match and we drop into found_vs2019.

It looks like on the CI (which uses VS2017) %VCINSTALLDIR% is coming back empty. Perhaps this is a difference between the Professional (which I have) and Community (on the CI) editions of Visual Studio? Or is it something with tools\msvs\vswhere_usability_wrapper.cmd?

@richardlau
Copy link
Member Author

It looks like on the CI (which uses VS2017) %VCINSTALLDIR% is coming back empty. Perhaps this is a difference between the Professional (which I have) and Community (on the CI) editions of Visual Studio? Or is it something with tools\msvs\vswhere_usability_wrapper.cmd?

Ah, it's probably because I build Node.js inside a "Developer Command Prompt for VS 2017" command prompt which has set up that environment variable.

@richardlau
Copy link
Member Author

I've got a build going at the moment but when it completes I'll try clearing VCINSTALLDIR before we call tools\msvs\vswhere_usability_wrapper.cmd.

@richardlau richardlau added the wip Issues and PRs that are still a work in progress. label Oct 25, 2019
@richardlau richardlau removed the wip Issues and PRs that are still a work in progress. label Oct 25, 2019
@richardlau
Copy link
Member Author

@targos I've updated this PR. Turns out all we need to do is clear the value of the VCINSTALLDIR environment variable before calling tools/msvs/vswhere_usability_wrapper.cmd so that the subsequent logic works properly.

@nodejs-github-bot
Copy link
Collaborator

@richardlau richardlau added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Oct 26, 2019
@targos
Copy link
Member

targos commented Oct 27, 2019

@joaocgreis

Copy link
Member

@joaocgreis joaocgreis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @richardlau!

@@ -240,6 +240,7 @@ if %target_arch%==x86 if %msvs_host_arch%==x86 set vcvarsall_arg=x86
:vs-set-2019
if defined target_env if "%target_env%" NEQ "vs2019" goto vs-set-2017
echo Looking for Visual Studio 2019
set "VCINSTALLDIR="
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
set "VCINSTALLDIR="
@rem VS2017 is detected here when VCINSTALLDIR is set (as in VS Command Prompt)
set "VCINSTALLDIR="

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, this is just a suggestion. Feel free to take it, change it as you see fit or leave it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a (different) comment. PTAL.

@richardlau richardlau force-pushed the vs2017 branch 2 times, most recently from dcdd328 to 07c4965 Compare October 31, 2019 05:39
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

nodejs-github-bot commented Oct 31, 2019

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

When run in a Visual Studio 2017 command prompt the `VCINSTALLDIR`
environment variable will be already set and is not cleared by the
`tools/msvs/vswhere_usability_wrapper.cmd` utility when it fails to
find Visual Studio 2019. This causes `vcbuild.bat` to incorrectly
assume Visual Studio 2019 and generate an incompatible configuration.

Clearing the value of `VCINSTALLDIR` before calling the utility fixes
the detection logic.

PR-URL: nodejs#30119
Fixes: nodejs#30118
Refs: nodejs#30022
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: João Reis <[email protected]>
@richardlau richardlau merged commit 1f2fdc9 into nodejs:master Nov 5, 2019
@richardlau
Copy link
Member Author

Landed in 1f2fdc9

@richardlau richardlau deleted the vs2017 branch November 5, 2019 04:03
targos pushed a commit that referenced this pull request Nov 5, 2019
When run in a Visual Studio 2017 command prompt the `VCINSTALLDIR`
environment variable will be already set and is not cleared by the
`tools/msvs/vswhere_usability_wrapper.cmd` utility when it fails to
find Visual Studio 2019. This causes `vcbuild.bat` to incorrectly
assume Visual Studio 2019 and generate an incompatible configuration.

Clearing the value of `VCINSTALLDIR` before calling the utility fixes
the detection logic.

PR-URL: #30119
Fixes: #30118
Refs: #30022
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: João Reis <[email protected]>
@targos targos mentioned this pull request Nov 5, 2019
@richardlau richardlau mentioned this pull request Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. build Issues and PRs related to build files or the CI. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

vcbuild.bat fails with Visual Studio 2017
5 participants