-
Notifications
You must be signed in to change notification settings - Fork 39
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
GPII-4355: Updated build scripts and projects to use VS2017 build tools #295
base: master
Are you sure you want to change the base?
Conversation
Could one of the admins verify that these changes are reasonable to test? If so, please reply with "ok to test". |
ok to test |
CI job failed: https://ci.gpii.net/job/windows-tests/1207/ |
While we're waiting to update CI to install VS2017 build tools, here is the log of a manual checkout/build from a local VM. [Build successful] |
…app release (i.e. not dev)
CI job failed: https://ci.gpii.net/job/windows-tests/1208/ |
ok to test |
CI job failed: https://ci.gpii.net/job/windows-tests/1209/ |
ok to test |
CI job failed: https://ci.gpii.net/job/windows-tests/1457/ |
This PR, combined with the gpii-app/GPII-4355 PR, should fully enable Morphic for Windows to compile using modern (VS2017) developer tools and Node.js v10.16.3.
Please note that this branch is based on the current "master" branch of GPII/windows (which contains a bug which is preventing most of the "set" Settings Handlers from working). However it should be able to be merged with any recent production-quality commit in the master branch.
Critical: developers must upgrade their developer environment to Visual Studio 2017. The new build scripts use Microsoft's new "vswhere" utility (included with VS2017+) to locate MSBuild, CSC, environment variables, etc. This is a hard fork in the road...and we will need all the developers on our team (plus the CI environment) to move to VS2017 when this goes "live" in master.
For the future: The $visualStudioVersion PowerShell variable has been designed to support either a specific version (e.g. "15.0" for VS2017) or a range (e.g. "[15.0,16.0)" as an inclusive range for any VS2017'ish releases from v15.0 to v15.9999999999). This means that as we want to start adding support for VS2019 or other newer releases, we can simplly update the $visualStudioVersion variable to include a wider range of compiler versions. Our build may indeed be compatible with VS2019 as well, but I have not tested with VS2019 due to the fact that Electron still uses VS2017 in their documentation.