Re: building part of jdk 8
This worked for me today for building just awt: This is in my bat file. The first two sets are what resolved my issue. set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i Then at the cygwin command line: eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 21 | tee build.log Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. Pete On 2/2/12 2:19 PM, Pete Brunet wrote: On 2/1/12 10:54 PM, Pete Brunet wrote: On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do... // These are done in a bat file before I do any makes set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCH_DATA_MODEL=32 FASTDEBUG=true 21 | tee build.log The error I am getting is make: *** No rule to make target `../../../build/windows-i586/btjars/compileproperties.jar', needed by `compile_all_props'. Stop. When building below the top level, for some reason a partial build directory is being created in jdk8/jdk. When doing a full build from the top level the only build directory I see is the one in jdk8. It appears that ../../../build/... is using the build under jdk rather than the build under the top level. Tonight I saw a similar failure when trying to rebuild JLabel.java from jdk: make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing' make[2]: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. and when trying to build directly at .../jdk/make/javax/swing, i.e. make: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. The JLabel issue was caused by the existence of ...\jdk\src\share\classes\javax\swing\JLabel - Copy.java. (This is Windows' scheme for copies.). However, that wouldn't explain the use of a build directory under jdk (instead of under the top level), i.e. my original problem might have been caused by using the wrong build dir: make: *** No rule to make target `../../../build/windows-i586/btjars/compileproperties.jar', needed by `compile_all_props'. Stop. In case it's helpful jdk/build contains these directories: bin btbins btclasses btjars classes gensrc include lib Since the above has windows-i586 instead of windows-i586-debug it looks like I need to add another variable when invoking make. Pete
Re: building part of jdk 8
On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do... // These are done in a bat file before I do any makes set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCH_DATA_MODEL=32 FASTDEBUG=true 21 | tee build.log The error I am getting is make: *** No rule to make target `../../../build/windows-i586/btjars/compileproperties.jar', needed by `compile_all_props'. Stop. When building below the top level, for some reason a partial build directory is being created in jdk8/jdk. When doing a full build from the top level the only build directory I see is the one in jdk8. It appears that ../../../build/... is using the build under jdk rather than the build under the top level. Tonight I saw a similar failure when trying to rebuild JLabel.java from jdk: make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing' make[2]: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. and when trying to build directly at .../jdk/make/javax/swing, i.e. make: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. In case it's helpful jdk/build contains these directories: bin btbins btclasses btjars classes gensrc include lib Since the above has windows-i586 instead of windows-i586-debug it looks like I need to add another variable when invoking make. Pete
Re: Is anyone able to build on Win 7
2012-02-02 00:10, Kelly O'Hair skrev: I don't know what the current state is. The CYGWIN community seemed pretty adamant that they wanted to stamp out all drive letter pathnames. As I understood it, it's not so much the version of make.exe, but how the make.exe was built. Some kind of 'allow drive letter paths' option needs to be turned on when building. I created a neat solution to get around this drive letter problem in the new build-infra/jdk8 (jdk7) forest. The configure script compiles an executable called uncygdrive.exe The make variables that point to tools that do not understand /cygdrive paths, like CC:=cl.exe and JAVA:=java.exe are rewritten to: CC:=uncygdrive.exe cl.exe JAVA:=uncygdrive.exe java.exe As you can guess, the uncygdrive command parses the command line and rewrites any /cygdrive/c/ into just c:/ (likewise for any other drive letter). It even enters into @files and creates a temporary file with adjusted content. Then it execs the new adjusted command line. Works great and the Makefiles become much simpler since you can just use /cygdrive everywhere! A more important problem is the dreaded slowdown of cygwin on 64 bit windows. It is believed to be the fork simulation gone haywaire when dealing with 64 bit address space, but what do I know. //Fredrik
Re: Request for review: hotspot/jprt.properties [S]
Looks good. Paul On 2/2/12 6:56 PM, Keith McGuigan wrote: Hello, Here's a webrev for changing the default JPRT release value for hotspot to jdk8. It can still be overridden by the -release jdk7 during JPRT submission. I also removed references to pre-7 releases and other unused value (jdk7b107, jdk7temp). The targets and parameters for jdk7 jdk8 are identical for now, but it's probably good to keep the distinction in the file so we can update jdk8 targets independently as development continues. http://cr.openjdk.java.net/~kamg/7069991/webrev.00/ Thanks for any reviews. -- - Keith
Re: Adding asm to JDK 8
Lambda was the proximate driving force. EE was also a contributor; as I mentioned earlier, Glassfish includes half a dozen versions of ASM, some of different vintages, because of how it is componentized. We can probably get rid of the extra repo once we can make it into a module. On 2/3/2012 12:11 PM, Phil Race wrote: Oh, its for lambda! Thank you for mentioning that. I had no clue what we needed this thing for :-), may be it was obvious to the rest of the world but not to me and I was surprised it wasn't mentioned in Jim's email. But does it really need its own new repo ? I think there needs to be a discussion on this as I'd like to see *fewer* of them. How enormous is this thing ? Can't be that big if there's a copy buried in jax-ws -phil. On 2/3/2012 3:46 AM, Alan Bateman wrote: On 03/02/2012 04:04, Mandy Chung wrote: Great. That would give a good starting point. Mandy On 2/2/2012 7:34 PM, Brian Goetz wrote: The main ASM distribution is broken into 5 jars, based on how people tend to use it; this is probably a good starting candidate for module boundaries. Brian - I also think we'll need a brief overview on usage too. In particular, is the plan to run ASM at runtime and is this the plan for the long term too or will it be replaced by something in the core to generate the classes as runtime? (I'm been too busy to track many of the details of lambda). -Alan
Re: building part of jdk 8
Just a few comments below... On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote: This worked for me today for building just awt: This is in my bat file. The first two sets are what resolved my issue. set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image The above two settings make no sense to me. ALT_OUTPUTDIR is supposed to point at the directory where you want the build results to go. One of the directories created is the j2sdk-image. This is a huge disk write area. ALT_JDK_IMPORT_PATH is something you set when you are doing partial builds, e.g. not building hotspot. It needs to point at some place that is pretty golden and steady, for a place to get parts of the jdk image that you are not building. You have it set to the same place you are building. :^( That seems fishy to me. I would have done a full build, moved or copied j2sdk-image to some place safe, and had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from destruction during the build. set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 The official boot jdk for jdk8 is actually the first shipping jdk7, although 7u2 should work, our release engineering and automated build systems use jdk7 fcs. set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary for some reason? set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i This bash command will add /usr/bin to the PATH, and convert PATH to the CYGWIN world. Then at the cygwin command line: eval `bin/vsvars.sh -v10 -32` Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio compiler. cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 21 | tee build.log Yup. Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. I've never been sure about Wbem needing to be in the system path. Let me know what you find out. So this is Windows 7 right? Is it Windows 7 X64 or X86? (32 or 64 bit OS) Do you have any anti-virus software installed, and any special settings? Is this the latest CYGWIN? (what does uname -a say?) There have been reports of problems with Windows 7 building, possibly involving CYGWIN and McAfee colliding somehow. Just curious. -kto Pete On 2/2/12 2:19 PM, Pete Brunet wrote: On 2/1/12 10:54 PM, Pete Brunet wrote: On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do... // These are done in a bat file before I do any makes set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCH_DATA_MODEL=32 FASTDEBUG=true 21 | tee build.log The error I am getting is make: *** No rule to make target `../../../build/windows-i586/btjars/compileproperties.jar', needed by `compile_all_props'. Stop. When building below the top level, for some reason a partial build directory is being created in jdk8/jdk. When doing a full build from the top level the only build directory I see is the one in jdk8. It appears that ../../../build/... is using the build under jdk rather than the build under the top level. Tonight I saw a similar failure when trying to rebuild JLabel.java from jdk: make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing' make[2]: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. and when trying to build directly at .../jdk/make/javax/swing, i.e. make: *** No rule to make target `javax/swing/JLabel', needed by `../../../build/windows-i586/tmp/com/javax.swing/.classes.list'. Stop. The JLabel issue was caused by the existence of ...\jdk\src\share\classes\javax\swing\JLabel - Copy.java. (This is Windows' scheme for copies.). However, that wouldn't explain the use of a build directory under jdk (instead of under the top level), i.e. my original
Re: building part of jdk 8
On 2/13/12 1:35 PM, Kelly O'Hair wrote: Just a few comments below... On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote: This worked for me today for building just awt: This is in my bat file. The first two sets are what resolved my issue. set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image The above two settings make no sense to me. ALT_OUTPUTDIR is supposed to point at the directory where you want the build results to go. One of the directories created is the j2sdk-image. This is a huge disk write area. I think I needed this to make my partial build use the same directory as my fastdebug_build full build. ALT_JDK_IMPORT_PATH is something you set when you are doing partial builds, e.g. not building hotspot. It needs to point at some place that is pretty golden and steady, for a place to get parts of the jdk image that you are not building. You have it set to the same place you are building. :^( That seems fishy to me. I would have done a full build, moved or copied j2sdk-image to some place safe, and had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from destruction during the build. I only build parts of awt and swing so maybe I've been lucky. In any event I made that change. set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 The official boot jdk for jdk8 is actually the first shipping jdk7, although 7u2 should work, our release engineering and automated build systems use jdk7 fcs. set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary for some reason? set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i This bash command will add /usr/bin to the PATH, and convert PATH to the CYGWIN world. Do I need to change something? Then at the cygwin command line: eval `bin/vsvars.sh -v10 -32` Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio compiler. cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 21 | tee build.log Yup. Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. I've never been sure about Wbem needing to be in the system path. Let me know what you find out. Rebuilding after tweaking awt_Component.cpp worked fine without this. I'll report back at some other time after doing a full rebuild. So this is Windows 7 right? Is it Windows 7 X64 or X86? (32 or 64 bit OS) 64 bit Windows 7 Do you have any anti-virus software installed, and any special settings? I have Norton 360 and for a full build I disable auto-protect. I don't bother disabling that for a partial build. Is this the latest CYGWIN? (what does uname -a say?) 1.7.0 (I dropped back from using 1.7.9 and so far this has been working, but I haven't done enough full builds yet to be sure.) Pete There have been reports of problems with Windows 7 building, possibly involving CYGWIN and McAfee colliding somehow. Just curious. -kto Pete On 2/2/12 2:19 PM, Pete Brunet wrote: On 2/1/12 10:54 PM, Pete Brunet wrote: On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do... // These are done in a bat file before I do any makes set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCH_DATA_MODEL=32 FASTDEBUG=true 21 | tee build.log The error I am getting is make: *** No rule to make target `../../../build/windows-i586/btjars/compileproperties.jar', needed by `compile_all_props'. Stop. When building below the top level, for some reason a partial build directory is being created in jdk8/jdk. When doing a full build from the top level the only build directory I see is the one in jdk8. It appears that ../../../build/... is using the build under jdk rather than the build under the top level. Tonight I saw a similar failure when trying to rebuild JLabel.java from jdk: make[2]:
Re: building part of jdk 8
On Feb 13, 2012, at 12:12 PM, Pete Brunet wrote: On 2/13/12 1:35 PM, Kelly O'Hair wrote: Just a few comments below... On Feb 13, 2012, at 9:08 AM, Pete Brunet wrote: This worked for me today for building just awt: This is in my bat file. The first two sets are what resolved my issue. set ALT_OUTPUTDIR=c:/OpenJDK/jdk8/build/windows-i586-fastdebug set ALT_JDK_IMPORT_PATH=c:/OpenJDK/jdk8/build/windows-i586-fastdebug/j2sdk-image The above two settings make no sense to me. ALT_OUTPUTDIR is supposed to point at the directory where you want the build results to go. One of the directories created is the j2sdk-image. This is a huge disk write area. I think I needed this to make my partial build use the same directory as my fastdebug_build full build. Understood. That's a perfectly valid reason. ALT_JDK_IMPORT_PATH is something you set when you are doing partial builds, e.g. not building hotspot. It needs to point at some place that is pretty golden and steady, for a place to get parts of the jdk image that you are not building. You have it set to the same place you are building. :^( That seems fishy to me. I would have done a full build, moved or copied j2sdk-image to some place safe, and had ALT_JDK_IMPORT_PATH refer to that copy, where it would be safe from destruction during the build. I only build parts of awt and swing so maybe I've been lucky. In any event I made that change. set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 The official boot jdk for jdk8 is actually the first shipping jdk7, although 7u2 should work, our release engineering and automated build systems use jdk7 fcs. set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin Not sure why ALT_MSDEVTOOLS_PATH is needed. Did you find this necessary for some reason? set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i This bash command will add /usr/bin to the PATH, and convert PATH to the CYGWIN world. Do I need to change something? No you are perfectly fine. I was just commenting that the PATH setting has changed. I always keep track of when PATH changes. Then at the cygwin command line: eval `bin/vsvars.sh -v10 -32` Perfect. That adjusts PATH, LIB, INCLUDE, etc, all for the Visual Studio compiler. cd /cygdrive/c/OpenJDK/jdk8/jdk/make/sun/awt/ make ARCH_DATA_MODEL=32 21 | tee build.log Yup. Note: I suspect I don't need wbem in my path; I'll remove it the next time I do a build. I've never been sure about Wbem needing to be in the system path. Let me know what you find out. Rebuilding after tweaking awt_Component.cpp worked fine without this. I'll report back at some other time after doing a full rebuild. http://www.pcreview.co.uk/forums/do-need-wbem-path-statement-t2330116.html My tendency is to leave Wbem in PATH. Not sure we need it, but why vary the standard Windows PATH and ask for trouble? ;^) -kto So this is Windows 7 right? Is it Windows 7 X64 or X86? (32 or 64 bit OS) 64 bit Windows 7 Do you have any anti-virus software installed, and any special settings? I have Norton 360 and for a full build I disable auto-protect. I don't bother disabling that for a partial build. Is this the latest CYGWIN? (what does uname -a say?) 1.7.0 (I dropped back from using 1.7.9 and so far this has been working, but I haven't done enough full builds yet to be sure.) Pete There have been reports of problems with Windows 7 building, possibly involving CYGWIN and McAfee colliding somehow. Just curious. -kto Pete On 2/2/12 2:19 PM, Pete Brunet wrote: On 2/1/12 10:54 PM, Pete Brunet wrote: On 1/23/12 9:39 AM, Pete Brunet wrote: In the past I was able to build part of jdk 8 but that is not currently working although I am able to do a full 32 bit build. I've recently moved from XP to W7 so my environment might not be set up quite right yet. Here's what I do... // These are done in a bat file before I do any makes set ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_02 set ALT_FREETYPE_HEADERS_PATH=C:/Users/Pete/freetype-2.4.8/include set ALT_FREETYPE_LIB_PATH=C:/Users/Pete/freetype-2.4.8/objs/win32/vc2010 set ANT_HOME=C:/Progra~2/apache-ant-1.7.1 set ALT_MSDEVTOOLS_PATH=C:/Progra~2/MICROS~1/Windows/v7.0A/bin set CLASSPATH= set PATH=C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem; set CYGWIN=nodosfilewarning cd c:\Users\Pete\cygwin\bin bash --login -i // These are done at the command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8/jdk/make/java/awt/ make ARCH_DATA_MODEL=32 FASTDEBUG=true 21 | tee build.log The error I am getting is make: *** No rule to make target
