Re: 7140918: Remove dependency on apt and com.sun.mirror API
On 31/01/2012 01:17, David Holmes wrote: : Okay. So as part of this will the new zip file be installed before the change gets pushed? Yes, that's right. -Alan
Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds.
Hello hotspot-runtime-dev and build-dev! This is a patch to enable ccache to work for all builds, not only builds where the build number has been explicitly set. Webrev is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ Exported hg patch is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch Is it good enough, so that you can commit for me Robert? Thanks! //Fredrik
Re: How to handle a merge problem
David Holmes (david.hol...@oracle.com) wrote: On 31/01/2012 2:50 PM, Pete Brunet wrote: ... Or maybe I should start from scratch, apply my patch and fix the issues that way. I seem to remember that the one time I did have a problem applying a patch to fresh clone I was able to fix them. -Pete Might be easiest depending on how many files are in conflict. If you have committed changes and want to sync with the upstream repo, the easiest way is to use the rebase extension (works best in hg 1.6 and later). You have to enable rebase in your .hgrc file, then you can run hg pull --rebase It will invoke your merge tool to resolve conflicts if necessary, and move your changesets to tip. Given that you've already pulled, you can still rebase your changesets so they are at tip, but you have to identify them and provide them on the command line. See 'hg help rebase.' -John On 1/30/12 8:56 PM, David Holmes wrote: Pete, On 31/01/2012 12:45 PM, Pete Brunet wrote: I just did the following: sh ./get_source.sh and got this: snip # cd ./jdk hg pull -u pulling from http://hg.openjdk.java.net/jdk8/jdk8//jdk searching for changes adding changesets adding manifests adding file changes added 563 changesets with 3123 changes to 2661 files (+1 heads) not updating: crosses branches (merge branches or update --check to force update) # exit code 0 This shouldn't be possible. get_source will first clone the repos then do a hg pull (why? Given it just cloned it!) It may be that you were extremely unlucky and between the clone and the pull there was an integration push to the repo. Even so you shouldn't get multiple heads. ??? How do I fix this? I haven't found instructions on the various OpenJDK sites. Delete the jdk repo and start again is all I can suggested to get back to a sane state. David - Pete
Re: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds.
Looks good, but where is the new jre_release_version() method used? /Staffan On 31 jan 2012, at 13:31, Fredrik Öhrström wrote: Hello hotspot-runtime-dev and build-dev! This is a patch to enable ccache to work for all builds, not only builds where the build number has been explicitly set. Webrev is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ Exported hg patch is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch Is it good enough, so that you can commit for me Robert? Thanks! //Fredrik
Re: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds.
On 1/02/2012 5:53 AM, Staffan Larsen wrote: Looks good, but where is the new jre_release_version() method used? It's currently only used in some closed code. The new method avoids the need to make the JRE_RELEASE_VERSION define available to that closed code. I don't understand the comment on the new method though. Not sure what stringstream has to do with this actual method. Otherwise looks good to me. I'm assuming that the actual problem is the ccache compares the defines used for a compilation and so if the version string contains a timestamp and gets updated on each (incremental?) build then ccache thinks it has to recompile. David - /Staffan On 31 jan 2012, at 13:31, Fredrik Öhrström wrote: Hello hotspot-runtime-dev and build-dev! This is a patch to enable ccache to work for all builds, not only builds where the build number has been explicitly set. Webrev is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ Exported hg patch is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch Is it good enough, so that you can commit for me Robert? Thanks! //Fredrik
...\jdk\make\docs\Makefile needs a fix
Back in November there was a change to ...\jdk\make\docs\Makefile to fix an out of memory problem by raising the memory size for a 32 bit build (line 74) from 512 to 612. That didn't work on my machine: 64 bit Windows 7 with 8 mb. I raised it up to 1024 to bypass the problem. I don't know if that's too much but it worked. Pete
