Install VS2017 on all build machines

[sxa]

Oracle are switching to supporting VS2017 builds, so we should too:
Ref: https://bugs.openjdk.java.net/browse/JDK-8201267 and eclipse-openj9/openj9#1697

[johanvos]

Note that there is a compiler bug in recent versions of VS2017 that prevents JavaFX (at least webkit) from being built for now: https://bugs.openjdk.java.net/browse/JDK-8210218
(this should not block you, as we're not even close to have an Ansible setup for JavaFX on windows)

[sxa]

That's ok - this shouldn't result in earlier versions being removed - it would be an addition for now. But thanks for that info - useful to be aware of it.

[sxa]

I've heard from a colleague on the infrastructure call today that there may be some conflicts installing VS2017 on machines that have the earlier versions so we're going to do some investigation before pushing this forward

[jdekonin]

The conflicts as I found our are related to the version of mingw installed on the machine. OpenJ9 only compiles with specific versions in when VS2017 is used.

#422 was the commit for VS2017 required changes, but there is no mention of version of mingw that should be used. That can be inferred through the openj9 build instructions here in the Windows section :
https://github.com/eclipse/openj9/blob/master/buildenv/Build_Instructions_V11.md#windows

I am not sure if the mingw v8.1 tooling will work alongside older VS installs. I have a student working on the addition to the playbook which should be coming in the next few days.

[johanvos]

The problems we have occur exactly when there are 2 versions installed, and different environment variables point to conflicting versions. Hopefully you won't run into it, but it caused lots of headaches :)

[sxa]

Hopefully you won't run into it

Do you have reason to believe we won't see the same problems as you did @johanvos? We are planning to have them both installed on our machines so we need to know this will have no risk of destabilising our use of either version.

[jdekonin]

@vsebe has VS2010, VS2013, and VS2017 installed on each of the 4 Windows 2012 Server machines on the OpenJ9 jenkins.

There are further changes required (mingw 8.1) as detail in the url above that I believe @vsebe is working on for adding to the playbook. Currently there is a defect open against OMR for compilation failure within DDR; eclipse-omr/omr#2885

[jdekonin]

#479

[sxa]

@johanvos Can you please clarify your "Hopefully you won't run into it" assertion and would like to understand why you believe that to be the case. Has @vsebe seen any of them?
@jdekonin Do you know if that OMR issue related specifically to VS2017 or MinGW?

[jdekonin]

Its a hard fail with VS2017, VS2013 still compiles fine. OpenJ9 won't be moving to VS2017 until this defect is resolved and there is a clean compile.

[vsebe]

Please note there are two versions of MinGW:

• the cygwin packages (gcc 5.4 or newer but less than 8.1) required to build OpenJ9 extensions for OpenJDK8 & OpenJDK10 - using VS 2010, 2013 toolchains
• MinGW-W64 v5 (gcc 8.1.0) required to build OpenJ9 extensions for OpenJDK11 (for now) with VS2017 toolchain. MinGW-W64 is installed in different location (see WIP: Install MinGW-W64 on Windows #479) than the cygwin package and has to be added first to the PATH.

[sxa]

@vsebe So if we're going to move to VS2017 everywhere for OpenJ9 then the version installed in PR479 should be adequate - is that correct? I'll aim to get one of our build machines in a suitable state for this.

[sxa]

https://ci.adoptopenjdk.net/label/windows&&x64&&buildj9/ are the current J9 build machines - I'll start putting the newer versions on https://ci.adoptopenjdk.net/computer/build-softlayer-win2012r2-x64-2/ (37.58.103.196)

[vsebe]

@sxa555 - yes, the MinGW from PR#479 is adequate.

[sxa]

@vsebe Is the install location specified in that PR - C:\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0 - the one that the OpenJ9 build process will look for explicitly or does the bin directory in there need to be added to the PATH somewhere as a separate step?

[sxa]

Going to remove the buildj9 tag from https://ci.adoptopenjdk.net/computer/build-softlayer-win2012r2-x64-1/ for now to force all OpenJ9 builds onto the new -2 machine.

(This will probably temporarily lock out our ability to run Win32 OpenJ9 builds)

[vsebe]

@sxa555 - fyi the OpenJ9 is investigating using Clang instead of mingw on Windows(eclipse-openj9/openj9#2469 (comment))

[sxa]

Bumping to next milestone - installed and tested on one machine so solves the immediate need.

[mwornast]

To set expectations this is not going to be solved this Month. I am about to go on leave. Realistic timeline is mid October.

@sej-jackson Maybe you want to pick this up.

[gdams]

@sxa555 assume this can be closed? VS2017 is in the playbook and installed on all build machines