Re: Review Request: Build-infra M1
One final review update. Cleanup of configure help output and make help target in root repo. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.03/ /Erik On 2012-04-03 11:59, Erik Joelsson wrote: Fixed these comments and posted new webrevs: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.02/ (Tried making a single webrev but my forest extension isn't working that well) /Erik On 2012-03-30 20:08, Kelly O'Hair wrote: Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet "...the boot jdk target bytecode." Everything else looks ok to me. -kto On 2012-03-30 15:19, Jonathan Gibbons wrote: langtools makefile... line 55 typo in comment "ony" line 57 grammar in comment "list of to be created" The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either "strip them of all content" or "strip all content from them" line 168: not clear what "this setup" refers to. -- Jon
Re: Review Request: Build-infra M1
In langtools/Makefile, line 42, bad/inappropriate/editorial comment: A more palatable solution would be to add the GenStubs functionality to javac. It would be totally unacceptable to add GenStubs to javac, so the comment is irrelevant. line 120, 130-138, the nio files are not required when building on JDK 7. line 179, what is javax.tools.JavaCompilerTool and why is it listed as in RESOURCE_SUFFIXES line 194, is the JARMAIN required? It should not be used downstream, so does it need to be set here? -- Jon On 04/04/2012 07:41 AM, Erik Joelsson wrote: One final review update. Cleanup of configure help output and make help target in root repo. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.03/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new.03/ /Erik On 2012-04-03 11:59, Erik Joelsson wrote: Fixed these comments and posted new webrevs: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.02/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new.02/ (Tried making a single webrev but my forest extension isn't working that well) /Erik On 2012-03-30 20:08, Kelly O'Hair wrote: Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet ...the boot jdk target bytecode. Everything else looks ok to me. -kto On 2012-03-30 15:19, Jonathan Gibbons wrote: langtools makefile... line 55 typo in comment ony line 57 grammar in comment list of to be created The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either strip them of all content or strip all content from them line 168: not clear what this setup refers to. -- Jon
Re: Review Request: Build-infra M1
We have also updated the user guide, which is available at http://openjdk.java.net/projects/build-infra/guide.html. The guide now also includes an FAQ. I'm still working on adding more Qs and As as discussed here on the list to it. If you have any questions that you'd like to see answered in it, feel free to let me know. /Magnus 4 apr 2012 kl. 16:41 skrev Erik Joelsson erik.joels...@oracle.com: One final review update. Cleanup of configure help output and make help target in root repo. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.03/ /Erik On 2012-04-03 11:59, Erik Joelsson wrote: Fixed these comments and posted new webrevs: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.02/ (Tried making a single webrev but my forest extension isn't working that well) /Erik On 2012-03-30 20:08, Kelly O'Hair wrote: Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet ...the boot jdk target bytecode. Everything else looks ok to me. -kto On 2012-03-30 15:19, Jonathan Gibbons wrote: langtools makefile... line 55 typo in comment ony line 57 grammar in comment list of to be created The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either strip them of all content or strip all content from them line 168: not clear what this setup refers to. -- Jon
Re: Review Request: Build-infra M1
On 2012-04-04 16:56, Jonathan Gibbons wrote: In langtools/Makefile, line 42, bad/inappropriate/editorial comment: "A more palatable solution would be to add the GenStubs functionality to javac." It would be totally unacceptable to add GenStubs to javac, so the comment is irrelevant. Removing line 120, 130-138, the nio files are not required when building on JDK 7. I'm not very familiar with this functionality. Are you recommending us to completely disable this part for now as it isn't needed right now? line 179, what is "javax.tools.JavaCompilerTool" and why is it listed as in RESOURCE_SUFFIXES It's possible we could express this differently. It's a file that needs to be copied as a resource (from source to classes dir) and this was the easiest way I found of getting it to be copied. Adding a comment to explain it for now. line 194, is the JARMAIN required? It should not be used downstream, so does it need to be set here? Probably not. Removing and testing. -- Jon On 04/04/2012 07:41 AM, Erik Joelsson wrote: One final review update. Cleanup of configure help output and make help target in root repo. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.03/ /Erik On 2012-04-03 11:59, Erik Joelsson wrote: Fixed these comments and posted new webrevs: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.02/ (Tried making a single webrev but my forest extension isn't working that well) /Erik On 2012-03-30 20:08, Kelly O'Hair wrote: Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet "...the boot jdk target bytecode." Everything else looks ok to me. -kto On 2012-03-30 15:19, Jonathan Gibbons wrote: langtools makefile... line 55 typo in comment "ony" line 57 grammar in comment "list of to be created" The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either "strip them of all content" or "strip all content from them" line 168: not clear what "this setup" refers to. -- Jon
Re: Review Request: Build-infra M1
On 04/04/2012 08:39 AM, Erik Joelsson wrote: line 179, what is javax.tools.JavaCompilerTool and why is it listed as in RESOURCE_SUFFIXES It's possible we could express this differently. It's a file that needs to be copied as a resource (from source to classes dir) and this was the easiest way I found of getting it to be copied. Adding a comment to explain it for now. OK, I see it now. Oops. It appears to be vestiges of incomplete undocumented functionality. Neither the name of the file or the name in it refer to valid types. I'll file a CR to remove it. -- Jon
Re: Review Request: Build-infra M1
Fixed these comments and posted new webrevs: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.02/ http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.02/ (Tried making a single webrev but my forest extension isn't working that well) /Erik On 2012-03-30 20:08, Kelly O'Hair wrote: Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet "...the boot jdk target bytecode." Everything else looks ok to me. -kto On 2012-03-30 15:19, Jonathan Gibbons wrote: langtools makefile... line 55 typo in comment "ony" line 57 grammar in comment "list of to be created" The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either "strip them of all content" or "strip all content from them" line 168: not clear what "this setup" refers to. -- Jon
Re: Review Request: Build-infra M1
Updated one webrev root: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.02/ * Legal headers on all files except compress.post, compress.pre and uncompress.sed. * Fixed check for static c++ linking, was supposed to be fixed already but the change had somehow disappeared. /Erik On 2012-03-29 16:05, Erik Joelsson wrote: Updated webrevs: root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.01/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.01/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.01/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new.01/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new.01/ jdk, all changes including a partial copy of the old makefiles http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new.01/ General changes: * Added link to documentation to README-builds.html. It's currently just a short user guide but we plan to expand on this over the next week. http://openjdk.java.net/projects/build-infra/guide.html * Fixed legal headers. * Cleanup of variable names in configure. * Numerous bugfixes. The GenerateNativeHeaders change has made it into jdk8-master but hasn't gone into the build forest yet. Same goes for our last hotspot build change (JVM_VARIANT*). Both of these are needed for the new build to function properly. Now please share your comments. Especially regarding what information you would like to see in the documentation. /Erik On 2012-03-21 15:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to "common/makefiles" and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can
Re: Review Request: Build-infra M1
Editorial comments like this one in the langtools makefile are inappropriate and should be removed. 53 # (By the way, resource bundles are silly, get rid of them, read the properties directly instead.) -- Jon On 03/30/2012 12:56 PM, Erik Joelsson wrote: Updated one webrev root: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.02/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new.02/ * Legal headers on all files except compress.post, compress.pre and uncompress.sed. * Fixed check for static c++ linking, was supposed to be fixed already but the change had somehow disappeared. /Erik On 2012-03-29 16:05, Erik Joelsson wrote: Updated webrevs: root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new.01/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new.01/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new.01/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxp-new.01/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxws-new.01/ jdk, all changes including a partial copy of the old makefiles http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-new.01/ General changes: * Added link to documentation to README-builds.html. It's currently just a short user guide but we plan to expand on this over the next week. http://openjdk.java.net/projects/build-infra/guide.html * Fixed legal headers. * Cleanup of variable names in configure. * Numerous bugfixes. The GenerateNativeHeaders change has made it into jdk8-master but hasn't gone into the build forest yet. Same goes for our last hotspot build change (JVM_VARIANT*). Both of these are needed for the new build to function properly. Now please share your comments. Especially regarding what information you would like to see in the documentation. /Erik On 2012-03-21 15:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build
Re: Review Request: Build-infra M1
langtools makefile... line 55 typo in comment ony line 57 grammar in comment list of to be created The Swedish examples are somewhat silly since there are no swedish properties files. The comments on line 92--94 are inaccurate: javac is only build twice, not three times. line 130: grammar, should be either strip them of all content or strip all content from them line 168: not clear what this setup refers to. -- Jon On 03/30/2012 12:56 PM, Erik Joelsson wrote: Updated one webrev root: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.02/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new.02/ * Legal headers on all files except compress.post, compress.pre and uncompress.sed. * Fixed check for static c++ linking, was supposed to be fixed already but the change had somehow disappeared. /Erik On 2012-03-29 16:05, Erik Joelsson wrote: Updated webrevs: root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new.01/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new.01/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new.01/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxp-new.01/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxws-new.01/ jdk, all changes including a partial copy of the old makefiles http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new.01/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-new.01/ General changes: * Added link to documentation to README-builds.html. It's currently just a short user guide but we plan to expand on this over the next week. http://openjdk.java.net/projects/build-infra/guide.html * Fixed legal headers. * Cleanup of variable names in configure. * Numerous bugfixes. The GenerateNativeHeaders change has made it into jdk8-master but hasn't gone into the build forest yet. Same goes for our last hotspot build change (JVM_VARIANT*). Both of these are needed for the new build to function properly. Now please share your comments. Especially regarding what information you would like to see in the documentation. /Erik On 2012-03-21 15:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/
Re: Review Request: Build-infra M1
Corba Makefile says: 45 # Thus we force the target bytecode to 6. But I think 6 should be 7, or better yet ...the boot jdk target bytecode. Everything else looks ok to me. -kto On Mar 29, 2012, at 7:05 AM, Erik Joelsson wrote: Updated webrevs: root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.01/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.01/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.01/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new.01/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new.01/ jdk, all changes including a partial copy of the old makefiles http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new.01/ General changes: * Added link to documentation to README-builds.html. It's currently just a short user guide but we plan to expand on this over the next week. http://openjdk.java.net/projects/build-infra/guide.html * Fixed legal headers. * Cleanup of variable names in configure. * Numerous bugfixes. The GenerateNativeHeaders change has made it into jdk8-master but hasn't gone into the build forest yet. Same goes for our last hotspot build change (JVM_VARIANT*). Both of these are needed for the new build to function properly. Now please share your comments. Especially regarding what information you would like to see in the documentation. /Erik On 2012-03-21 15:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to common/makefiles and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-March/000571.html
Review Request: Build-infra M1
Updated webrevs: root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new.01/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new.01/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new.01/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new.01/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new.01/ jdk, all changes including a partial copy of the old makefiles http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new.01/ General changes: * Added link to documentation to README-builds.html. It's currently just a short user guide but we plan to expand on this over the next week. http://openjdk.java.net/projects/build-infra/guide.html * Fixed legal headers. * Cleanup of variable names in configure. * Numerous bugfixes. The GenerateNativeHeaders change has made it into jdk8-master but hasn't gone into the build forest yet. Same goes for our last hotspot build change (JVM_VARIANT*). Both of these are needed for the new build to function properly. Now please share your comments. Especially regarding what information you would like to see in the documentation. /Erik On 2012-03-21 15:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to "common/makefiles" and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1]
Re: Review Request: Build-infra M1
This isn't really an issue for the first push, more of a question as to how this will all look once the remaining make files has been converted. My question relates to jdk/makefiles/CompileJavaClasses.gmk and CompileNativeLibraries.gmk and how they will be maintained more longer term. Is the intention that over time that the references to AWT, JDWP, SCTP, and other specific areas will be moved elsewhere? -Alan
Re: Review Request: Build-infra M1
2012-03-27 16:39, Michael McMahon skrev: A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? You run configure once to setup a particular build configuration. After it is run, you only need to run make for the build configuration. Rerunning configure on an already setup build configuration is not recommended. If you want to tweak something (like different flags to compilers and such, just edit the generated spec.gmk file. 2) Can you give examples of the kind of build changes that would be needed :- - when a small'ish change is made (eg adding a couple of new source files, or renaming or removing them)? Adding/removing source files does not require a rerun of configure. - when a new component is added, with both Java and native sources in new source directories Adding an entire subdirectory of sources, more native source etc etc does not require a rerun of configure. Configure does not care about source code layout except where the repositories are. It knows how to find/download compilers/linkers/tools and create a spec.gmk file with all the necessary variables that encode this information. (For example: CC,JDK_TOPDIR,OUTPUT_ROOT,ARCH etc etc) //Fredrik
Re: Review Request: Build-infra M1
On 27/03/12 16:04, Fredrik Öhrström wrote: 2012-03-27 16:39, Michael McMahon skrev: A few more things I'd like to understand are: 1) In what circumstances exactly would the configure script have to be re-run? You run configure once to setup a particular build configuration. After it is run, you only need to run make for the build configuration. Rerunning configure on an already setup build configuration is not recommended. If you want to tweak something (like different flags to compilers and such, just edit the generated spec.gmk file. 2) Can you give examples of the kind of build changes that would be needed :- - when a small'ish change is made (eg adding a couple of new source files, or renaming or removing them)? Adding/removing source files does not require a rerun of configure. - when a new component is added, with both Java and native sources in new source directories Adding an entire subdirectory of sources, more native source etc etc does not require a rerun of configure. Configure does not care about source code layout except where the repositories are. It knows how to find/download compilers/linkers/tools and create a spec.gmk file with all the necessary variables that encode this information. (For example: CC,JDK_TOPDIR,OUTPUT_ROOT,ARCH etc etc) Right. Configure doesn't need to be re-run, but presumably there is some build meta-information linking sources to target libraries etc. Say a new native library libfoo were to be added with associated C (and Java) sources. Where would this get added to the build system? - Michael
Re: Review Request: Build-infra M1
2012-03-27 17:21, Michael McMahon skrev: Right. Configure doesn't need to be re-run, but presumably there is some build meta-information linking sources to target libraries etc. Say a new native library libfoo were to be added with associated C (and Java) sources. Where would this get added to the build system? New Java sources in the jdk need no special treatment (though if they are platform dependent you might have to be careful how they are added to the source tree, since it is a mess) and they are all compiled in a single javac invocation defined in CompileJavaClasses.gmk For native libraries, a new library is added as a macro call to SetupNativeCompilation in CompileNativeLibraries.gmk. All libraries are added to the variable BUILD_LIBRARIES and the target all depends on $(BUILD_LIBRARIES) The macro SetupNativeCompilation configures all dependencies between source files (and header files) to object files to the library. Enabling incremental builds. //Fredrik
Re: Review Request: Build-infra M1
On 23/03/12 19:11, Fredrik Öhrström wrote: in increasing order of verbosity make VERBOSE= make VERBOSE=-d make VERBOSE=-d -p Thanks. It looks like the first of the three options above is most similar to the verbosity level of the old build. Is all of this documented anywhere? I think at the very least, a cheat-sheet will be needed to help people transition between the two systems, and options like the first one above will be very commonly used as part of that. Maybe an actual flag value for that setting (as opposed to the empty string) might be more meaningful. Another minor (newbie) comment, is that some of the configure flags are documented (in --help) as --with-XXX=PATH, but there are some that should be documented the same way, but aren't (--with-boot-jdk is the one many will see first) - Michael Den fredagen den 23:e mars 2012 skrev Michael McMahonmichael.x.mcma...@oracle.com mailto:michael.x.mcma...@oracle.com: Is it possible to get a more verbose style of echoing the complete compile/build commands like the old build ? - Michael On 21/03/12 14:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to common/makefiles and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-March/000571.html
Re: Review Request: Build-infra M1
2012-03-26 12:05, Michael McMahon skrev: Thanks. It looks like the first of the three options above is most similar to the verbosity level of the old build. Is all of this documented anywhere? Well, I have so far really tried to comment in the makefiles. So the make VERBOSE= trick is the first thing that is written in the root Makefile. :-) However, I agree that reading the makefiles really, is not an option for most people. Thus here is a first cheat sheet of the options that are of OpenJDK builder interest. (The list will change and also be expanded with more configuration options.) It is in fact the output from configure --help where I have removed options of more generic interest and that are not really used yet. For example detailed install locations and such. The configure script tries to figure everything out for you. The goal is that you should not have to configure the number of cores, where the boot jdk is etc etc. For example, the configure script does try to find your boot jdk on Windows by looking in the default installation locations. It does so only partially on the Mac. (Please add that code to configure.ac if you like!) So you specify --with-boot-jdk=jdk7 only when want to override, or if you have a special installation. The same is true for most other options, number of cores, amount of memory etc etc. On Windows, you have to specify the path to the freetype dlls and header files. Since they have no default location. But the configure script will find your visual studio installation! Typical configure examples: # Plain and simple, build a release version. ../autoconf/configure # You want to debug? ../autoconf/configure --enable-debug # A windows build. ../autoconf/configure --with-freetype=/cygdrive/c/downloads/myfreetype --with-boot-jdk=/cygdrive/c/javas/jdk7 # Build using incremental build for java. Ie rebuild only the package and its dependent packages when a single # Java source file is changed. ../autoconf/configure --enable-javac-server --enable-javac-deps --enable-javac-multi-core # Cross compiling to 32 bit, and build only the server jvm. ../autoconf/configure --host=i686-unknown-linux-gnu --with-sys-root=/home/sysroots/for32bitlinux --with-jvm-variants=server # Plain and simple. make # Debug the build process. make VERBOSE= # If you have run configure twice from the makefiles directory. # (For example you have normal configure and a cross configure) # This make command will build all configurations. make ALL --- --build=BUILD configure for building on BUILD [guessed] But it is recommended that you set it. --host=HOST cross-compile to build programs to run on HOST [BUILD] --disable-head Should support for a head (graphical UI support) be compiled into the jdk/jvm? [default=enabled] --enable-debug Enable the debug level=fastdebug, ie asserts, -g and optimizations. --disable-ccacheShould ccache be used to speed up recompilations? [default=enabled] --disable-precompiled-headers Should precompiled headers be used by the C++ compiler [default=enabled] --enable-javac-server Disable the shared javac server during the build process, which is enabled by default. --enable-javac-deps Enable the dependency tracking between Java packages. --enable-javac-multi-core Compile Java packages concurrently instead of doing a batch compile of each source root. --disable-macosx-runtime-support Disable use of the MacOSX Java runtime support framework. --disable-docs Disable generation of documentation [default=disabled] (Should be enabled, but we really need to fix the speed of javadoc!) --disable-nimbusDisable nimbus LF [default=enabled] --disable-static-link-stdc++ Use only dynamic linking to the c++ runtime on Linux. The default is to static link. --enable-hotspot-test-in-build Enable running of Queens test after Hotspot build. Automatically disabled when cross compiling. --with-num-cores=32 specify the number of cores in the build system. --with-memorysize=1024 specify the number MB of memory in the build system. Used to limit number of concurrent javacs. --with-jdk-variant Choose jdk variant to build: normal,embedded. [default=normal] --with-jvm-variants Choose jvm variants, separated by commas, to build:
Re: Review Request: Build-infra M1
On 03/26/2012 12:09 PM, Fredrik Öhrström wrote: However, I agree that reading the makefiles really, is not an option for most people. ... or even desirable. :-) -- Jon
Re: Review Request: Build-infra M1
Nothing that can't be fixed or adjusted after the initial integration. So consider me a reviewer. Just a few comments. * I noticed that the copyright years were a little strange, saying Copyright (c) 2007, 2011, instead of Copyright (c) 2011, 2012, or Copyright (c) 2012,. * The @GenerateNativeHeader additions seem like they deserve some kind of comment, maybe a short one on the same line, like No native methods here, but the constants are needed in the supporting JNI code or something like that? * The top repo's additions are a bit of a mind blower. Lots of stuff here. Haven't seem m4 files in a long time. ;^) - In common/makefiles/IdlCompilation.gmk, lines 82-84 it says 82 $(if $3,$1_$(strip $2)) 83 $(if $3,$1_$(strip $3)) 84 $(if $4,$1_$(strip $4)) Is line 82 right? $3 and not $2? - In common/makefiles/MakeBase.gmk, this is very strange to me: 134 compress_pre:=$(strip $(shell cat $(SRC_ROOT)/common/makefiles/compress.pre)) 135 compress_post:=$(strip $(shell cat $(SRC_ROOT)/common/makefiles/compress.post)) This path mapping logic seems like high maintenance. I understand what it is trying to get around, and I don't have any suggestions for improvements at this time, but it does look very very touchy stuff. :^( The good thing is that we have only one copy of it, and if anyone figures out a better way, we can change it, in one place. It will take me quite a bit of time to understand this new makefile logic completely. -kto On Mar 21, 2012, at 7:07 AM, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to common/makefiles and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-March/000571.html
Re: Review Request: Build-infra M1
2012-03-26 18:13, Kelly O'Hair skrev: * The @GenerateNativeHeader additions seem like they deserve some kind of comment, maybe a short one on the same line, like No native methods here, but the constants are needed in the supporting JNI code or something like that? Good idea! * The top repo's additions are a bit of a mind blower. Lots of stuff here. Haven't seem m4 files in a long time. ;^) - In common/makefiles/IdlCompilation.gmk, lines 82-84 it says 82 $(if $3,$1_$(strip $2)) 83 $(if $3,$1_$(strip $3)) 84 $(if $4,$1_$(strip $4)) Is line 82 right? $3 and not $2? Thank you for catching this! It is a bug, but the code works anyway, since there is always at least 3 arguments. - In common/makefiles/MakeBase.gmk, this is very strange to me: 134 compress_pre:=$(strip $(shell cat $(SRC_ROOT)/common/makefiles/compress.pre)) 135 compress_post:=$(strip $(shell cat $(SRC_ROOT)/common/makefiles/compress.post)) This path mapping logic seems like high maintenance. I understand what it is trying to get around, and I don't have any suggestions for improvements at this time, but it does look very very touchy stuff. :^( The good thing is that we have only one copy of it, and if anyone figures out a better way, we can change it, in one place. Well, the compression does not need to be perfect, it just helps out when chunking a list of paths into units that can be handled by the command line length limits on cygwin and solaris. If there was a single feature that I would like to have in make, it would be a way to export a variable to a file on disk, without having to go through the command line. This is particularly problematic with Java since there are so many more Java sources in a Java project, than there are C sources in a C-project. Not even the list of packages in the jdk fits on the cygwin command line! //Fredrik
Re: Review Request: Build-infra M1
Kelly, On 24/03/2012 1:16 AM, Kelly O'Hair wrote: On Mar 22, 2012, at 4:51 PM, David Holmes wrote: Not wanting to go too OT here but I see the build-deps server as something to be used at most per machine rather than per developer. We have build servers internally that can be used by dozens of developers and we don't want multiple copies of toolsets. Even in the new build system I would expect to see the toolsets (for cross-compilation) installed on shared NFS mounts for use by these build servers. But at worse I would expect to have one installation per machine. Unless it is done properly, having multiple developers updating a single machine copy of build dependency files could be a disaster. I don't know what exactly you mean by that but I don't propose that multiple developers update anything. I expect multiple developers to _use_ a stable (perhaps local) copy of the build tools for the build they are doing. How that one copy gets setup is a different issue. David - Not all developers would be working on source bases with the exact same dependencies. And NFS mounts create even more complications, creating a network dependence and similar update issues. If you don't have control over these dependencies, every build you do could result in different bits, and if the build dependencies do need to change, it's important that the individual developer knows that they did change, and how to back it out or realize why things changed. It has been my view that local disk space is not an issue on most modern systems, and having many copies is not a problem if it is managed automatically and not manually, i.e. they really are the right copies. Having it local and unique to that developer would provide the most predictable results, but only if we can get the automatic install/update logic reliable. I'm currently having a great deal of problem with our internal buildtest system and it's all related to the systems changing out from under us all the time. Automatic updates being installed, automatic virus definitions changing, automatic defragmentation of the disks every week, services that keep other services running, and automatic reboots for a variety of reasons. Virtual machines also come with mixed blessings, it's a complicated world. Stability and predictability is hard in an ever changing world. So I'm frequently trying to make sure that we are dealing with fewer variables and more constants, and if the constants need to change, change them carefully. -kto
Re: Review Request: Build-infra M1
On 24/03/2012 5:57 AM, Andrew Hughes wrote: I know that's the current status quo. It seemed to be being suggested that the closed rules be removed from the public Makefiles and kept separately. Maybe I misunderstood. No, that is what I am proposing. Why should instructions on how to build sources that don't exist in the OpenJDK be part of the OpenJDK makefiles? At best they are just clutter for OpenJDK developers. David --
Re: Review Request: Build-infra M1
2012-03-23 00:51, David Holmes skrev: Not wanting to go too OT here but I see the build-deps server as something to be used at most per machine rather than per developer. We have build servers internally that can be used by dozens of developers and we don't want multiple copies of toolsets. And this is exactly how the configure script is setup. If you run configure --help you see: --with-builddeps-dirstore downloaded build dependencies here [default=/localhome/builddeps] Ie. the default installation is directory is supposed to be shared on the build server, and to do it correctly, you have also: --with-builddeps-group chgrp the downloaded build dependencies to this group it even takes precautions to make it work even when to concurrent configures try to download the same builddeps. Even in the new build system I would expect to see the toolsets (for cross-compilation) installed on shared NFS mounts for use by these build servers. But at worse I would expect to have one installation per machine. The builddeps supports using an NFS-mount as well. Please have a look in builddeps.java.conf which is useful to verify the old way of building with an active nfs-mount. Using an NFS-mount is so 1990:ish. At least, when it has no support for versioning the builddeps and no automated assistance to install only the necessary builddeps on the build machine. I firmly believe that openjdk build files should only contain instructions for building openjdk source code. The alt-src mechanism is a simple mechanism to let us override an open source file with a closed one. This mechanism is available to anyone who wants to customize their OpenJDK without hacking the main OpenJDK sources. And the configure equivalent to alt-src is called --with-add-source-root=/--with-override-source-root= My concern, hence my question about needing to read/understand this file, is what happens if it doesn't work on a system? How do we debug the issue? Sure we can just run autoconf to generate a new (and hopefully working) version, but how do we determine what needs to get checked back into the repo? You debug it, usually by adding echo debugme=$VARTODEBUG in configure.ac, regenerating configure, and checking the output. The complexity of the generated configure script is that it is cross-shell compatible. I.e. it runs on many different versions of shells, not just bash and if you use macros like AC_LINK_IFELSE, then clearly you are happy that you did not have to write the expanded code yourself. We should standardize on a version of autoconf to use, to minimize the changes to the configure script, when an update is made. However it is unnecessaru to worry too much about the configure diff, since a small change in configure.ac can cause a large change in the configure scripts, it is after all compiled code. But the configure.ac program itself, is not complex, as programs go. Just one test after another and some if statements. However there are a lot of tests to do, which reflects of course the complexity of setting up the OpenJDK build on different platforms. //Fredrik
Re: Review Request: Build-infra M1
On Mar 22, 2012, at 4:51 PM, David Holmes wrote: Not wanting to go too OT here but I see the build-deps server as something to be used at most per machine rather than per developer. We have build servers internally that can be used by dozens of developers and we don't want multiple copies of toolsets. Even in the new build system I would expect to see the toolsets (for cross-compilation) installed on shared NFS mounts for use by these build servers. But at worse I would expect to have one installation per machine. Unless it is done properly, having multiple developers updating a single machine copy of build dependency files could be a disaster. Not all developers would be working on source bases with the exact same dependencies. And NFS mounts create even more complications, creating a network dependence and similar update issues. If you don't have control over these dependencies, every build you do could result in different bits, and if the build dependencies do need to change, it's important that the individual developer knows that they did change, and how to back it out or realize why things changed. It has been my view that local disk space is not an issue on most modern systems, and having many copies is not a problem if it is managed automatically and not manually, i.e. they really are the right copies. Having it local and unique to that developer would provide the most predictable results, but only if we can get the automatic install/update logic reliable. I'm currently having a great deal of problem with our internal buildtest system and it's all related to the systems changing out from under us all the time. Automatic updates being installed, automatic virus definitions changing, automatic defragmentation of the disks every week, services that keep other services running, and automatic reboots for a variety of reasons. Virtual machines also come with mixed blessings, it's a complicated world. Stability and predictability is hard in an ever changing world. So I'm frequently trying to make sure that we are dealing with fewer variables and more constants, and if the constants need to change, change them carefully. -kto
Re: Review Request: Build-infra M1
in increasing order of verbosity make VERBOSE= make VERBOSE=-d make VERBOSE=-d -p Den fredagen den 23:e mars 2012 skrev Michael McMahon michael.x.mcma...@oracle.com: Is it possible to get a more verbose style of echoing the complete compile/build commands like the old build ? - Michael On 21/03/12 14:07, Erik Joelsson wrote: As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to common/makefiles and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-March/000571.html
Re: Review Request: Build-infra M1
- ahug...@redhat.com skrev: I know that's the current status quo. It seemed to be being suggested that the closed rules be removed from the public Makefiles and kept separately. Maybe I misunderstood. Well, I guess I would like the closed rules be so simple that the default add/override functionality in the configure script is enough. With IcedTea, most of the changes are build changes for obvious reasons, so nearly every commit was regenerating configure :-) The goal for the new build system must be, that for normal OpenJDK development, there should rarely be any need to regenerate configure. The configure script and the makefiles should deal with any normal change/addition/removal of source code and new modules. Configure should only change to manage new platforms, new compilers etc. //Fredrik
Re: Review Request: Build-infra M1
- david.hol...@oracle.com skrev: My major concern with the transition here is being able to take existing knowledge of the build system and be able to figure out where in the new system certain things are handled. How can I tell if a Makefile is part of the old build or the new build? Are some both? You read the file named LegacyMakefiles.gmk and you will understand that the contents of java, javax, sun and com contain the remaining legacy makefiles. The contents of these will be brought up to the makefiles toplevel and put into CompileNativeLibraries and or some of the other toplevel makefiles. This coming together is a necessary step to add correct dependencies and to prepare for the Jigsaw split into modules in the future. It is still unclear to me how cross-compilation is to be set up. You can cross compile from x64 linux to ia32 linux, with the following commandline: ../autoconf/configure \ --host=i686-unknown-linux-gnu \ --with-builddeps-conf=/home/ohrstrom/jdk8/common/autoconf/builddeps.conf.example \ --with-builddeps-server=buildtools.se.oracle.com/buildtools/openjdk \ --with-builddeps-dir=/home/ohrstrom/builddeps \ --with-jvm-variants=client,server For those outside of Oracle, the builddeps server is not available, you have to have i686-unknown-linux-gnu-gcc et al in your path, and drop the builddeps options. Sounds silly to cross compile from x64 to ia32, yes, but the command above exercising everything that is needed for cross compilation. What remains is to find the correct CC for compiling to/for the build platform (legacy name HOSTCC), in configure for the hotspot build. By running from x64 linux to ia32 linux, I cheat since the i686-unknown-linux-gnu-gcc works for the build platform as well. It is unclear to me how the src/closed and make/closed repositories are supported/handled. Going forward much of what pertains to Oracle JDK proprietary features, should be moved out of the OpenJDK repository in my opinion. The new makefiles do build the closed jdk, even though it has to use the current totally broken way of injecting source code repositories smack in the middle of the openjdk sources. Of course, there should be no trace of closed jdk code, neither in the makefiles, nor in the source code. And there is a solution for this in the configure script, ie the add/override source roots commands. But that potential solution is irrelevant as long as the open/closed source code repositories are structured the way they are. Is there a cheat sheet for how to run configure? There are many options that seems completely irrelevant to what would normally be part of a JDK build; conversely some obvious flags seem to be missing eg ALT_OUTPUTDIR. You set the OUTPUTDIR by running the configure script from the outputdir, then run make from the outputdir. This was explained during the tech talk and the information was available to you as a pdf. (Since you refused to have a paper version sent to you.) Is it intended that any single person actually understand the contents of configure and need to edit it? It has strange contents (like multiple file copyright headers in places ???). Reading the configure script is like reading the bytecode of a Java program or reading the machine code generate from a c-compiler. Go ahead if you want to, but most people would prefer to read the source. ie configure.ac The BUILD_HEADLESS_ONLY option is not for what it has been used. A normal JDK build will build a JDK that has both headful and headless support (property: java.awt.headless=true). The BUILD_HEADLESS_ONLY flag was an artifact from our embedded build systems for use on platforms where it was simply not possible to build anything pertaining to the GUI systems ie no X11 headers or libraries. As has been pointed out recently BUILD_HEADLESS_ONLY doesn't actually work in current jdk8 (and likely jdk7 too). Undoubtedly. But this is one of many,many typical problems when digging through the current makefiles. A lot of options, like env variables, that are not commented, have no verification if they are set correctly, and in some cases, do not even work. Clearly it would be beneficial to be able to build a headless version of the jdk. Thus the option exists in the configure script. If the original makefiles are broken, well that is just something that we need to fix. common/makefiles/Makefile I may be misreading something but the help has 161 $(info make ALL # build images for all configurations) but the all: target only builds jdk, not images. True, a mistake in the comment. I'll fix. common/makefiles/compress.post common/makefiles/compress.pre ??? These are just weird. What role do they serve? Were they autogenerated? common/makefiles/uncompress.sed ??? what is this? Is it autogenerated? How do I know if I need to add anything to it? If you read the comments in the Makefile
Re: Review Request: Build-infra M1
Hello, Fredrik already answered most of this but I will add my own comments. On 2012-03-22 07:15, David Holmes wrote: Hi Erik, My major concern with the transition here is being able to take existing knowledge of the build system and be able to figure out where in the new system certain things are handled. How can I tell if a Makefile is part of the old build or the new build? Are some both? We have created a new directory in each repository called makefiles and that's where the new makefiles are. In the root, we needed more than just makefiles and created common for all of the new files. It is our intention to move the root Makefile from common/makefiles to the root when we actually make the switch. The jdk repo is a special case where we copied over much of the old makefiles from jdk/make to jdk/makefiles while doing the conversion. We needed a copy of the files to be able to change them without affecting the old build. (Typical changes would be removing them when converted and removing the subdirs-call to removed files and also sometimes removing partly converted functionality.) When we are done, all of the copied old files will be gone. It is still unclear to me how cross-compilation is to be set up. As Fredrik demonstrated, cross compilation has been in the design from early on, but we haven't put effort into actually solving the embedded build yet. It is unclear to me how the src/closed and make/closed repositories are supported/handled. Going forward much of what pertains to Oracle JDK proprietary features, should be moved out of the OpenJDK repository in my opinion. I completely agree that we should remove all (or as much as possible) traces of the proprietary Oracle stuff from the open makefiles. For now, we have just used the old ifndef OPENJDK, but this is something we plan on attacking. Is there a cheat sheet for how to run configure? There are many options that seems completely irrelevant to what would normally be part of a JDK build; conversely some obvious flags seem to be missing eg ALT_OUTPUTDIR. We don't have such documentation yet unfortunately. It would be a great help for us if you could give us a list of the variables that you usually need to tinker with so that we can make sure those have options. Is it intended that any single person actually understand the contents of configure and need to edit it? It has strange contents (like multiple file copyright headers in places ???). The configure script is generated using autoconf. The main input file is configure.ac which in turn imports a couple of more files (*.m4). common/makefiles/compress.post common/makefiles/compress.pre common/makefiles/uncompress.sed ??? what is this? Is it autogenerated? How do I know if I need to add anything to it? These are used in an elaborate hack to work around command line length limits. Not meant to be read by a sane human, but the resulting make macro for outputting large amounts of parameters to a command is pretty neat. Does this pertain only to the new javac server or is this a general enhancement to javac for 8? As I understand it, javac is getting a new shiny flag (-h I think) that will generate the headerfiles automatically for classes that either have native methods or are annotated with the GenerateNativeHeaders annotation. jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-other/ Most of these changes seem to be related to tool changes rather than being build system changes. Yes, we needed to change the APIs to some of the build tools to be able to write more effective make rules for them. If I remember correctly, there are two kinds of changes. 1: Make the tool work from one file to another instead of changing a file in place and 2: Change the parameter for supplying a file containing the command line to use @file which seems to be standard among a lot of tools. The latter was needed to make the tools compatible with the uncygdrive utility. Why do I have to cd to common/makefiles ? As I described above, we want to keep the new build system out of the way for now to not disrupt anything for the existing build. When we make the switch, the common/makefiles/Makefile will move down to the root. It's also possible to build from the outputdir if you prefer that. I tried this today and got a javac error compiling a Java2D demo - as report to the build-infra list. I saw your mail and will try to figure out what's wrong. I haven't seen this problem before. /Erik
Re: Review Request: Build-infra M1
Hi Fredrik, On 22/03/2012 5:05 PM, Fredrik Öhrström wrote: - david.hol...@oracle.com skrev: It is still unclear to me how cross-compilation is to be set up. You can cross compile from x64 linux to ia32 linux, with the following commandline: ../autoconf/configure \ --host=i686-unknown-linux-gnu \ --with-builddeps-conf=/home/ohrstrom/jdk8/common/autoconf/builddeps.conf.example \ --with-builddeps-server=buildtools.se.oracle.com/buildtools/openjdk \ --with-builddeps-dir=/home/ohrstrom/builddeps \ --with-jvm-variants=client,server For those outside of Oracle, the builddeps server is not available, you have to have i686-unknown-linux-gnu-gcc et al in your path, and drop the builddeps options. I couldn't access /home/ohrstrom either :( I guess this needs to be taken up internally to see how this build-deps stuff is to be setup, configured, and maintained. Something for M2 perhaps. Sounds silly to cross compile from x64 to ia32, yes, but the command above Not silly at all, we have an issue with that right now. exercising everything that is needed for cross compilation. What remains is to find the correct CC for compiling to/for the build platform (legacy name HOSTCC), in configure for the hotspot build. By running from x64 linux to ia32 linux, I cheat since the i686-unknown-linux-gnu-gcc works for the build platform as well. Ok, so as Erik added we're not quite there yet - but the pieces are lining up. It is unclear to me how the src/closed and make/closed repositories are supported/handled. Going forward much of what pertains to Oracle JDK proprietary features, should be moved out of the OpenJDK repository in my opinion. The new makefiles do build the closed jdk, even though it has to use the current totally broken way of injecting source code repositories smack in the middle of the openjdk sources. Of course, there should be no trace of closed jdk code, neither in the makefiles, nor in the source code. And there is a solution for this in the configure script, ie the add/override source roots commands. But that potential solution is irrelevant as long as the open/closed source code repositories are structured the way they are. Ok I see how src/closed is handled. What I can't see is how make/closed is handled, or more specifically how we factor out proprietary details into a distinct set of closed makefiles. Is there a cheat sheet for how to run configure? There are many options that seems completely irrelevant to what would normally be part of a JDK build; conversely some obvious flags seem to be missing eg ALT_OUTPUTDIR. You set the OUTPUTDIR by running the configure script from the outputdir, then run make from the outputdir. This was explained during the tech talk and the information was available to you as a pdf. (Since you refused to have a paper version sent to you.) Yes - Guilty as charged - I have a PDF somewhere. But it was a general question for everyone's benefit. Plus, if I run configure from common/makefiles that does not become the outputdir, it instead creates a top-level build directory in the repo (though config.log and config.status do pollute the current directory). Is it intended that any single person actually understand the contents of configure and need to edit it? It has strange contents (like multiple file copyright headers in places ???). Reading the configure script is like reading the bytecode of a Java program or reading the machine code generate from a c-compiler. Go ahead if you want to, but most people would prefer to read the source. ie configure.ac I'll take that as a No. ;-) common/makefiles/compress.post common/makefiles/compress.pre ??? These are just weird. What role do they serve? Were they autogenerated? common/makefiles/uncompress.sed ??? what is this? Is it autogenerated? How do I know if I need to add anything to it? If you read the comments in the Makefile where these commands are put to use, You will find in MakeBase.gmk that these tools are necessary to workaround command line length limitations on platforms like Solaris and Cygwin. Thanks for the pointer. It is not evident from the the webrev where/how these get used. Does this pertain only to the new javac server or is this a general enhancement to javac for 8? It is an enhancement for jdk8. Why do I have to cd to common/makefiles ? Because we want to keep the original makefiles in place, for the time being. Thus the new build system does not affect the old build system at all. The question was why do I have to cd into common/makefiles to run the configure script. I think the answer is because if you are in common/makefiles then a build directory will be created at the top-level of the repo forest; otherwise the pwd will be treated as the intended outputdir. Thanks, David //Fredrik
Re: Review Request: Build-infra M1
On 22/03/2012 6:35 PM, Fredrik Öhrström wrote: - david.hol...@oracle.com skrev: I tried this today and got a javac error compiling a Java2D demo - as report to the build-infra list. You are building a closed demo. The fix that written by Alan 2 weeks ago: Java2Demo breaks build, incompatible method in the same class has not been integrated into build-infra closed yet. Is there a flag to disable building this? I just grabbed a fresh clone of open and closed build-infra repos to try. Or should I remove the closed repos for now? Thanks, David //Fredrik
Re: Review Request: Build-infra M1
- david.hol...@oracle.com skrev: I tried this today and got a javac error compiling a Java2D demo - as report to the build-infra list. You are building a closed demo. The fix that written by Alan 2 weeks ago: Java2Demo breaks build, incompatible method in the same class has not been integrated into build-infra closed yet. //Fredrik
Re: Review Request: Build-infra M1
- david.hol...@oracle.com skrev: I couldn't access /home/ohrstrom either :( You can replace my home directory with yours. ;-) I guess this needs to be taken up internally to see how this build-deps stuff is to be setup, configured, and maintained. Something for M2 perhaps. Yes, absolutely. Sounds silly to cross compile from x64 to ia32, yes, but the command above Not silly at all, we have an issue with that right now. :-) exercising everything that is needed for cross compilation. What remains is to find the correct CC for compiling to/for the build platform (legacy name HOSTCC), in configure for the hotspot build. By running from x64 linux to ia32 linux, I cheat since the i686-unknown-linux-gnu-gcc works for the build platform as well. Ok, so as Erik added we're not quite there yet - but the pieces are lining up. They are indeed, and there are a lot of them, that is why these makefiles have to go into jdk8 now, because it will take a few iterations to have them aligned perfectly. Yes - Guilty as charged - I have a PDF somewhere. But it was a general question for everyone's benefit. We will definitely create a nice cheat sheet! Some of the options available to configure are there as of default. Most of the options are not needed by the daily openjdk developer. to, but most people would prefer to read the source. ie configure.ac I'll take that as a No. ;-) Its got a lot of tasty comments... :-) The question was why do I have to cd into common/makefiles to run the configure script. I think the answer is because if you are in common/makefiles then a build directory will be created at the top-level of the repo forest; otherwise the pwd will be treated as the intended outputdir. That is another good answer. But we want the configure script and the makefile to be in the root in the future, but we cant put it there since it would interfere with the old Makefile in place. //Fredrik
Re: Review Request: Build-infra M1
Until we have done the integration later today. Please just build the openjdk. Thanks! //Fredrik - david.hol...@oracle.com skrev: On 22/03/2012 6:35 PM, Fredrik Öhrström wrote: - david.hol...@oracle.com skrev: I tried this today and got a javac error compiling a Java2D demo - as report to the build-infra list. You are building a closed demo. The fix that written by Alan 2 weeks ago: Java2Demo breaks build, incompatible method in the same class has not been integrated into build-infra closed yet. Is there a flag to disable building this? I just grabbed a fresh clone of open and closed build-infra repos to try. Or should I remove the closed repos for now? Thanks, David //Fredrik
Re: Review Request: Build-infra M1
On 2012-03-22 09:32, David Holmes wrote: The question was why do I have to cd into common/makefiles to run the configure script. I think the answer is because if you are in common/makefiles then a build directory will be created at the top-level of the repo forest; otherwise the pwd will be treated as the intended outputdir. Actually, you can run configure from the root, common/, common/makefiles or common/autoconf and it will behave the same. I chose to not give multiple options in the build instructions to avoid confusion. Instead I opted for common/makefiles since you would probably want to run make from there afterwards anyway. /Erik
Re: Review Request: Build-infra M1
I just noticed that due to a hg config error, my last integ didn't get pushed to this particular repo. Fixed now. /Erik On 2012-03-22 09:37, David Holmes wrote: On 22/03/2012 6:35 PM, Fredrik Öhrström wrote: - david.hol...@oracle.com skrev: I tried this today and got a javac error compiling a Java2D demo - as report to the build-infra list. You are building a closed demo. The fix that written by Alan 2 weeks ago: Java2Demo breaks build, incompatible method in the same class has not been integrated into build-infra closed yet. Is there a flag to disable building this? I just grabbed a fresh clone of open and closed build-infra repos to try. Or should I remove the closed repos for now? Thanks, David //Fredrik
Re: Review Request: Build-infra M1
On 3/22/12 5:34 PM, Fredrik Öhrström wrote: I know, but the benefit of having the configure script executable in the repo is tremendous, so the extra hassle is worth it. In particular if you want to use builddeps to bootstrap the build environment on for example a Solaris machine. Not to mention the care and feeding of build bots running Windows, where running autoreconf just-in-time before starting the build process could be a lengthy text adventure ... ;) cheers, dalibor topic -- Oracle http://www.oracle.com Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
Re: Review Request: Build-infra M1
A few specific comments ... On 23/03/2012 2:34 AM, Fredrik Öhrström wrote: - ahug...@redhat.com skrev: What is this builddeps server? Is it something that's worth emulating elsewhere? snip This feature to easily acquire the build dependencies is very useful for us, since it makes it easy to have the same compiler on all developer/build-server platforms. You can easily build the exact same bits on your desktop, as is built on the build-farm, since you use the exact same compiler. The old makefiles uses an nfs-mount (/java) to store the builddeps, which unfortunately prevents non-networked builds. The old makefiles use NFS mounted paths by default but you can of course override them for your local environment - that is what the ALT_* variables are for. In the new build you would simply define the non-default paths once as part of the configure process. Not wanting to go too OT here but I see the build-deps server as something to be used at most per machine rather than per developer. We have build servers internally that can be used by dozens of developers and we don't want multiple copies of toolsets. Even in the new build system I would expect to see the toolsets (for cross-compilation) installed on shared NFS mounts for use by these build servers. But at worse I would expect to have one installation per machine. It's not clear to me why it's a good idea to remove traces of the 'closed' JDK from the makefiles. Wouldn't this only cause more divergence and mean that the core OpenJDK makefiles aren't being tested as much? Not at all, we strive to have all makefiles in the open. We build entirely based on the OpenJDK makefiles, in fact I do not think there are any closed makefiles. The hacks needed to insert closed code are arbitrary and visible inside the OpenJDK makefiles. We simply believe that a better solution can be found. I firmly believe that openjdk build files should only contain instructions for building openjdk source code. The alt-src mechanism is a simple mechanism to let us override an open source file with a closed one. This mechanism is available to anyone who wants to customize their OpenJDK without hacking the main OpenJDK sources. However we also have a number of build files that relate only to building things outside the openjdk repositories - eg the Release-embedded.gmk and Defs-embedded.gmk files for our SE Embedded product. This are in the openjdk repository for our convenience. My mission is to move all such build information out of the openjdk into our closed repositories where it belongs. I previously started an email thread on this: http://mail.openjdk.java.net/pipermail/build-dev/2012-January/005383.html Unfortunately while we have a make/closed repository in the JDK repo it isn't used much; and it doesn't exist at all for hotspot. So the task is non-trivial. I also wanted to avoid doing the work twice and so have been waiting/watching this build-infra work. But I'm unclear how I would go about this separation in the build-infra world (mainly because the files I mention above have yet to be converted :) ). Yes! That is the intent, a standard way of building that everyone recognizes. That's a somewhat biased definition of everyone ;-) It's been 12 years since I've had to work with autoconf etc and I don't miss it. :) The configure script is generated using the autoconf tool and is pieced together by the insertion and expansion of various m4 macros. To change it, you alter configure.ac and then run autoconf. This was the focus of my last question, as having configure checked into the repository means that everyone has to be using the same autoconf to generate, to avoid superfluous changes. I know, but the benefit of having the configure script executable in the repo is tremendous, so the extra hassle is worth it. In particular if you want to use builddeps to bootstrap the build environment on for example a Solaris machine. My concern, hence my question about needing to read/understand this file, is what happens if it doesn't work on a system? How do we debug the issue? Sure we can just run autoconf to generate a new (and hopefully working) version, but how do we determine what needs to get checked back into the repo? Cheers, David //Fredrik
Re: Review Request: Build-infra M1
On 22/03/2012 21:21, Fredrik Öhrström wrote: Yes, of course, I just pushed a fix. Thanks, I just wanted to check as it is the webrev. Have you changed the class analyzer to output a text file with the mapping of the sources? e.g. java/lang/Object.java jdk.base/java/langObject.java We should probably move this part of the discussion to jigsaw-dev but we do want to get to the point soon where the class analyzer isn't run as part of the build. -Alan
Review Request: Build-infra M1
As outlined in [1], the build-infra project would like to push the current work into jdk8 in order to expose it to a wider audience. The webrevs are made against the jdk8/build forest. In each repository, there are two kinds of changes: 1. Changes to old makefiles and source code to be compatible with the new build. 2. The new makefiles For corba, jaxp and jaxws, all changes of category 1 have already gone in. For langtools, we are awaiting one more change for introducing the GenerateNativeHeader annotation. For hotspot, all necessary changes have been pushed into hotspot-rt. For jdk, there are two webrevs, one with everything and one with just the category 1 changes, to make it easier to see them. Finally for the root repository there are only new files in the common subdir. root, configure script and makefiles: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-root-new/ langtools, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-new/ langtools, GenerateNativeHeader annotation (this is already going in through tools, but adding it here for reference as the jdk changes depend on it) http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-langtools-nativeheader/ corba, 1 new makefile: http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-corba-new/ jaxp, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxp-new/ jaxws, 1 new makefile http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jaxws-new/ jdk, just the changes to old files http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/ jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Of course, if you prefer you can look at the new makefiles directly in the build-infra/jdk8 repository forest too. These changes should not affect the old build at all. To build using the new build system, change directory to "common/makefiles" and: ../autoconf/configure make (make images) State of the new build (the old build should of course be unaffected): Linux 32bit: Works Linux 64bit: Works Windows 32bit: Works Windows 64bit: Works Solaris i586: Builds but launchers currently unusable Some notes: The old and new build (on linux x64) produce very close to equal results. There is a comparison script in common/bin/compareimage.sh with which this can be checked. Not all makefiles in jdk have been converted yet, for those that haven't been, a copy of the old files are used. Not all promised features in the java compilation are active and ready in this milestone. Most notably, it's still not using more than one cpu and the nifty new dependency tracking is disabled. A clean build is still pretty fast, but incremental builds aren't as good as they will be yet. On windows, only cygwin is currently supported. Now please share your feedback! /Erik [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2012-March/000571.html
Re: Review Request: Build-infra M1
2012-03-21 16:43, Andrew Hughes skrev: I haven't tried this out yet, but I'll try and give it a spin in build-infra. One thing that did stand out from the patch is that generated files such as configure are being checked in. For updates to this, is there a plan to mandate the use of a specific version of autoconf? Otherwise, we're going to get changes simply because someone generated the file using a different version. Alternatively, we could just require that the user has autoconf installed and runs it prior to configure. The configure script must be checked in. Until now, we have used different autoconf versions (2.61 or later), depending on which platform we have update the configure script. The mac has one version, my workstation another etc etc. You are right that in the future we will have to standardize on a specific version, and even mandate a commit check in hg for it. //Fredrik
