This is kind of an update on the bug that started out as:
6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building) But that bug has been closed as a fix to just the corba repository Makefiles. So if and when these changes are pushed in, the bugid will be different, or it may appear as multiple bugids and changesets. This webrev: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-cygwin-6875240/webrev/ Is my current state for the jdk repository Makefiles. The fork/exec reduction is pretty significant, over 50% reduction as measured on Solaris builds, but the goal of significantly improving the overall Windows CYGWIN build time is less fruitful, maybe a 10-15% reduction in build time. This is not at all the same results as I saw with the corba repository makefile changes. I was going to post some build time data, but it's hard to be accurate, with Windows in particular. The environment variables are effectively being used as a sort of cache of information with these changes. Plus the number of 'find' commands has been limited. The above webrev includes a few diversions to the primary change: * All source files that were template java files, used to generate java source files were renamed *.java-template. This file suffix change simplifies much of the Makefile logic and could probably be done as a separate changeset. * Use of the make syntax $(eval) required an upgrade to make 3.81, and this upgrade brought out a problem with make 3.81 and MKS shells regarding escaped quotes on compile lines. So you will see changes from things like -DX="\"Y\"" to -DX='"Y"', to avoid the problem, but that makes it the same for all platforms, a good thing. The old make 3.78.1 (or < 3.81) and MKS shells seem happy with either way. These changes could probably be done with a separate changeset too. * Use of AUTO_JAVA_PRUNE had to become more specific because of the use of the make $(filter*) functions rather than SED and GREPs. This makes the act of pruning more explicit. I'm not sure where to go from here, it's obvious that the low hanging fruit that I thought would help here is not helping that much. At this point, internally, at least for Windows X64, we will probably continue to use MKS, perhaps just build with CYGWIN on 32bit Windows? Advice, ideas, or suggestions are welcome. -kto
