Enhancing jaotc to automatically find VS2017 linker

[Andrew Luo]

Right, that's a good idea.  I had thought about this a bit previously, but since what we have right now already works, I haven't spent much time on it.  (Right now I'm still looking to get WSL tests working first, but if this isn't done after that I might be able to look into it further)

Thanks,

-Andrew

From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Monday, January 21, 2019 12:36 AM
To: build-dev <build-dev at openjdk.java.net>
Cc: Andrew Luo <andrewluotechnologies at outlook.com>
Subject: Fwd: Enhancing jaotc to automatically find VS2017 linker

I've completely missed vswhere. It's years and years overdue, but it's nice that Microsoft is finally shipping something like this. :-)

We should support using vswhere as the primary way to detect a Visual Studio installation, if it is present, and the user do not override the default selection on the command line.

/Magnus


-------- Forwarded Message --------
Subject:

Enhancing jaotc to automatically find VS2017 linker

Date:

Fri, 18 Jan 2019 22:16:51 +0000

From:

Andrew Luo <andrewluotechnologies at outlook.com><mailto:andrewluotechnologies at outlook.com>

To:

hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net> <hotspot-compiler-dev at openjdk.java.net><mailto:hotspot-compiler-dev at openjdk.java.net>




Hi,

Has there been any plans to enhance jaotc to support automatically finding the link.exe in VS2017?  If not, I am interested in contributing some work to support this.

I see that in Linker.java (src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java) we find link.exe using the environment variables VS...COMNTOOLS, but since in VS2017 and forward, this is not defined, it seems another approach is necessary.  Microsoft suggests that you use vswhere (https://github.com/Microsoft/vswhere, BSD licensed, included with Visual Studio 2017 15.2 and forward) or their COM API to find the latest VS2017 toolset.

Anyways, if everyone agrees we should add VS2017 support, there are a few ways to do this (in order of simplest/easiest to most complex):


1.       Check that vswhere exists on the system, if it does, call vswhere (out of process - not sure this is acceptable...) and use that to find the VS2017 link.exe

2.       Ship vswhere with the JDK and call it out of process

3.       Statically link a copy of vswhere (BSD licensed - is this okay?) into our code and add a JNI stub to call it

4.       Call the COM API in a JNI function to get the latest version of VS2017

Personally I prefer (1), but if out-of-process isn't acceptable I'm fine with doing (4) or (3).

Let me know if you have any comments/feedback on this proposal.

Thanks,

-Andrew