Looks good.
/Erik
On 2018-05-18 09:53, Kevin Walls wrote:
Great, thanks, rebuilt the webrev.
If we add many more there we might want to rethink or reword the
sanity warning, but I'd like to save that for another time. 8-)
Thanks
Kevin
On 18/05/2018 16:29, Erik Joelsson wrote:
Hello Kevin,
I have a machine with both 2015 and 2017 installed and checked the
link version numbers:
VS2015:
C:\Program Files (x86)\Microsoft Visual Studio 14.0>link /?
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
VS2017:
C:\Users\erik\source>link /?
Microsoft (R) Incremental Linker Version 14.12.25835.0
Copyright (C) Microsoft Corporation. All rights reserved.
So it looks like you need to add 1412 to checkLink in sanity.make.
/Erik
On 2018-05-18 01:51, Kevin Walls wrote:
Hi Erik -
Quite right, thanks. Actually I should include recognising VS2015
while I'm doing this.
Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/
Also, update Abstract_VM_Version::internal_vm_info_string() in
src/share/vm/runtime/vm_version.cpp so the long version string is
readable for these compilers.
In the sanity checks for VS2015, I am predicting it has a linker
version of 1900 as it's between the 1800 and 1900 that I have seen
myself for the other versions I have.
I have a local VS2013 build, and builds using the unchanged
"official" compiler are still OK.
Thanks
Kevin
On 17/05/2018 23:32, Erik Joelsson wrote:
Hello Kevin,
In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to
VS2015 and 1912 to VS2017. Is it really 1900 in nmake?
Otherwise I think this looks ok.
/Erik
On 2018-05-17 15:21, Kevin Walls wrote:
Hi,
I'd like to get a review for this 8u/hotspot build change for
Windows, to loosen the restriction on what compilers we can use.
JBS:
8203349: 8u hotspot should recognise later Windows compilers
https://bugs.openjdk.java.net/browse/JDK-8203349
Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/
Changes in the places we (sanity) check version numbers, set some
compile
options, and expand the check in vm.make to make sure we put the
precompiled
object _build_pch_file.obj on the jvm link command.
In compile.make I added blocks for VS2013 and 17, and left them as
separate,
duplicated, blocks of settings to make them easier to change
independently.
This doesn't change anything about what is "supported" or
documented as working.
Thanks!
Kevin