Enhancing jaotc to automatically find VS2017 linker

[Andrew Luo]

Just wanted to check in again on this in case my email got missed over the long weekend (in the US).  Let me know if I've sent this to the wrong mailing list...

Anyways, after looking into it more myself though, it seems like out-of-process isn't that unusual given that we execute link.exe out of process anyways.

Thanks,

-Andrew

From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo
Sent: Friday, January 18, 2019 2:17 PM
To: hotspot-compiler-dev at openjdk.java.net
Subject: Enhancing jaotc to automatically find VS2017 linker

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190124/fbc15379/attachment-0001.html>