Re: RFR [9] : get_source.sh should be more friendly to MQ
Chris Hegarty (chris.hega...@oracle.com) wrote:
On 11/04/14 15:59, Jonathan Gibbons wrote:
Popping all patches beforehand is reasonable, but afterwards, it would
be better to reset to the patches that were previously applied than to
try and push all of them.
Michael as requested same.
What is the behavior if you cannot qpush patches after the pull, because
of merge issues?
The parts of the specific patch that applied cleanly remain applied,
them that did not are written out to reject files to be analyzed. The
remainder of the patches in that repository are not applied. get_source
will then exit with an appropriate error exit code and you can take action.
[Sorry for resurrecting this thread, I just became aware of it--was not
subscribed.]
My workflow relies heavily on mq and (IMHO, of course) reject files
are needless tedium. So I depend heavily on rebase. In order to
avoid reject files when pulling, I do:
hg qpush -a # push everything
hg pull --rebase# pull and rebase in one step, will
# invoke merge tools if necessary
hg qpop some_patch# optional
If you omit the 'hg qpush -a' before pulling, it becomes tedious
(sometimes impossible) to get your merge tools invoked when you later
want to push the patches.
-John
On 04/11/2014 07:58 AM, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone $@ || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2/dev/null`
+
+# Pop all patches, if any, before updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpop.
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpush.
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
--
John CoomesOracle, MS USCA22-3??
john.coo...@oracle.com 4220 Network Circle
408-276-7048 Santa Clara, CA 95054-1778
*** Support GreenPeace and we'll all breathe easier. ***
Re: RFR [9] : get_source.sh should be more friendly to MQ
Mike Duigou (mike.dui...@oracle.com) wrote:
On Apr 11 2014, at 12:06 , Chris Hegarty chris.hega...@oracle.com wrote:
On 11 Apr 2014, at 18:55, Mike Duigou mike.dui...@oracle.com wrote:
Have you looked at using rebase?
I have not, in any detail.
I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Yes, this may work. I was just looking for a single command to active this.
Maybe this combination could be baked into get_source.sh if patch
repositories exist, and we can verify the existence of the rebase extension
( rather than my previous proposal ) ?
I have contemplated adding this as an alternative to the pull -u step in
get_source.sh but wasn't others would agree. Some people hate rebase.
We can detect whether rebase is enabled via :
hg showconfig extensions | grep ^extension.rebase | wc -l
Play with this approach manually and see if it works for you. If it does then
we can consider enhancing get_source.sh
'hg pull --rebase' is the equivalent of pull + update + rebase, and
you should already be able to run 'hgforest.sh pull --rebase'
(although I haven't tried it).
I'd be wary of trying to run rebase automatically, without an
indication that's what the user wants.
-John
-Chris.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty chris.hega...@oracle.com wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically. If
you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone $@ || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2/dev/null`
+
+# Pop all patches, if any, before updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpop.
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpush.
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
--
John CoomesOracle, MS USCA22-3??
john.coo...@oracle.com 4220 Network Circle
408-276-7048 Santa Clara, CA 95054-1778
*** Support GreenPeace and we'll all breathe easier. ***
Re: RFR [9] : get_source.sh should be more friendly to MQ
Jonathan Gibbons (jonathan.gibb...@oracle.com) wrote:
Could we do the same with the trees extension?
You can do it now with:
hg tpull --rebase
(As mentioned in my other message, I always precede the above with
'hg qpush -a' to avoid reject files.)
-John
On 04/11/2014 10:55 AM, Mike Duigou wrote:
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty chris.hega...@oracle.com wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically. If
you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone $@ || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2/dev/null`
+
+# Pop all patches, if any, before updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpop.
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ ${patchdirs} != ] ; then
+ echo Found queue repository, qpush.
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
--
John CoomesOracle, MS USCA22-3??
john.coo...@oracle.com 4220 Network Circle
408-276-7048 Santa Clara, CA 95054-1778
*** Support GreenPeace and we'll all breathe easier. ***
Re: RFR 8030011: Update Hotspot version string output
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote: ... I think I incorporated all the changes David, John and you suggested and started some sanity testing; Here's is the latest webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Please review (don't forget to refresh each file on your browser) and let me know if I missed anything. thanks guys! Looks good. Might be nice to shorten the rest of the assert messages in vm_version.cpp to match the one for the build number, e.g., bad major version). -John
Re: RFR 8030011: Update Hotspot version string output
Alejandro E Murillo (alejandro.muri...@oracle.com) wrote:
Please review this change to make the hotspot related output produced by
java -version
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Generally looks good, but I agree with David that the long lines
should be wrapped, and it might even be clearer to separate them into
two variables, e.g.,
JDK_VERSION_DEFS = -DJDK_MAJOR_VERSION=\$(JDK_MAJOR_VERSION)\ \
-DJDK_MINOR_VERSION=\$(JDK_MINOR_VERSION)\ \
... other defs ...
VERSION_DEFS = -DHOTSPOT_RELEASE_VERSION=\$(HS_BUILD_VER)\ \
-DJRE_RELEASE_VERSION=\$(JRE_RELEASE_VER)\ \
$(JDK_VERSION_DEFS)
Also the change to this part of vm.make differs between at least the
solaris version and the linux version (didn't check bsd or windows).
Please make them all consistent.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
I like the additional error checking. I think you could eliminate the
4 copies of similar code with a function that does the checks and sets
the field, e.g.,
void set_version_field(int * version_field, const char * version_str,
const char * const assert_msg) {
if (version_str != NULL ...) {
DEBUG_ONLY(assert_digits(version_str, assert_msg));
*version_field = atoi(version_str);
}
}
-John
Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit
Tao Mao (tao@oracle.com) wrote: The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ This looks good to me. -John
review request - 7196361 add hotspot/make/closed to hgforest.sh
Please review this small change to keep the script in sync with the
forest structure.
webrev:
http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/
inline diff:
diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh
--- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700
+++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700
@@ -60,3 +60,3 @@
if [ ${pull_extra_base} != ] ; then
-subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/src/closed hotspot/test/closed deploy install sponsors pubs
+subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install
sponsors pubs
pull_default_tail=`echo ${pull_default} | sed -e
's@^.*://[^/]*/\(.*\)@\1@'`
-John
Re: review request - 7196361 add hotspot/make/closed to hgforest.sh
Chris Hegarty (chris.hega...@oracle.com) wrote:
+1
Thanks Chris. Apologies for not including you in the cset comment; I
committed the cset and started the push before getting your message.
-John
On 05/09/2012 20:40, Kelly O'Hair wrote:
Looks fine to me.
-kto
On Sep 5, 2012, at 12:08 PM, John Coomes wrote:
Please review this small change to keep the script in sync with the
forest structure.
webrev:
http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/
inline diff:
diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh
--- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700
+++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700
@@ -60,3 +60,3 @@
if [ ${pull_extra_base} != ] ; then
-subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/src/closed hotspot/test/closed deploy install sponsors pubs
+subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install
sponsors pubs
pull_default_tail=`echo ${pull_default} | sed -e
's@^.*://[^/]*/\(.*\)@\1@'`
-John
Re: review request - 7196361 add hotspot/make/closed to hgforest.sh
Kelly O'Hair (kelly.oh...@oracle.com) wrote:
Looks fine to me.
Thanks Kelly.
-John
On Sep 5, 2012, at 12:08 PM, John Coomes wrote:
Please review this small change to keep the script in sync with the
forest structure.
webrev:
http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/
inline diff:
diff -r d5e73011bde2 -r e177daf578bd make/scripts/hgforest.sh
--- a/make/scripts/hgforest.sh Thu Aug 30 10:26:55 2012 -0700
+++ b/make/scripts/hgforest.sh Wed Sep 05 11:51:52 2012 -0700
@@ -60,3 +60,3 @@
if [ ${pull_extra_base} != ] ; then
-subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/src/closed hotspot/test/closed deploy install sponsors pubs
+subrepos_extra=jdk/src/closed jdk/make/closed jdk/test/closed
hotspot/make/closed hotspot/src/closed hotspot/test/closed deploy install
sponsors pubs
pull_default_tail=`echo ${pull_default} | sed -e
's@^.*://[^/]*/\(.*\)@\1@'`
-John
Re: Round two - RFR (7152336): Enable OpenJDK builds on Windows with MinGW/MSYS
Tim Bell (tim.b...@oracle.com) wrote: I went over the open changes again and removed some debug code left in by mistake, updated copyright dates and fixed a few typos. Here is an updated webrev: http://cr.openjdk.java.net/~tbell/7152336/webrev.01/ These changes are building in both 32 and 64 bit mode on my Windows 7 system. jtreg test runs of the '-automatic -noshell' tests under test/java/lang test/java/math test/java/util ran as expected (2 failures, both known bugs). I only looked at the hotspot changes, which are fine. One minor request. In hotspot/make/windows/makefiles/defs.make: 215 else 216 ifeq ($(USING_MINGW), true) 217 ABS_OUTPUTDIR := $(shell $(CD) $(OUTPUTDIR);$(PWD)) 218 ABS_BOOTDIR := $(shell $(CD) $(BOOTDIR);$(PWD)) 219 ABS_GAMMADIR:= $(shell $(CD) $(GAMMADIR);$(PWD)) 220 ABS_OS_MAKEFILE := $(shell $(CD) $(HS_MAKE_DIR)/$(OSNAME);$(PWD))/build.make 221 else You can append line 216 to 215, e.g., 215 else ifeq ($(USING_MINGW), true) which eliminates some indentation and an endif, and I find easier to read. -John Thanks in advance for your review and feedback - I'd like to get these changes in soon. Tim Bell On 06/13/12 22:31, Tim Bell wrote: Hello everyone- Kelly asked me to pick up on bug #/7152336 //Enable builds on Windows with MinGW/MSYS/, and this email thread: http://mail.openjdk.java.net/pipermail/build-dev/2012-April/thread.html#6083 As David pointed out, we will need at least one other bug # for the hotspot changes. That said, this is enough to get me started. Hi Volker: I have applied the patches originally from your posting. Many thanks for that: http://cr.openjdk.java.net/~simonis/MinGW_MSYS.v1/ With a few modifications (keep cpio for non MinGW/Msys builds, keep MKS as an option), the proposed changes are visible here for review: http://cr.openjdk.java.net/~tbell/7152336/webrev.00/ For reference, my test build log is visible here: http://cr.openjdk.java.net/~tbell/7152336/webrev.00/full_control_build_no_docs.log Additional test builds on JPRT (our internal build apparatus) verified that I didn't regress the existing build. Abbreviated jtreg [1] testing on this build was successful: $ /d/tools/jdk8/7152336/windows-i586/bin/java -jar /d/tools/jtreg-internal/jtreg/lib/jtreg.jar -automatic -noshell test/java/lang test/java/math test/java/util Directory JTreport not found: creating Directory JTwork not found: creating Directory JTwork\scratch not found: creating Test results: passed: 698; failed: 1; error: 5 Report written to D:\tools\jdk8\7152336\jdk\JTreport\html\report.html Results written to D:\tools\jdk8\7152336\jdk\JTwork Error: Some tests failed or other problems occurred. The failing test (java/lang/Math/WorstCaseTests.java) is due to a known regression: 7174532 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7174532 jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 The 5 error tests are all ignored until bug xxx (for some value of x) is resolved. Thanks in advance for your review and feedback - Tim Bell [1] http://openjdk.java.net/projects/code-tools/
Re: Building OpenJDK 6 on Solaris sparc
Weiqi Gao (weiqi...@gmail.com) wrote: Hi, I'm trying to build OpenJDK 6 and OpenJDK 7 on a variety of machines. I have encountered the following error while building OpenJDK 7 (http://hg.openjdk.java.net/jdk7/jdk7) on Solaris sparc (SunOS cicada2 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Blade-1000). I'm using the suncc5.10 compiler and the lasted jdk1.6.0_32 from Oracle as the bootstrap JDK. I'm not sure what's the cause of this problem. Can anyone shed some light on it? rm -f copy.o CC -DSOLARIS -DSPARC_WORKS -DSPARC -DPRODUCT -xF ... cg: assertion failed in file ../src/sparc/block_edges.cc at line 581 cg: block_edges.accumulate_successors: bad state cg: 1 errors Hi, That's a bug in the compiler backend. Make sure you have applied the patches listed in the README-builds.html file: http://hg.openjdk.java.net/jdk7/jdk7/raw-file/dada8003df87/README-builds.html#studio -John
Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable
Erik Joelsson (erik.joels...@oracle.com) wrote: New webrev: http://cr.openjdk.java.net/~erikj/7141244/webrev.02/ http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.02/ 177 lines changed: 89 ins; 29 del; 59 mod; 3970 unchg Changes since last time: * Moved the , to after $(SPEC) * Changed comment in gcc/sparcWorks.make according to suggestion from Fredrik. Looks good. One minor request: in linux/makefiles/gcc.make, you moved the setting of STRIP under the SPEC conditional. Might as well fold it into the CROSS_COMPILE_ARCH conditional that's already there. -John On 2012-02-09 10:09, Erik Joelsson wrote: On 2012-02-09 03:51, David Holmes wrote: make/defs.make: + ifneq (,$(SPEC)) + include $(SPEC) + endif Having the blank first looks odd. I assume you aren't using -inlcude because you want to see errors if SPEC is set but not found. I guess it's an unconscious habit from java where you rather do .equals(something) to avoid NPE. I will switch it around. And the assumption is correct. We used -include at first, but I figured that we wanted to know if the include failed at least on the root level Makefile. make/windows/makefiles/compile.make: The definitions of MT=mt.exe in each block for the different VS versions seems redundant. If we factor this out is there any reason not to group: CXX=cl.exe MT=mt.exe RC=rc.exe LD=link.exe together and use the same if (,$(SPEC)) approach? Grouping them together would certainly look nicer, but MT isn't set for every possible compiler version. Not sure if that matters since we don't support older versions anyway, right? As for testing for SPEC, this is nmake and the SPEC file is only gnumake compatible. CXX, MT, RC and LD are sent in to nmake on the command line from gnumake. They are then generated into local.make which is in turn included by sub invocations of nmake. Sending in SPEC as well seemed redundant to me, but we could send it in as a flag signaling that configure should be in control. Wouldn't look obviously better to me though. I'm open for suggestions. /Erik
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: RFR: 7133124 Remove redundant packages from JAR command line
Dmitry Samersoff (dmitry.samers...@oracle.com) wrote: Kelly, The serialize checkins issue can be minimized some by using distributed SCMs (Mercurial, Git, etc) We have chosen a model: build-test-integrate but we may consider different approach: integrate-build-test-[backout if necessary] In that model, you can never rely on the repository having any degree of stability. It may not even build at a given moment. Developer (A) integrate his changeset to an integration workspace Bot takes snapshot and start building/testing Developer (B) integrate his changeset to an integration workspace Bot takes snapshot and start building/testing if Job A failed, bot lock integration ws, restore it to pre-A state, apply B-patch. unlock ws. Don't forget the trusting souls that pulled from the integration repo after A inflicted the breakage: they each waste time cleaning up a copy of A's mess. -John On 2012-01-29 23:52, Kelly O'Hair wrote: On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: I'm missing something. How can everybody using the exact same system scale to 100's of developers? System = distributed build and test of OpenJDK Ah ha... I'm down in the trenches dealing with dozens of different OS's arch's variation machines. You are speaking to a higher level, I need to crawl out of the basement. Developers send in jobs Jobs are distribute across a pool of (HW/OS) resources The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress) The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage No assumptions made about what exists on the machine other than HW/OS The build and test tasks are self sufficient, i.e. bootstrap themselves The bootstrapping is done in the same way for different build and test tasks Understood. We have talked about this before. I have also been on the search for the Holy Grail. ;^) This is why I keep working on JPRT. The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter) The serialize checkins issue can be minimized some by using distributed SCMs (Mercurial, Git, etc) and using separate forests (fewer developers per source repository means fewer merge/sync issues) and having an integrator merge into a master. This has proven to work in many situations but it also creates delivery to master delays, especially if the integration process is too heavyweight. The JDK projects has been doing this for a long time, I'm sure many people have opinions as to how successful it is or isn't. It is my opinion that merges/syncs are some of the most dangerous things you can do to a source base, and anything we can do to avoid them is usually goodness, I don't think you should scale this without some very great care. And that one system will naturally change over time too, so unless you are able to prevent all change to a system (impossible with security updates etc) every use of that 'same system' will be different. Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm. Possible but not always easy. The auto updating of everything has increased significantly over the years, making it harder to control completely. I've been doing this buildtest stuff long enough to never expect anything to be 100% reliable. Hardware fails, software updates regress functionality, networks become unreliable, humans trip over power cords, virus scanners break things, etc. It just happens, and often, it's not very predictable or reproducible. You can do lots of things to minimize issues, but at some point you just have to accept a few risks because the alternative just isn't feasible or just can't happen with the resources we have. -kto -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ...
Re: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds
David Holmes (david.hol...@oracle.com) wrote: Okay now that my brain is functioning again lets see if it is third-time lucky: http://cr.openjdk.java.net/~dholmes/7036525/webrev.2/ This reverts things back to my original webrev where we set HS_ALT_SRC_REL to NO_SUCH_PATH. It has to be a non-existent path otherwise it will appear in the generated definitions for Src_Dirs_I and Src_Dirs_V. The user can override this by setting OPENJDK=true and HS_ALT_SRC_REL=whatever as variables on the make invocation eg: gmake OPENJDK=true HS_ALT_SRC_REL=/my/dist/src product1 Sure, looks good to me. -John
Re: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds
David Holmes (david.hol...@oracle.com) wrote: John Coomes said the following on 05/04/11 02:37: David Holmes (david.hol...@oracle.com) wrote: I've just made the change as John suggested and to be honest I don't know why I didn't think of that myself. I do see your point though, by setting it the same the build will always use the ALT_SRC in the OpenJDK case - but this will be fine because it is the same as COMMON_SRC. This is only used to generate the Makefiles during the buildtree phase so I don't think it is really a concern either way. FWIW, I prefer the change you've made, but don't feel that strongly about it. To be honest I'm doubting the whole rationale for this change as it means that an OPENJDK build will never use the alt-src mechanism, when according to the comments alt-src was also intended to be used by others for introducing alternative code into their builds/distributions. In those cases you may well want both alt-src and OPENJDK (given that OPENJDK could be being set at the top-level JDK makefile). IMHO, better if an OPENJDK build doesn't use alt-src, at least by default. And I suspect you can override HS_ALT_SRC_REL from the gmake command line, even when OPENJDK==true (haven't tried it, though). No. Unless you use -e a variable's value from the environment will be overridden by an explicit assignment in the Makefile. ... True about the environment, but I meant this: gmake product OPENJDK=true HS_ALT_SRC_REL=my_impl which will override the assignment within the make file (http://www.gnu.org/s/hello/manual/make/Overriding.html#Overriding). ... Which means that the better fix here is: + 36 ifndef HS_ALT_SRC_REL 37 ifneq ($(OPENJDK),true) 38 # This needs to be changed to a more generic location, but we keep it as this 39 # for now for compatibility 40 41 HS_ALT_SRC_REL=src/closed 42 else 43 HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL) 44 endif + 45 endif This version treats HS_ALT_SRC_REL differently from other vars, in that a value from the environment overrides the assignment in the makefile, even without the -e option to gmake. -John
Re: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds
David Holmes (david.hol...@oracle.com) wrote: Hi John, Fresh webrev at: http://cr.openjdk.java.net/~dholmes/7036525/webrev.1/ Looks good to me. -John David Holmes said the following on 04/30/11 10:09: Thanks John. Currently sitting here shaking my head is disbelief. I'll try this again. David John Coomes said the following on 04/30/11 03:47: David Holmes (david.hol...@oracle.com) wrote: http://cr.openjdk.java.net/~dholmes/7036525/webrev/ Simple but crude. If OPENJDK is defined then the Hotspot alternative source mechanism is effectively disabled by checking for a non-existent path. This allows people using the alt-src mechanism to select which type of build they want in a way that is consistent with how builds of OPENJDK are done in the rest of the JDK. Tested by checking the errorReporter.cpp location in builds with/without OPENJDK set, and with/without src/closed present. This will be pushed into hotspot-rt/hotspot for hs21-b11 Hi David, 38 ifneq ($(OPENJDK),true) 39 HS_ALT_SRC_REL=src/closed 40 else 41 HS_ALT_SRC=NO_SUCH_PATH 42 endif 43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL) 44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL) The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets HS_ALT_SRC (no *REL*), and that is overwritten on line 44. I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/, but I doubt that was intended. You could change line 41 to HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL) Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have to rely on NO_SUCH_PATH. -John
Re: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds
David Holmes (david.hol...@oracle.com) wrote: Hi Keith, Keith McGuigan said the following on 05/03/11 02:13: On Apr 29, 2011, at 1:47 PM, John Coomes wrote: David Holmes (david.hol...@oracle.com) wrote: http://cr.openjdk.java.net/~dholmes/7036525/webrev/ Simple but crude. If OPENJDK is defined then the Hotspot alternative source mechanism is effectively disabled by checking for a non-existent path. This allows people using the alt-src mechanism to select which type of build they want in a way that is consistent with how builds of OPENJDK are done in the rest of the JDK. Tested by checking the errorReporter.cpp location in builds with/without OPENJDK set, and with/without src/closed present. This will be pushed into hotspot-rt/hotspot for hs21-b11 Hi David, 38 ifneq ($(OPENJDK),true) 39 HS_ALT_SRC_REL=src/closed 40 else 41 HS_ALT_SRC=NO_SUCH_PATH 42 endif 43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL) 44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL) The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets HS_ALT_SRC (no *REL*), and that is overwritten on line 44. I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/, but I doubt that was intended. You could change line 41 to HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL) Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have to rely on NO_SUCH_PATH. I'd prefer to leave it as NO_SUCH_PATH. That way tests for the existence of that directory (or files in those directories) will correctly fail and won't mistakenly indicates that alt-srcs exist. I believe there are a number of tests like that already, but I'll bet it currently works fine (unintentionally) if HS_ALT_SRC == HS_COMMON_SRC. I've just made the change as John suggested and to be honest I don't know why I didn't think of that myself. I do see your point though, by setting it the same the build will always use the ALT_SRC in the OpenJDK case - but this will be fine because it is the same as COMMON_SRC. This is only used to generate the Makefiles during the buildtree phase so I don't think it is really a concern either way. FWIW, I prefer the change you've made, but don't feel that strongly about it. To be honest I'm doubting the whole rationale for this change as it means that an OPENJDK build will never use the alt-src mechanism, when according to the comments alt-src was also intended to be used by others for introducing alternative code into their builds/distributions. In those cases you may well want both alt-src and OPENJDK (given that OPENJDK could be being set at the top-level JDK makefile). IMHO, better if an OPENJDK build doesn't use alt-src, at least by default. And I suspect you can override HS_ALT_SRC_REL from the gmake command line, even when OPENJDK==true (haven't tried it, though). -John
Re: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds
David Holmes (david.hol...@oracle.com) wrote: http://cr.openjdk.java.net/~dholmes/7036525/webrev/ Simple but crude. If OPENJDK is defined then the Hotspot alternative source mechanism is effectively disabled by checking for a non-existent path. This allows people using the alt-src mechanism to select which type of build they want in a way that is consistent with how builds of OPENJDK are done in the rest of the JDK. Tested by checking the errorReporter.cpp location in builds with/without OPENJDK set, and with/without src/closed present. This will be pushed into hotspot-rt/hotspot for hs21-b11 Hi David, 38 ifneq ($(OPENJDK),true) 39 HS_ALT_SRC_REL=src/closed 40 else 41 HS_ALT_SRC=NO_SUCH_PATH 42 endif 43 HS_COMMON_SRC=$(GAMMADIR)/$(HS_COMMON_SRC_REL) 44 HS_ALT_SRC=$(GAMMADIR)/$(HS_ALT_SRC_REL) The 'if' block sets HS_ALT_SRC_*REL*, but the else block sets HS_ALT_SRC (no *REL*), and that is overwritten on line 44. I think it works because after line 44, HS_ALT_SRC == $(GAMMADIR)/, but I doubt that was intended. You could change line 41 to HS_ALT_SRC_REL=$(HS_COMMON_SRC_REL) Then when OPENJDK=true, HS_ALT_SRC==HS_COMMON_SRC, and you don't have to rely on NO_SUCH_PATH. -John
(Fwd) review request (S): 7037250 cscope.make is silently broken
Mea culpa, forgot to ask for permission, so am asking for forgiveness instead. This makefile change has been pushed to the hotspot-gc repo. It has no effect on the product, simply fixes cscope database generation. -John --- start of forwarded message --- From: John Coomes john.coo...@oracle.com To: hotspot-gc-...@openjdk.java.net Subject: review request (S): 7037250 cscope.make is silently broken Date: Sat, 16 Apr 2011 13:38:45 -0700 I'd appreciate reviews the fix for 7037250: cscope.make database generation is silently broken I recently resumed using cscope and found cscope.make was rather broken. Details are in the webrev: http://cr.openjdk.java.net/~jcoomes/7037250-cscope/ Thanks for any comments. -John --- end of forwarded message ---
Re: Need reviewer: change sanity check on make 3.81
Kelly O'Hair (kelly.oh...@oracle.com) wrote: Need reviewer: change sanity check on make 3.81 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Use of gnu make 3.81 or newer is required now, which should be readily available on all platforms. I recommend a big heads-up. The solaris gnumake versions in /java/devtools are 3.78.1 (can someone update them?), and solaris 10 ships with 3.80. -John The patch is rather trivial: diff --git a/make/common/shared/Sanity.gmk b/make/common/shared/ Sanity.gmk --- a/make/common/shared/Sanity.gmk +++ b/make/common/shared/Sanity.gmk @@ -255,10 +255,10 @@ MAKE_CHECK :=$(call CheckVersions,$(MAKE_VER),$(REQUIRED_MAKE_VER)) sane-make: @if [ $(MAKE_CHECK) != same -a $(MAKE_CHECK) != newer ]; then \ - $(ECHO) WARNING: The version of make being used is older than \n \ + $(ECHO) ERROR: The version of make being used is older than \n \ the required version of '$(REQUIRED_MAKE_VER)'. \n \ The version of make found was '$(MAKE_VER)'. \n \ - $(WARNING_FILE) ; \ + $(ERROR_FILE) ; \ fi ## -kto
Re: Need reviewer: NONFCS_BUILD_INFO to add to the non-fcs version string
Kelly O'Hair (kelly.oh...@oracle.com) wrote: Dang... just shoot me now. :^( Try this: http://cr.openjdk.java.net/~ohair/openjdk7/nonfcs-version/webrev/ Sorry about that. Aren't we using the term GA (general availability) instead of FCS these days? Aside from that, looks fine. -John On Nov 24, 2010, at 11:28 AM, Mark Wielaard wrote: On Wed, 2010-11-24 at 11:19 -0800, Kelly O'Hair wrote: I need a reviewer for this change: 6987107: Add NONFCS_BUILD_INFO variable to add to but not modify MILESTONE in version string http://javaweb.sfbay.sun.com/~ohair/webrevs/jdk7/nonfcs-version/webrev/ Bit hard to review if the host isn't reachable :) Could you just attach the patch to your email, or post it on some publicly reachable machine? Thanks, Mark
Re: Recommended GCC version?
Mario Torre ([EMAIL PROTECTED]) wrote: Il giorno lun, 31/03/2008 alle 18.37 +0200, Clemens Eisserer ha scritto: Hello, I wonder which version of GCC is recommended for building OpenJDK? 4.3 will probably not work out-of-the-box, should I downgrade to 4.2 or 4.1? ... Thanks a lot, lg Clemens I had to steal a couple of patches from icedtea to be able to build hotspot with gcc 4-3, works fine otherwise. FWIW, the fix for 6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk 6 went into the hotspot runtime repository a few days ago: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f139919897d2 It should make its way up to jdk7/jdk7/hotspot fairly soon for jdk7 build 30 or 31. I expect that will allow hotspot to build on current linux distros, but I haven't tried yet. -John
jdk7/hotspot-gc/hotspot: 9876543 make gc better
Changeset: e44754018a19 Author:jcoomes Date: 2007-11-14 16:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e44754018a19 9876543 make gc better ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
jdk7/hotspot-gc/hotspot: 9876543 make gc better (fix comment)
Changeset: 98a807091399 Author:jcoomes Date: 2007-11-14 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/98a807091399 9876543 make gc better (fix comment) ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
