Re: Review for 7141242: build-infra merge: Rename CPP-CXX and LINK-LD
Hello, I've intentionally left out all VS project files. I'm not sure but I suspect that CPP is some kind of standard name for the compiler in that context. I'm happy to hear I didn't mess up the project creation! /Erik On 2012-02-02 09:01, Staffan Larsen wrote: Those generated files are Visual Studio projects for VS version 6 (I think). Really old stuff. I don't think these are used (nor is VS 6 supported), so we should eventually clean out that code. I wouldn't bother fixing it. /Staffan On 2 feb 2012, at 08:51, Bengt Rutisson wrote: Hi Erik, I have not looked closely at your changes, so don't consider this a review. What I did do was apply your patch and try to create a Visual Studio project with the create.bat script. That still works. Nice! One thing I noticed is that the ProjectCreator tool generates some files for the ADLC builds. These files still use the CPP name. Since it still works to create a project I don't know if this needs to be changed. But maybe it is good to be consistent. Here's where we use the CPP name: src\share\tools\ProjectCreator/WinGammaPlatformVC6.java: 68:printWriter.println(CPP=cl.exe); 145:printWriter.println(# SUBTRACT CPP /YX /Yc /Yu); 149:printWriter.println(# ADD CPP /Yc\incls/_precompiled.incl\); 210:rv.add(ADD CPP /nologo /MT /W3 /WX /GX /YX /Fr /FD /c); 217:rv.add(ADD BASE CPP +Util.prefixed_join( /I , includes, true)); 218:rv.add(ADD CPP +Util.prefixed_join( /I , includes, true)); 219:rv.add(ADD BASE CPP +Util.prefixed_join( /D , defines, true)); 220:rv.add(ADD CPP +Util.prefixed_join( /D , defines, true)); 221:rv.add(ADD CPP /Yu\incls/_precompiled.incl\); 230:rv.add(ADD BASE CPP /MD); 231:rv.add(ADD CPP /MD); 252:rv.add(ADD BASE CPP /Gm /Zi /O+opt); 272:rv.add(ADD CPP /O+getOptFlag()); And these are the generated files: build\vs-amd64/compiler2/generated/ADLCompiler.dsp build\vs-amd64/tiered/generated/ADLCompiler.dsp Bengt On 2012-02-02 03:33, David Holmes wrote: Hi Erik, On 1/02/2012 7:13 PM, Erik Joelsson wrote: http://cr.openjdk.java.net/~erikj/7141242/webrev.00/ 240 lines changed: 0 ins; 19 del; 221 mod; 6363 unchg 7141242: build-infra merge: Rename CPP-CXX and LINK-LD Lots of CCC to CXX too :) One compatibility concern: anyone currently setting CPP_FLAGS or LINK_FLAGS etc, externally, will need to change to the new names. Probably worth sending a wider email (jdk8-dev?) when this gets pushed. --- make/bsd/makefiles/gcc.make - CPP = $(CXX) + CXX = $(CXX) infinite recursion or a tautology? :) --- make/*/makefiles/launcher.make Not your doing but this has highlighted some strange rules eg: + $(QUIETLY) $(CC) -g -o $@ -c $ -MMD $(LAUNCHERFLAGS) $(CXXFLAGS) C++ flags passed to C compiler? --- make/*/makefiles/rules.make -# $(CC) is the c compiler (cc/gcc), $(CCC) is the c++ compiler (CC/g++). -C_COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) -CC_COMPILE = $(CCC) $(CPPFLAGS) $(CFLAGS) +# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++). +C_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) +CC_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) The original code is confusing, given that CC is the C compiler it makes no sense that a C++ compile be called CC_COMPILE. Is it worth changing these to CC_COMPILE and CXX_COMPILE? Maybe a secondary cleanup? And again C++ flags passed to C compiler :( --- You missed a couple of scripts on Windows that use LINK_VER: windows/get_msc_ver.sh windows/build_vm_def.sh Cheers, David - The build-infra project is starting to move into jdk8. For the hotspot build to stay compatible with the changes, the naming of standard make variables, like CC and LD need to be standardized across the build. Currently hotspot names the C++ compiler CPP, which is traditionally the name of the preprocessor. The windows nmake files name the linker LINK. We would like to rename the C++ compiler to CXX and have the linker named LD everywhere. Patch is tested with hsx/hotspot-rt. Testing with jdk7u is in progress. /Erik
Re: Review for 7141242: build-infra merge: Rename CPP-CXX and LINK-LD
Hello David, Thanks for taking a look! New webrev here: http://cr.openjdk.java.net/~erikj/7141242/webrev.01/ JPRT job running. In this version a lot more has changes, see comments inline. On 2012-02-02 03:33, David Holmes wrote: Hi Erik, Lots of CCC to CXX too :) Right, it looked to me like CCC was used in rules.make by someone who didn't like using CPP for the C++ compiler. I couldn't see any need for an intermediate variable there, just extra confusion. One compatibility concern: anyone currently setting CPP_FLAGS or LINK_FLAGS etc, externally, will need to change to the new names. Probably worth sending a wider email (jdk8-dev?) when this gets pushed. Good point. We will need to send it out both to jdk8 and jdk7 consumers as this will (unfortunately) also hit 7u4. make/bsd/makefiles/gcc.make - CPP = $(CXX) + CXX = $(CXX) Thanks for spotting that. Fixed in new webrev. I think I've created variations on this patch too many times now. C++ flags passed to C compiler? That looks weird yes. I don't dare changing it in the scope of this work though. make/*/makefiles/rules.make -# $(CC) is the c compiler (cc/gcc), $(CCC) is the c++ compiler (CC/g++). -C_COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) -CC_COMPILE = $(CCC) $(CPPFLAGS) $(CFLAGS) +# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++). +C_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) +CC_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) The original code is confusing, given that CC is the C compiler it makes no sense that a C++ compile be called CC_COMPILE. Is it worth changing these to CC_COMPILE and CXX_COMPILE? Maybe a secondary cleanup? Either a secondary cleanup or all at once. The new webrev deals with these and the related COMPILE.CC. These changes aren't needed for build-infra but they sure make the code clearer. Basically: CC_COMPILE - CXX_COMPILE C_COMPILE - CC_COMPILE *.CC - *.CXX *.c - *.CC Removed *.cpp as they weren't used (* is COMPILE, GENASM, LINK, LINK_LIB and PREPROCESS) Question is, how far do we want to go? With these changes, we have consistent naming of CC and CXX in all cases that I have found. You missed a couple of scripts on Windows that use LINK_VER: windows/get_msc_ver.sh windows/build_vm_def.sh I skipped the scripts as it didn't seem needed for my purposes, but included them in the new webrev. /Erik
unable to build JLabel
After editing JLabel.java, deleting my build directory, and starting a full build I am getting make[5]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing' snip - six sets of mkdir, rm, cp make[5]: *** No rule to make target `javax/swing/JLabel', needed by `C:/OpenJDK/jdk8/build/windows-i586/../windows-i586-fastdebug/tmp/com/javax.swing/.classes.list'. Stop. My build process was: // 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 cygwin command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8 make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true NO_DOCS=true fastdebug_build 21 | tee build.log
Re: jsr instructions in OpenJDK 6 classes
Hi Andrew, Whether or not the jsr instruction is used is -target specific; version 50.0 class files from -target 6 and later do not support jsr/ret since stackmaps are used. I haven't delved into the OpenJDK 6 build before writing this email, but I suspect some of the classes in rt.jar are compiled with -target 5, but javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr instructions from a stock compile. Sufficiently recent versions of javap will emit the classfile version under the -verbose flag. HTH, -Joe [1] Source, target, class file version decoder ring, http://blogs.oracle.com/darcy/entry/source_target_class_file_version On 02/02/2012 04:46 AM, Andrew Haley wrote: I'm sorry for the cross-post, but I don't know exactly who to address this to. Just to save you time reading all this: the javac in OpenJDK 6 generates jsr instructions, but only if you compile a great many source files in one go. This affects rt.jar. I'm trying to find out why. If you build OpenJDK6 and do this: happy:jdk6 $ javap -c -bootclasspath build/linux-amd64/classes/ -classpath build/linux-amd64/classes/ java.util.concurrent/PriorityBlockingQueue | grep jsr 48: jsr 62 56: jsr 62 17: jsr 28 23: jsr 28 74: jsr 87 ... you'll see lots of jsr instructions. Why is this? It seems that if you compile the .java file this doesn't happen: happy:jdk6 $ ./build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:./build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -jar ./build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath /local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes -d /tmp /local/openjdk/jdk6/jdk/src/share/classes/java/util/concurrent/PriorityBlockingQueue.java happy:jdk6 $ javap -c -bootclasspath /tmp -classpath /tmp java.util.concurrent/PriorityBlockingQueue | grep jsr No jsr instructions this time. So, I try the compile again, but with the full list of classes in .classes.list: $ $ /local/openjdk/jdk6/build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -jar /local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath /local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes -d /tmp @/local/openjdk/jdk6/build/linux-amd64/tmp/java/java.lang/java/.classes.list $ javap -c -bootclasspath /tmp -classpath /tmp java.util.concurrent/PriorityBlockingQueue | grep jsr | head -5 48: jsr 62 56: jsr 62 17: jsr 28 23: jsr 28 74: jsr 87 Lots of jsrs. Now the really weird bit: if I edit classes.list to contain only a small subset of the files and run the command again, $ grep java.util.concurrent /local/openjdk/jdk6/build/linux-amd64/tmp/java/java.lang/java/.classes.list classes.concurrent $ /local/openjdk/jdk6/build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -jar /local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath /local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes -d /tmp @classes.concurrent $ javap -c -bootclasspath /tmp -classpath /tmp java.util.concurrent/PriorityBlockingQueue | grep jsr | head -5 ... no jsr instructions. I realize that OpenJDK 6 is nearing EOL, but this behaviour is so bizarre that I'd appreciate some input! Thanks, Andrew.
Re: jsr instructions in OpenJDK 6 classes
On 02/02/2012 04:52 PM, Joe Darcy wrote: stackmaps are used. I haven't delved into the OpenJDK 6 build before writing this email, but I suspect some of the classes in rt.jar are compiled with -target 5, but javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr instructions from a stock compile. Well, I'm using the same compile command so that doesn't quite explain it, but never mind. Why are some of the classes in rt.jar are compiled with -target 5 ? Would it hurt simply to remove that? Andrew.
Re: jsr instructions in OpenJDK 6 classes
On 02/02/2012 08:59 AM, Andrew Haley wrote: On 02/02/2012 04:52 PM, Joe Darcy wrote: stackmaps are used. I haven't delved into the OpenJDK 6 build before writing this email, but I suspect some of the classes in rt.jar are compiled with -target 5, but javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr instructions from a stock compile. Well, I'm using the same compile command so that doesn't quite explain it, but never mind. Why are some of the classes in rt.jar are compiled with -target 5 ? Would it hurt simply to remove that? Andrew. I haven't had to poke around this part of the system for a while, but some classes were compiled as part of bootstrapping under the previous platform version language level. I don't recall offhand the earliest system OpenJDK 6 supports using as a bootstrap. I don't think compiling the classes in rt.jar with -target 5 or -target 6 should make much difference, but probably wouldn't offer much benefit either. (The classes in rt.jar aren't verified anyway so the faster verifier doesn't help.) -Joe
Fwd: unable to build JLabel
The problem was caused by the existence of ...\jdk\src\share\classes\javax\swing\JLabel - Copy.java. (This is Windows' scheme for copies.) Original Message Subject:unable to build JLabel Date: Thu, 02 Feb 2012 10:27:58 -0600 From: Pete Brunet peter.bru...@oracle.com Reply-To: peter.bru...@oracle.com To: build-dev build-dev@openjdk.java.net After editing JLabel.java, deleting my build directory, and starting a full build I am getting make[5]: Entering directory `/cygdrive/c/OpenJDK/jdk8/jdk/make/javax/swing' snip - six sets of mkdir, rm, cp make[5]: *** No rule to make target `javax/swing/JLabel', needed by `C:/OpenJDK/jdk8/build/windows-i586/../windows-i586-fastdebug/tmp/com/javax.swing/.classes.list'. Stop. My build process was: // 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 cygwin command line eval `bin/vsvars.sh -v10 -32` cd /cygdrive/c/OpenJDK/jdk8 make ARCH_DATA_MODEL=32 ALLOW_DOWNLOADS=true NO_DOCS=true fastdebug_build 21 | tee build.log
Re: building part of jdk 8
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: Is anyone able to build on Win 7
On Feb 2, 2012, at 5:22 AM, Fredrik Öhrström wrote: 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! Excellent. This assumes that the CYGWIN user has not used mount points, e.g. mount C:/foobar to /foobar but we can deal with that when the time comes. I like your solution. 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. Yeah. It's bad enough that it could be slower because it is a VM, could be slowed down by AV On-Access scanning, or is just a slow Windows file system. So many things can slow a Windows system down. :^( And my long term plan was to do both 32bit and 64bit builds on Windows 64bit so we need fewer systems, and we use 64bit OS's that can have more CPU and RAM for scaling up the build. :^( If we had a really good Windows System Performance expert somewhere out there, I bet he/she could find some ways for us to make this Windows X64 CYGWIN situation faster. I'm not that person, and I've run out of ideas. :^( In the meantime I'm still using MKS. :^( -kto //Fredrik
Re: jsr instructions in OpenJDK 6 classes
On Feb 2, 2012, at 8:59 AM, Andrew Haley wrote: On 02/02/2012 04:52 PM, Joe Darcy wrote: stackmaps are used. I haven't delved into the OpenJDK 6 build before writing this email, but I suspect some of the classes in rt.jar are compiled with -target 5, but javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr instructions from a stock compile. Well, I'm using the same compile command so that doesn't quite explain it, but never mind. Why are some of the classes in rt.jar are compiled with -target 5 ? Would it hurt simply to remove that? Andrew. Not sure about OpenJDK6. But I thought ALL the classes in JDK6 were compiled with -target 5. As I recall the big issue was the StackMapTable attributes in -target 6 classes. Many of the classfile reader/writers had issues having to re-create the StackMaptable attribute and I vaguely recall some performance issues, and maybe some rt.jar size issues, and maybe some pack200 issues, etc. etc. It was, how do you say it. a 'can o worms' ???:^( -kto
Request for review: hotspot/jprt.properties [S]
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: Review for 7141242: build-infra merge: Rename CPP-CXX and LINK-LD
Hi Erik, I think this has gone as far as it needs for now. My visual inspection of these changes looks okay. My lingering concern is the impact on external scripts etc that may set some of the renamed flags. Even I have a build script that sets things so that I don't get complaints about using the wrong compiler version on Solaris. David On 2/02/2012 7:59 PM, Erik Joelsson wrote: Hello David, Thanks for taking a look! New webrev here: http://cr.openjdk.java.net/~erikj/7141242/webrev.01/ JPRT job running. In this version a lot more has changes, see comments inline. On 2012-02-02 03:33, David Holmes wrote: Hi Erik, Lots of CCC to CXX too :) Right, it looked to me like CCC was used in rules.make by someone who didn't like using CPP for the C++ compiler. I couldn't see any need for an intermediate variable there, just extra confusion. One compatibility concern: anyone currently setting CPP_FLAGS or LINK_FLAGS etc, externally, will need to change to the new names. Probably worth sending a wider email (jdk8-dev?) when this gets pushed. Good point. We will need to send it out both to jdk8 and jdk7 consumers as this will (unfortunately) also hit 7u4. make/bsd/makefiles/gcc.make - CPP = $(CXX) + CXX = $(CXX) Thanks for spotting that. Fixed in new webrev. I think I've created variations on this patch too many times now. C++ flags passed to C compiler? That looks weird yes. I don't dare changing it in the scope of this work though. make/*/makefiles/rules.make -# $(CC) is the c compiler (cc/gcc), $(CCC) is the c++ compiler (CC/g++). -C_COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) -CC_COMPILE = $(CCC) $(CPPFLAGS) $(CFLAGS) +# $(CC) is the c compiler (cc/gcc), $(CXX) is the c++ compiler (CC/g++). +C_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) +CC_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) The original code is confusing, given that CC is the C compiler it makes no sense that a C++ compile be called CC_COMPILE. Is it worth changing these to CC_COMPILE and CXX_COMPILE? Maybe a secondary cleanup? Either a secondary cleanup or all at once. The new webrev deals with these and the related COMPILE.CC. These changes aren't needed for build-infra but they sure make the code clearer. Basically: CC_COMPILE - CXX_COMPILE C_COMPILE - CC_COMPILE *.CC - *.CXX *.c - *.CC Removed *.cpp as they weren't used (* is COMPILE, GENASM, LINK, LINK_LIB and PREPROCESS) Question is, how far do we want to go? With these changes, we have consistent naming of CC and CXX in all cases that I have found. You missed a couple of scripts on Windows that use LINK_VER: windows/get_msc_ver.sh windows/build_vm_def.sh I skipped the scripts as it didn't seem needed for my purposes, but included them in the new webrev. /Erik
Re: Request for review: hotspot/jprt.properties [S]
Hi Keith, On 3/02/2012 9:56 AM, Keith McGuigan wrote: 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). Are we sure there is no reason to leave any pre-7 release info here? Otherwise changes seem okay. David 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
Hi Jim, I added build-dev to the cc as this is of general interest. Actually before doing this a heads-up should go out to all jdk8-dev I think. One question: are there any cross-compilation issues with building this? I'm assuming not but want to check. Okay two questions :) : do you know when this will get modularized and show up in the jigsaw repositories? Thanks, David On 3/02/2012 9:29 AM, Jim Holmlund wrote: This is just a heads up that we are in the process of adding http://asm.ow2.org/ to jdk 8 as a new top level repo. This new repo contains the asm source code, with a few mods that are needed to build/run it in our environment. The new repo also contains the build files needed to participate in our forest builds. The main building is done by the asm build.xml, with a Makefile wrapper around that in order to participate in the forest build. This Makefile dynamically renames the asm packages by prepending 'org.openjdk'. The forest build handles the asm repo in the same was as the other repos, eg, corba. The asm repo is built just after langtools, and then the resulting .class files are known in the jdk build and are put into rt.jar. The changes for this are: - These files are modified/added: M Makefile M make/Defs-internal.gmk M make/README.pre-components A make/asm-rules.gmk M make/jdk-rules.gmk M make/sanity-rules.gmk M make/scripts/hgforest.sh - the new asm repo is built just after langtools - these files in the jdk repo are modified/added: M THIRD_PARTY_README M make/Makefile M make/common/Release.gmk M make/common/internal/ImportComponents.gmk M make/common/shared/Defs-control.gmk M make/common/shared/Defs.gmk M make/common/shared/Sanity-Settings.gmk A make/common/internal/Defs-asm.gmk A test/org/openjdk/org/objectweb/asm/OmitCommons.java A test/org/openjdk/org/objectweb/asm/OmitOptimizer.java A test/org/openjdk/org/objectweb/asm/OmitTreeAnalysis.java A test/org/openjdk/org/objectweb/asm/OmitUtil.java A test/org/openjdk/org/objectweb/asm/OmitXml.java A test/org/openjdk/org/objectweb/asm/RequiredAsmClasses.java These changes have not been reviewed and thus are subject to change. Hopefully, this work can be finished in the next couple weeks. But where have we heard that before. Please let me know if you have any questions or need more info. - jjh
Re: Adding asm to JDK 8
On 2/2/2012 7:13 PM, David Holmes wrote: Okay two questions :) : do you know when this will get modularized and show up in the jigsaw repositories? FWIW. We have been sync'ing up jigsaw forest with jdk8 periodically and hope to do it in a regular basis. It's currently sync'ed with jdk8-b23. When asm shows up in jdk8 promoted build, I hope to pull it down and do the merge in the following week or two depending on how it'll be modularized and their dependencies. Mandy
Re: Adding asm to JDK 8
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. On 2/2/2012 10:33 PM, Mandy Chung wrote: On 2/2/2012 7:13 PM, David Holmes wrote: Okay two questions :) : do you know when this will get modularized and show up in the jigsaw repositories? FWIW. We have been sync'ing up jigsaw forest with jdk8 periodically and hope to do it in a regular basis. It's currently sync'ed with jdk8-b23. When asm shows up in jdk8 promoted build, I hope to pull it down and do the merge in the following week or two depending on how it'll be modularized and their dependencies. Mandy
Re: Adding asm to JDK 8
On 3/02/2012 1: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. That will be an interesting testcase for jigsaw as well I think. David On 2/2/2012 10:33 PM, Mandy Chung wrote: On 2/2/2012 7:13 PM, David Holmes wrote: Okay two questions :) : do you know when this will get modularized and show up in the jigsaw repositories? FWIW. We have been sync'ing up jigsaw forest with jdk8 periodically and hope to do it in a regular basis. It's currently sync'ed with jdk8-b23. When asm shows up in jdk8 promoted build, I hope to pull it down and do the merge in the following week or two depending on how it'll be modularized and their dependencies. Mandy
Re: Adding asm to JDK 8
Jim, Do you plan to remove one already existing in the rt.jar (it comes from jax-ws)? com.sun.xml.internal.ws.org.objectweb.asm Do you have permission to include one particular version or plan to sync it regularly? -Dmitry On 2012-02-03 07:13, David Holmes wrote: Hi Jim, I added build-dev to the cc as this is of general interest. Actually before doing this a heads-up should go out to all jdk8-dev I think. One question: are there any cross-compilation issues with building this? I'm assuming not but want to check. Okay two questions :) : do you know when this will get modularized and show up in the jigsaw repositories? Thanks, David On 3/02/2012 9:29 AM, Jim Holmlund wrote: This is just a heads up that we are in the process of adding http://asm.ow2.org/ to jdk 8 as a new top level repo. This new repo contains the asm source code, with a few mods that are needed to build/run it in our environment. The new repo also contains the build files needed to participate in our forest builds. The main building is done by the asm build.xml, with a Makefile wrapper around that in order to participate in the forest build. This Makefile dynamically renames the asm packages by prepending 'org.openjdk'. The forest build handles the asm repo in the same was as the other repos, eg, corba. The asm repo is built just after langtools, and then the resulting .class files are known in the jdk build and are put into rt.jar. The changes for this are: - These files are modified/added: M Makefile M make/Defs-internal.gmk M make/README.pre-components A make/asm-rules.gmk M make/jdk-rules.gmk M make/sanity-rules.gmk M make/scripts/hgforest.sh - the new asm repo is built just after langtools - these files in the jdk repo are modified/added: M THIRD_PARTY_README M make/Makefile M make/common/Release.gmk M make/common/internal/ImportComponents.gmk M make/common/shared/Defs-control.gmk M make/common/shared/Defs.gmk M make/common/shared/Sanity-Settings.gmk A make/common/internal/Defs-asm.gmk A test/org/openjdk/org/objectweb/asm/OmitCommons.java A test/org/openjdk/org/objectweb/asm/OmitOptimizer.java A test/org/openjdk/org/objectweb/asm/OmitTreeAnalysis.java A test/org/openjdk/org/objectweb/asm/OmitUtil.java A test/org/openjdk/org/objectweb/asm/OmitXml.java A test/org/openjdk/org/objectweb/asm/RequiredAsmClasses.java These changes have not been reviewed and thus are subject to change. Hopefully, this work can be finished in the next couple weeks. But where have we heard that before. Please let me know if you have any questions or need more info. - jjh -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
