hg: jdk8/build/jdk: 2 new changesets
Changeset: 88597d465e48 Author:ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author:erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk
Re: JDK 8 RFR: JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build
That sounds good to me. /Erik On 2013-10-04 01:00, Joseph Darcy wrote: Some of the fixes I need are in the TL repo, some are in awt. If I can't arrange for the full set of fixes to be in the same repo soon, I plan to push just the "try" fix now and then "auxiliaryclass" and "empty" once the fixes propagate. (There is a hazard of new instances of problem popping up in the interim so I'd prefer to get new lint categories enabled as soon as possible.) Thanks, -Joe On 10/2/2013 1:17 AM, Erik Joelsson wrote: The change looks ok. Pushing it through JPRT sounds like a good idea. /Erik On 2013-10-02 01:22, Joe Darcy wrote: Hello, As a follow-up to JDK-8024643 "Turn on javac lint checking in building the jdk repo", the time approaches to enable a few more lint warnings in the build of the jdk repo: JDK-8024603 Turn on javac lint checking for auxiliaryclass and empty in jdk build http://cr.openjdk.java.net/~darcy/8024603.0/ The webrev above and patch below adds the "auxiliaryclass", "empty", and "try" categories: --- old/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700 +++ new/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700 @@ -27,7 +27,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 1" -JAVAC_WARNINGS:=-Xlint:-unchecked,-deprecation,-overrides,classfile,dep-ann,divzero,varargs -Werror +JAVAC_WARNINGS:=-Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,classfile,dep-ann,divzero,empty,try,varargs -Werror # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. The bugs blocking these categories are fixed or out for review. Please review the change; it would only be pushed on a successful full jprt run. Thanks, -Joe
Re: JDK7u40: build issue with a french VS2010 Express
On 3/10/2013 10:56 PM, Francis ANDRE wrote:
Hi
In the 7u40/jdk/make/common/shared/Compiler-msvc.gmk, the code for
computing the CC_VER does work with a French VS2010 Express compiler
CC_VER := $(shell $(CC) 2>&1 | $(HEAD) -n 1 | $(SED)
's/.*\(Version.*\)/\1/' | $(NAWK) '{print $$2}')
because the cl command returns
Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version
16.00.30319.01 pour 80x86
Copyright (C) Microsoft Corporation. Tous droits réservés.
utilisation : cl [ option... ] nom de fichier... [ /link linkoption... ]
So, soneone from the build team would say: Hey guy, pick up the English
version and it will work!. But that does not work neither because when
one download VS2010 Express from a French territory, one gets the French
version EVEN if the English version was explicitly requested (I made it
twice, thinking I missed to select the English version).
Not sure how the build is supposed to account for all possible languages
used by the toolsets such that it can determine what the version is ??
In other languages the word "version" may not even appear. Doesn't this
compiler have some flag to print the version? (Obviously it didn't in
the past hence the code but maybe it does now?)
The problem has already been solved in the hotspot build by using the
externals variables FORCE_MSC_VER and FORCE_LINK_VERSION in this file
/hotspot/make/windows/get_msc_ver.sh
That doesn't seem an unreasonable approach. As long as there is some way
for people in your situation to make things work.
David
-
I can build a fix for this issue but I think it is better than someone
from the build team fix this issue because of the overall responsibility
of making the build correct on the WXP/VS2010 as well as others
platforms which I do not have.
Francis
Re: hgforest.sh still fails to detect Python
I did get started on this issue finally and have done the regression testing to make sure it works across all of the required platforms. I will finish up the patch in the next couple of weeks. Mike On Sep 11 2013, at 06:48 , Dmitry Samersoff wrote: > Mike, > > hgforest still doesn't detect python because on my linux laptop hg > headline is > > #!/usr/bin/env python > > I'd attached the patch I use (regenerated against latest tl with 8024200 > changes) > > -Dmitry > > On 2013-09-03 23:43, Mike Duigou wrote: >> Hello all; >> >> This is a very small change to trim optional whitespace off of the >> interpreter directive which may appear in the hg wrapper script. The >> whitespace is legal per https://en.wikipedia.org/wiki/Shebang_%28Unix%29 and >> is now included in some distributions of mercurial (Ubuntu 13.04). >> >> http://cr.openjdk.java.net/~mduigou/JDK-8024200/0/webrev/ >> >> Mike >> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. >
Re: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611)
On 3/10/2013 1:32 AM, Daniel D. Daugherty wrote:
David,
Thanks for the thorough review (as always)!
It will take me a while to process all the comments, but another
reply will be forthcoming.
Don't bother with the minimal VM build attempt, you won't even get
started. The files don't exist for BSD.
David
Dan
On 10/1/13 8:52 PM, David Holmes wrote:
Hi Dan,
Overall thumbs up. A couple of minor issues that need fixing. A few
meta-comments (I hate seeing all this stuff duplicated again and again.
David
-
- common/autoconf/hotspot-spec.gmk.in
Seems a good simplification.
- common/autoconf/jdk-options.m4
No comment.
---
- common/makefiles/NativeCompilation.gmk
So JDK .diz support is phase 2? :)
The Windows changes here seem okay given that on windows a .debuginfo
file should never be in the target list.
---
- hotspot/make/Makefile
+ $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM
EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR.
For fun you can try building minimal on OSX, but I don't know how far
you will get:
--with-jvm-variants=client,server,minimal1
I'll point out obvious issues with minimal VM support anyway.
---
- hotspot/make/bsd/Makefile
No comment.
- hotspot/make/bsd/makefiles/buildtree.make
No comment.
- make/bsd/makefiles/defs.make
Note that the whole jdk6_or_earlier logic is defunct as this will
never be used for jdk6 or earlier. But best to clean all that up at
the one time.
Sadly I never found a satisfactory solution to the multiplicity and
verbosity of the FDS messages, so OSX builds will now be afflicted by
them too.
328 else
329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo
330 endif
This pre-existing minimal VM code needs to be modified to reference
the dSYM directory on OSX as per the client/server cases.
---
- hotspot/make/bsd/makefiles/dtrace.make
Note related to your changes but I don't think any of the "64"
directory stuff has any meaning outside of Solaris.
102 dsymutil $@
I think dsymutil should be assigned to a variable in the platform
defs.make as with other tools.
Would be nice if objcopy/dsymutil could be hidden behind a single
SYM_TOOL variables as well so there wasn't so much duplication of the
process. You could have a single set of instructions to invoke
SYM_TOOL, STRIP and ZIP (strip would be skipped of course because
STRIP_POLICY would never be set on osx). Just wishful thinking ...
---
- hotspot/make/bsd/makefiles/gcc.make
+ FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH))
should be
+ FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH))
Don't we need the USE_CLANG variations here as for linux?
---
- hotspot/make/bsd/makefiles/jsig.make
- hotspot/make/bsd/makefiles/saproc.make
Similar comments to dtrace.make
---
- make/bsd/makefiles/universal.gmk
I did not understand the additional logic here:
63 # Copy built non-universal binaries in place
64 $(UNIVERSAL_COPY_LIST):
65 BUILT_COPY_FILES="`find
$(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@)
2>/dev/null`"; \
66 if [ -n "$${BUILT_COPY_FILES}" ]; then \
67 for i in $${BUILT_COPY_FILES}; do \
68 if [ -f $${i} ]; then \
69 $(MKDIR) -p $(shell dirname $@); \
70 $(CP) -R $${i} $@; \
71 fi; \
72 if [ -d $${i} ]; then \
73 $(MKDIR) -p $@; \
74 fi; \
75 done; \
76 fi
until I realized that foo.dSYM is a directory not a file! Even so
don't you want to copy the contents of the directory across ?
BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM.
---
- make/bsd/makefiles/vm.make
Similar comments to dtrace.make ref dsymutil.
---
- hotspot/make/defs.make
No comment.
---
- jdk/make/common/Defs-macosx.gmk
No comment
- jdk/makefiles/Tools.gmk
Not sure about this one. Logically is seems correct but up to now this
has been defined for everything without it seeming to cause a problem.
So why do we need to change it and what impact will it have?
David
-
On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote:
Greetings,
I have the initial support for Full Debug Symbols (FDS) on MacOS X done
and ready for review:
7165611 implement Full Debug Symbols on MacOS X hotspot
https://bugs.openjdk.java.net/browse/JDK-7165611
Here is the JDK8/HSX-25 webrev URL:
OpenJDK:
http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/
Internal:
http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/
This webrev includes changes for the follow repos:
jdk8
jdk8/hotspot
jdk8/jdk
jdk8/jdk/make/closed
Once these changes are approved, I'm planning to push them to
RT_Baseline. From there, they can follow the normal path to
Main_Baseline and eventually JDK8.
This work enables FDS on MacOS X for the 'hotspot' repo; the changes in
the other repos are necessary to support importing the .diz files from
Re: JDK 8 RFR: JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build
Some of the fixes I need are in the TL repo, some are in awt. If I can't arrange for the full set of fixes to be in the same repo soon, I plan to push just the "try" fix now and then "auxiliaryclass" and "empty" once the fixes propagate. (There is a hazard of new instances of problem popping up in the interim so I'd prefer to get new lint categories enabled as soon as possible.) Thanks, -Joe On 10/2/2013 1:17 AM, Erik Joelsson wrote: The change looks ok. Pushing it through JPRT sounds like a good idea. /Erik On 2013-10-02 01:22, Joe Darcy wrote: Hello, As a follow-up to JDK-8024643 "Turn on javac lint checking in building the jdk repo", the time approaches to enable a few more lint warnings in the build of the jdk repo: JDK-8024603 Turn on javac lint checking for auxiliaryclass and empty in jdk build http://cr.openjdk.java.net/~darcy/8024603.0/ The webrev above and patch below adds the "auxiliaryclass", "empty", and "try" categories: --- old/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700 +++ new/makefiles/Setup.gmk2013-10-01 15:53:23.0 -0700 @@ -27,7 +27,7 @@ # To build with all warnings enabled, do the following: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 1" -JAVAC_WARNINGS:=-Xlint:-unchecked,-deprecation,-overrides,classfile,dep-ann,divzero,varargs -Werror +JAVAC_WARNINGS:=-Xlint:-unchecked,-deprecation,-overrides,auxiliaryclass,classfile,dep-ann,divzero,empty,try,varargs -Werror # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. The bugs blocking these categories are fixed or out for review. Please review the change; it would only be pushed on a successful full jprt run. Thanks, -Joe
RFR: JDK-8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources
Please review this fix for SetupZipArchive. The dependency list ended up empty if the SUFFIXES parameter wasn't set. This caused src.zip to not get updated when source files were changed. http://cr.openjdk.java.net/~erikj/8025869/webrev.root.01/ /Erik
JDK7u40: build issue with a french VS2010 Express
Hi
In the 7u40/jdk/make/common/shared/Compiler-msvc.gmk, the code for computing the
CC_VER does work with a French VS2010 Express compiler
CC_VER := $(shell $(CC) 2>&1 | $(HEAD) -n 1 | $(SED) 's/.*\(Version.*\)/\1/' |
$(NAWK) '{print $$2}')
because the cl command returns
Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version 16.00.30319.01
pour 80x86
Copyright (C) Microsoft Corporation. Tous droits réservés.
utilisation : cl [ option... ] nom de fichier... [ /link linkoption... ]
So, soneone from the build team would say: Hey guy, pick up the English version
and it will work!. But that does not work neither because when one download
VS2010 Express from a French territory, one gets the French version EVEN if the
English version was explicitly requested (I made it twice, thinking I missed to
select the English version).
The problem has already been solved in the hotspot build by using the externals
variables FORCE_MSC_VER and FORCE_LINK_VERSION in this file
/hotspot/make/windows/get_msc_ver.sh
I can build a fix for this issue but I think it is better than someone from the
build team fix this issue because of the overall responsibility of making the
build correct on the WXP/VS2010 as well as others platforms which I do not have.
Francis
Re: RFR: 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK.
Looks good, many thanks for fixing this! Thanks, Christian On Oct 3, 2013, at 5:01, Erik Joelsson wrote: > Please review this simple patch adding /MP to the windows cl.exe command > lines when supported. In my tests, the speed improvement is around 40% on the > hotspot part of the build on the Stockholm jprt queue and my local build. > This is really low hanging fruit for build speed improvements. > > http://cr.openjdk.java.net/~erikj/8007446/webrev.hotspot.01/ > > I will also need a sponsor to push this for me if review is passed. > > /Erik
Re: RFR: 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK.
Looks good! I can sponsor the push. Thanks, /Staffan On 3 okt 2013, at 11:14, Erik Joelsson wrote: > Please review this simple patch adding /MP to the windows cl.exe command > lines when supported. In my tests, the speed improvement is around 40% on the > hotspot part of the build on the Stockholm jprt queue and my local build. > This is really low hanging fruit for build speed improvements. > > http://cr.openjdk.java.net/~erikj/8007446/webrev.hotspot.01/ > > I will also need a sponsor to push this for me if review is passed. > > /Erik > >
RFR: 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK.
Please review this simple patch adding /MP to the windows cl.exe command lines when supported. In my tests, the speed improvement is around 40% on the hotspot part of the build on the Stockholm jprt queue and my local build. This is really low hanging fruit for build speed improvements. http://cr.openjdk.java.net/~erikj/8007446/webrev.hotspot.01/ I will also need a sponsor to push this for me if review is passed. /Erik
