Hi Tim, I'm still glad that you're pushing this forward:)
Just wanted to let you know two more things we found out about the MinGW build in the hope they may be useful for others as well: - you can considerably speed up the build (especially an incremental build which only rebuilds a few files) if you disable implicit make rules (i.e. use make's '-r' option). You can set "MAKE=make -r" to also use this option for recursive make invocations but perhaps it would be better to just define "MAKEFLAGS += -r" in the top-level makefiles. Without this option, make tries to look up a lot of non-existing RCS and SCCS files which especially hurts on Windows (see http://www.electric-cloud.com/blog/2009/08/19/makefile-performance-built-in-rules/ for a more detailed description). - internally we use a sh-script (build.sh) which sets some environment variables and then calls make to start the build. Under MKS it was possible to simply call such a sh-script from an arbitrary DOS-shell because MKS registered '.sh' as a known extension and just did the right thing. Under MinGW/MSYS we had to explicitly call 'bash.exe -i build.sh <shell-script-args>'. However this unfortunately didn't work reliable. Instead the top-level DOS-shell crashed (with the error "Command Windows Host has stopped working") during the build which results in thousands of DOS-boxes popping up for every executed system command. This problem can be solved by just piping the desired command to the shell like so: "build.sh <shell-script-args> | bash.exe -i" Regards, Volker On Wed, Jun 27, 2012 at 6:45 PM, Tim Bell <[email protected]> wrote: > I went over the open changes again and removed some debug code left in > by mistake, updated copyright dates and fixed a few typos. Here is an > updated webrev: > > http://cr.openjdk.java.net/~tbell/7152336/webrev.01/ > > These changes are building in both 32 and 64 bit mode on my Windows 7 > system. > > jtreg test runs of the '-automatic -noshell' tests under test/java/lang > test/java/math test/java/util ran as expected (2 failures, both known bugs). > > Thanks in advance for your review and feedback - I'd like to get these > changes in soon. > > Tim Bell > > > On 06/13/12 22:31, Tim Bell wrote: >> >> Hello everyone- >> >> Kelly asked me to pick up on bug #/7152336 "//Enable builds on Windows >> with MinGW/MSYS"/, and this email thread: >> >> >> http://mail.openjdk.java.net/pipermail/build-dev/2012-April/thread.html#6083 >> >> As David pointed out, we will need at least one other bug # for the >> hotspot changes. That said, this is enough to get me started. >> >> Hi Volker: >> >> I have applied the patches originally from your posting. Many thanks for >> that: >> http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/ >> >> With a few modifications (keep cpio for non MinGW/Msys builds, keep MKS as >> an option), the proposed changes are visible here for review: >> >> http://cr.openjdk.java.net/~tbell/7152336/webrev.00/ >> >> For reference, my test build log is visible here: >> >> >> http://cr.openjdk.java.net/~tbell/7152336/webrev.00/full_control_build_no_docs.log >> >> Additional test builds on JPRT (our internal build apparatus) verified >> that I didn't regress the existing build. >> >> Abbreviated jtreg [1] testing on this build was successful: >> >> $ /d/tools/jdk8/7152336/windows-i586/bin/java -jar >> /d/tools/jtreg-internal/jtreg/lib/jtreg.jar -automatic -noshell >> test/java/lang test/java/math test/java/util >> Directory "JTreport" not found: creating >> Directory "JTwork" not found: creating >> Directory "JTwork\scratch" not found: creating >> Test results: passed: 698; failed: 1; error: 5 >> Report written to D:\tools\jdk8\7152336\jdk\JTreport\html\report.html >> Results written to D:\tools\jdk8\7152336\jdk\JTwork >> Error: Some tests failed or other problems occurred. >> >> The failing test (java/lang/Math/WorstCaseTests.java) is due to a known >> regression: 7174532 >> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7174532> >> "jdk/test/java/lang/Math/WorstCaseTests.java failing on x86" >> >> The 5 error tests are all ignored until bug xxxxxxx (for some value of x) >> is resolved. >> >> Thanks in advance for your review and feedback - >> >> Tim Bell >> >> [1] http://openjdk.java.net/projects/code-tools/ >> >
