RFR (M): Enable OpenJDK builds on Windows with MinGW/MSYS (original) (raw)

Volker Simonis volker.simonis at gmail.com
Fri Mar 9 17:58:13 UTC 2012

On Thu, Mar 8, 2012 at 8:58 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:

On Mar 8, 2012, at 9:39 AM, Volker Simonis wrote:

Hi,

please review the following changes which make it possible to use MinGW/MSYS as underlying build environment for Windows. Because the changes touch several repositories I prepared three webrevs, all relative to http://hg.openjdk.java.net/jdk8/build For the main repository: http://cr.openjdk.java.net/~simonis/MinGWMSYS.v1/ I had originally purged all mention of MKS from this README because we wanted to stop using it in favor of CYGWIN, and only maintain one way to build on Windows. That never happened internally, many kept using MKS because it was so much faster. So as much as I hate seeing the MKS instructions being added, I understand why you felt compelled to add them, and see no obvious inaccuracies We didn't  have any plans to continue to support MKS with the new build infrastructure work. It creates a complication that we wanted to avoid, but at the same time we are running into the "CYGWIN is too slow, especially on 64bit Windows" problem. So we will need to discuss this on the build-infra-dev alias. Since this change is just README, and I see nothing wrong with regards to your changes, it seems ok, with the caveat that if we end up really abandoning MKS, we may need to purge the MKS references.  I just don't know what will happen here right now.

For the HotSpot repository: http://cr.openjdk.java.net/~simonis/MinGWMSYShotspot.v1/ Seems fine. This change could probably proceed regardless of the others I think. But someone from the hotspot team may need to help here.... or maybe I could do it... Was the /option to -option a style issue, or was it required somehow? Just curious, I have no objection to making it consistent.

Yes, it is required because MinGW tries to be smart when calling non-MinGW executables and interprets slash-options as paths (e.g. "/I" may end up as "I:") See http://mingw.org/wiki/Posix_path_conversion for more information.

Also, the quotes on the paths..  any particular reason why?

This was very tricky to get right on all three environments and the quoted version basically just worked. The problem again is MinGWs automatic path conversion: if you give the top-level make something like ALT_BOOTDIR=C:/Java/jdk1.7.0_02 it implicitly converts it into ALT_BOOTDIR=/c/Java/jdk1.7.0_02 for the next recursive make call. Later, when nmake will be called, it converts it back into C:/Java/jdk1.7.0_02 which fools nmake. But if the path is quoted, all works well.

For the JDK repository http://cr.openjdk.java.net/~simonis/MinGWMSYSjdk.v1/ Seems fine but unfortunately, we have other closed repos that might be impacted here. The cpio change concerns me, not that I'm in love with cpio, I tried to get rid of it a long time ago, but it was so much faster than tar for some reason. So I'll need to make sure the entire Oracle JDK build process is ok with these changes before this could go in.

I didn't realized any performance problems and tar is already used in some places for copying files so I thought it will be ok. Hope your internal repos work fine with the change, otherwise please let me know.

Right now I'm not so concerned about using MinGW/MSYS as making sure the existing builds are not broken. But I am looking forward to using MinGW/MSYS soon.

I may need to enlist someone to do some image comparisons and double check that the end result has not changed too.

Absolutely. Please keep me informed if you encounter any problems.

Please be so kind and also create three bug ids for the corresponding changes. Created: 7152336: Enable builds on Windows with MinGW/MSYS I think we can use the same CR for all repos. Unless you really want 3 CRs.

That's your playground:) I'm happy either way.

The changes are minimal in the sense that I did "just enough" changes to be able to build on Windows with either one of the three Unix emulation environments (MKS, Cygwin, MinGW/MSYS). The main benefits of the new MinGW/MSYS based Windows build are: - no problems with make - one can simply use the make tool which comes with MinGW/MSYS - with the current MinGW/MSYS version the build is known to succeed, while the newest Cygwin 1.7.10 version is known to break the OpenJDK build (see: http://old.nabble.com/Is-anyone-able-to-build-on-Win-7-td33196055.html) - speed - the MinGW/MSYS build times are comparable to the MKS build times and is at least 50% faster than the Cygwin build times (see numbers below) That 50% faster is great news.

The changes are intentionally against the old, "traditional" build system to fix the mentioned Cygwin problems and simplify the Windows build just now. I don't expect any problems in adapting the "new" build infrastructure to MinGW/MSYS as well in a follow-up step. More information on each change can be found in the corresponding webrevs. Timing results for the different build environments (MKS ver. 9.4, Cygwin ver. 1.7.9, MinGW/MSYS 1.0.17) for a full JDK 8 product build on a freshly booted, dual core i7 notebook with 8GB RAM, HDD and 64-bit Windows 7:

MKS -- Build times ---------- Target allproductbuild Start 2012-02-29 19:19:26 End   2012-02-29 20:07:44 00:03:10 corba 00:03:44 hotspot 00:00:30 jaxp 00:00:37 jaxws 00:39:39 jdk 00:00:36 langtools 00:48:18 TOTAL ------------------------- MinGW/MSYS -- Build times ---------- Target allproductbuild Start 2012-02-29 18:16:31 End   2012-02-29 19:10:59 00:02:57 corba 00:03:04 hotspot 00:00:32 jaxp 00:00:40 jaxws 00:46:36 jdk 00:00:36 langtools 00:54:28 TOTAL ------------------------- Cygwin -- Build times ---------- Target allproductbuild Start 2012-02-29 14:36:50 End   2012-02-29 16:05:50 00:05:47 corba 00:03:24 hotspot 00:00:33 jaxp 00:00:43 jaxws 01:17:45 jdk 00:00:39 langtools 01:29:00 TOTAL ------------------------- Excellent details.  Thanks. I'll definitely work with you to get these changes integrated. -kto Regards, Volker

More information about the build-dev mailing list