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






Reply via email to