[8u] 8203349: 8u hotspot should recognise later Windows compilers

[Kevin Walls]

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
>>
>>
>