-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
win: find and setup for VS2017 #1130
Conversation
Personally I would move logic from the C# to JS. I like that you use more of the information available to us from the COM, but I would filter and choose in JS. I also like the idea of a log, but maybe if the C# prints everything, there will be no need. |
Reviewed-By: João Reis <reis@janeasystems.com>
aa8626e
to
1f79c98
Compare
Updated, fixed failure when there's no usable installation and store the MSBuild executable path in config so that it can respect Tested (with node v7 on Windows 7):
|
Is this PR taking a dependency on powershell and the C# compiler? That... seems unfortunate. |
PR-URL: #1130 Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
@bnoordhuis it does, but those two are installed by default everywhere I've looked. To make node-gyp work out of the box in the platforms we support, it's either this, |
Merging is a little premature. There has been no sign-off from a committer and you didn't run the CI either. |
LGTM(ish) I'll make a future PR with some more changes 😉 |
lib/build.js
Outdated
@@ -14,7 +14,9 @@ var fs = require('graceful-fs') | |||
, mkdirp = require('mkdirp') | |||
, exec = require('child_process').exec | |||
, processRelease = require('./process-release') | |||
, win = process.platform == 'win32' | |||
, win = process.platform === 'win32' | |||
if (win) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need this if you already injected config.variables.msbuild_path
(which is smart)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@bnoordhuis CI is green, do you want to review? I think this is important to have, what should I do to move this forward? |
cc @nodejs/node-gyp @nodejs/build |
Updated: changed the MSBuild dependency component. Installing only MSBuild does not make it usable for C++ if the workload is not installed. But installing "Visual Studio C++ core features" is enough, includes MSBuild.exe and the necessary files to make it usable. |
@bnoordhuis, @rvagg PTAL |
working on this now FYI, had to get a few other pressing things out of the way but I'm reviewing and testing this out for myself now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requested some minor changes and a bit of feedback. If the 2015->2017 thing is a GYP hack then the rest are just minor fixes.
Tested in a few different configurations myself, works as it should. The .cs thing is unfortunate but I understand the rationale and don't think it's ultimately a big deal. 👍 and thanks for the hard work folks.
lib/configure.js
Outdated
@@ -137,6 +139,18 @@ function configure (gyp, argv, callback) { | |||
// disable -T "thin" static archives by default | |||
variables.standalone_static_library = gyp.opts.thin ? 0 : 1 | |||
|
|||
if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would you mind inverting this? reads really badly. (win && (!gyp.opts.msvs_version || gyp.opts.msvs_version === '2017'))
lib/configure.js
Outdated
if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) { | ||
const vsSetup = findVS2017() | ||
if (vsSetup) { | ||
gyp.opts.msvs_version = '2015' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we forcing this to make GYP happy, or is this (and the next line) a mistake?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are forcing this to make GYP happy, and to avoid pulling https://chromium-review.googlesource.com/#/c/433540/ (which did not land yet) as a floating patch, since floating patches seem to be avoided here.
lib/find-vs2017.js
Outdated
|
||
var vsSetup | ||
try { | ||
const vsSetupRaw = execSync(psQuery, { encoding: 'utf8' }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var
for consistency, also given that node-gyp still works for very old versions of Node
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I mean, s/var/const
in this entire file
lib/configure.js
Outdated
@@ -137,6 +139,18 @@ function configure (gyp, argv, callback) { | |||
// disable -T "thin" static archives by default | |||
variables.standalone_static_library = gyp.opts.thin ? 0 : 1 | |||
|
|||
if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) { | |||
const vsSetup = findVS2017() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/const/var
@@ -0,0 +1,262 @@ | |||
// powershell -ExecutionPolicy Unrestricted -Version "2.0" -Command "&{Add-Type -Path Find-VS2017.cs; [VisualStudioConfiguration.Main]::Query()}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this file need source attribution and/or copyright? or is it ours?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote it myself. GUIDs extracted from interop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add
// Copyright 2017 - Refael Ackermann
// Distributed under MIT style license
// See accompanying file LICENSE at https://github.com/node4good/windows-autoconf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend using updated file https://github.com/node4good/windows-autoconf/blob/master/tools/GetVS2017Configuration.cs
@rvagg updated, PTAL. About the 2015->2017 GYP hack, my comment above is hidden by GitHub:
|
|
@joaocgreis let's get this published today. Clean it up and get it merged and we'll publish and then PR npm to get it there too. Ping me on IRC when you're around and want to move forward. |
PR-URL: #1130 Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Rod Vagg <rod@vagg.org>
Landed in ae141e1 |
v3.6.0 released, thanks for the hard work on this @refack, @joaocgreis, @bzoz and anyone else who contributed, not a small effort |
Attempted PRs to npm (I always get seem to get this process wrong):
|
OK, looks like we might not be getting v4 compatibility for VS 2017 from npm unless we patch it ourselves I guess @nodejs/lts npm/npm#16049 |
What's needed for v4 compat? Can I help? |
@refack issue is that Node 4 is going into maintenance mode soon, so there might not be another update to npm before that time. The ping to @nodejs/lts is for the LTS team to decide whether it's worth doing another v4 release to pick up the npm update. FWIW, I think it's worth updating to support VS2017 in Node 4 (but then I won't have to do the release). |
@gibfahn, thanks |
I'm not sure that was read from the comment correctly but it could be the case. |
Based on that comment, if we can get it into Node v4, we can get it into npm. Node v4 goes into maintenance mode on 2017-04-01, i.e. in ten days. Whichever way we go, we need to make a decision ASAP. |
👎 |
@joaocgreis, @rvagg Let's fast track #1153 |
"Bring back VS150COMNTOOLS" |
else if (id == "Microsoft.VisualStudio.Component.VC.Tools.x86.x64") | ||
hasVCTools = true; | ||
else if (id.StartsWith(Win10SDKPrefix)) | ||
Win10SDKVer = Math.Max(Win10SDKVer, UInt32.Parse(id.Substring(Win10SDKPrefix.Length))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug found with new SDK #1144
The officially supported vswhere tool is now available as part of the install starting today with Visual Studio 15.2 preview 2: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed-with-visual-studio-2017/. This doesn't fix all the existing installs of VS 2017 but going forward you can now detect the VS install locations and whether C++ tools are available from a scripted environment. I hope this helps your scenario. |
One approach is to download VSWhere as a fallback if not available and completely rely on it to find VS2017: # powershell
$vswherePath = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe";
if (!(Test-Path $vswherePath)) {
$latestReleaseTag = $(curl https://api.github.com/repos/Microsoft/vswhere/releases/latest | `
ConvertFrom-Json) | % { $_.tag_name };
$vswherePath = "$pwd\vswhere.exe";
curl -O $vswherePath `
https://github.com/Microsoft/vswhere/releases/download/$latestReleaseTag/vswhere.exe;
}
$vsBase = &$vswherePath -latest -products * `
-requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 `
-property installationPath;
if (!$vsBase) {
throw "VS or MSVC component is not installed";
}
&"$vsBase\vc\Auxiliary\Build\vcvars64.bat";
# now link.exe, cl.exe etc. are in PATH
# or write vsvars path to stdout for the caller (MSBuild Exec task)
echo $vsBase\vc\Auxiliary\Build\vcvars64.bat; However, in practice, vswhere is available in a deterministic location when we have VS or buildtools installed, then downloading is sort of moot if we don't want to support non-ProgramFiles installs (e.g. https://github.com/dotnet/corert/blob/378ad6a/src/BuildIntegration/findvcvarsall.bat). |
Patch Set 4: Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. Patch-set: 4
Patch Set 4: > Patch Set 4: > > Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) > > In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. We could also assume the default install location and allow users to set an environment variable if they have a non-default install. That is what Chrome is doing - the complexity of the COM solution didn't seem justified, at least initially. Patch-set: 4 Reviewer: Gerrit User 1128439 <1128439@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>
Patch Set 4: > Patch Set 4: > > Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) > > In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. Obviously, but I like this solution for this project, it's good enough... ... ... ... ... ... ... You know what, I'll make another PR with the full script Patch-set: 4 Reviewer: Gerrit User 1188132 <1188132@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>
Patch Set 9: > Patch Set 9: > > > Patch Set 9: > > > > > AFAIK that all correct. > > > also: > > > - MS are not likely to change this logic till SP1 (if even) > > > - Meanwhile `GYP` based projects (i.e. `node-gyp`, `node`, `libuv` that I know of) have been floating patches of their own... > > > > > > Detection logic aside, we should land either this or 453201, since all the VS2017 issues are becoming a major PITA > > > > Okay, I agree that we should land something as this has dragged on too long and we should have VS2017 support. > > > > For now, since > > 1) we have no reason to think that the registry-based approach doesn't work, and that that's what GN is using, > > 2) and that I don't know who can actually review the PS/C# code for correctness or support it besides you, > > > > I think the registry approach is the better way to go, and hopefully MS will change their course. If it turns out that the registry approach breaks or becomes otherwise problematic, I'm fine w/ taking this code for both GYP and GN until we get a better solution. > > > > Does that work for you? > > If you mean 453201, sure! Ohh, P.S. the C#/PS code has landed in `node-gyp` nodejs/node-gyp#1130 and `Boost/build` boostorg/build#170 But NM Patch-set: 9 Reviewer: Gerrit User 1188132 <1188132@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>
Reviewed #1103 :
cc @refack @bzoz can you review?