On Thu, Mar 8, 2012 at 8:58 PM, Kelly O'Hair <kelly.oh...@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/MinGW_MSYS.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/MinGW_MSYS_hotspot.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/MinGW_MSYS_jdk.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: </p> >> >> MKS >> -- Build times ---------- >> Target all_product_build >> 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 all_product_build >> 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 all_product_build >> 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 >
