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 <andrewluotechnolog...@outlook.com>
To: hotspot-compiler-...@openjdk.java.net
<hotspot-compiler-...@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
