Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition

Wed Dec 16 20:18:34 UTC 2015

On 2015-12-16 16:33, Kumar Srinivasan wrote:
> Hello,
>
> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 
>
>
> You are undefining Windows math.h OVERFLOW, what is it defined
> as ? With you redefining this, will it cause problems for users of
> this API, likely to affect JNI apps.
>
> Probably need to redefine the pack200 OVERFLOW constant to
> something else, probably PACK200_OVERFLOW to prevent namespace
> collisions.

I agree, this is a better solution. I've updated the webrev with this 
solution (although I used the name PSIZE_OVERFLOW to align with PSIZE_MAX).

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02

/Magnus

>
> Kumar
>
> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>> Hi,
>>>   I have signed the OCA and emailed a scan according the 
>>> instructions. I separated the freetype changes into a separate batch 
>>> as suggested. I have shared the patch files on OneDrive, they are my 
>>> Public folder. Here’s the link to the folder: 
>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>   The OneDrive folder should contain these 4 files:
>>>   freetype_JDK9.patch
>>> vs2015_JDK9.patch
>>> vs2015_JDK9_hotspot.patch
>>> vs2015_JDK9_jdk.patch
>>>   The first two target the root repository, the other two are for 
>>> hotspot and jdk repositories, respectively.
>>>   I rebased the patches on JDK9 tip today. I           ran “make 
>>> images” and fixed a couple of new errors that have appeared since 
>>> the previous version. A couple of the changes I had made were also 
>>> not needed any more.
>>>   Please have a look!
>> Hi Timo,
>>
>> I'm sorry for the long delay.
>>
>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this 
>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>
>> The vs2015 changes are more complicated since they touch multiple 
>> places in the code. Also, your patch had started bitrotting slightly 
>> during my long response time. I'm trying to fix it up, and will post 
>> a review when I have sorted everything out. I will verify that the 
>> change does not break any of our supported platforms, but I'd like 
>> you to verify that the patch still works on VS2015. When I publish 
>> the webrev, there will be a download link to the patch file.
>>
>> Also, this patch touches both hotspot code and multiple jdk modules, 
>> so it will need to be reviewed by other groups as well, besides the 
>> build team.
>>
>> /Magnus
>>
>>>             Sent from Mail for Windows 10
>>>
>>> From: Magnus Ihse Bursie
>>> Sent: Friday, October 23, 2015 17:13
>>> To: timo.kinnunen at gmail.com;build-dev
>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 
>>> Communityedition
>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>> Hi,
>>>>
>>>> I’ve been going over the Windows build of the whole JDK for a while 
>>>> with VS 2015 and now I have patches that allow the build to complete.
>>>>
>>>> I’ve made changes in the root repository as well as in hotspot and 
>>>> jdk repositories. The changes fall broadly in three categories: 
>>>> enabling the v140 toolchain and improving freetype compilation, 
>>>> adding casts to where pointers are truncated and miscellaneous 
>>>> small-scale code changes.
>>>>
>>>> The patch to the root repository streamlines handling of freetype 
>>>> by implementing a default source directory at $HOME/freetype under 
>>>> Cygwin. It is checked during configure and used for compiling if 
>>>> “--with-freetype-src” is not specified. A help message giving the 
>>>> unpacking command with the correct directory is also included. This 
>>>> patch is about 90 lines without counting generated-configure.sh 
>>>> changes.
>>>>
>>>> The patches to jdk and hotspot contain native code changes only and 
>>>> no changes to make-files. These are about 580 and 290 lines, 
>>>> respectively. All patches are generated with “hg diff -g”.
>>>>
>>>> Would you be willing to incorporate these? How should I proceed 
>>>> with this?
>>>   Hi Timo,
>>>   First of all, I apologize that you have not recieved any response for
>>> far too long. :-(
>>>   Thank you for your interest in helping to improve OpenJDK!
>>>   In general, a patch to allow compilation on           VS 2015 
>>> Community edition
>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>> patch and help you work with getting it accepted.
>>>   My first question to you is: have you signed the OCA? Also, unless
>>> you've done so already, reading http://openjdk.java.net/contribute/ 
>>> is a
>>> good start for starting to contribute to OpenJDK.
>>>   However, supporting a new compiler, without at the same time 
>>> breaking an
>>> older one, can sometimes be tricky business. This means that you might
>>> need to iterate your patch a number of times, until it's suitable for
>>> inclusion. I don't want to scare you away, just be realistic up front
>>> that it might require some more work from your part (and our!). Also,
>>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>>> SP4, so I know what I'm talking about...)
>>>    From what you write, I think you should try           to separate 
>>> the
>>> freetype-src default directory from the compiler upgrade settings. The
>>> former might be easier to start with, as it's less likely to be
>>> disruptive for anything else.
>>>   Also, at this point, I think it would be helpful for me to be able to
>>> have an initial look at the patches. You need to be an OpenJDK 
>>> Author to
>>> be able to access the OpenJDK infrastructure, so unfortunately that is
>>> not available to you. :-( For a first peek, the patches can be provided
>>> just about any way (but attachments to this list is unfortunately not
>>> allowed). For a final, proper, code review they need to reside on our
>>> infrastructure, but at that point I can help with fixing that.
>>>   /Magnus
>