I'd like to make a simple tweak to jdk/test/Makefile in order to support
control over the "-v" verbosity option sent to jtreg.
'langtools/test/Makefile' has supported a similar "JTREG_VERBOSE" variable for
awhile now.
(Would it be nice to align the test-running infrastructure for langtools
Looks fine to me.
-- Kevin
Daniil Titov wrote:
Thank you, Mandy!
The long line is corrected.
Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
http://cr.openjdk.java.net/~dtitov/8156960/webrev.03
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Best regards,
Thank you, Mandy!
The long line is corrected.
Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.03
http://cr.openjdk.java.net/~dtitov/8156960/webrev.03
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Best regards,
Daniil
-Original Message-
From: Mandy
Thank you, Erik!
Please review the new version of the patch that has "../" fixed:
Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.02
http://cr.openjdk.java.net/~dtitov/8156960/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
Best regards,
Daniil
Erik:
This small patch adds the jmod tool itself as a dependency to the
creation of jmods. The effect of this is that changes to the jmod tool
src will trigger a rebuild of all jmods automatically.
Bug: https://bugs.openjdk.java.net/browse/JDK-8144911
Patch:
diff -r 89769a2f1511
Erik:
On 06/09/16 05:23, Alan Bateman wrote:
On 09/06/2016 13:18, Claes Redestad wrote:
On 2016-06-09 14:11, Erik Joelsson wrote:
You have a point, we should avoid relying on uninitialized variables
being empty.
http://cr.openjdk.java.net/~erikj/8055735/webrev.top.02/
Thanks, looks
On 09/06/2016 13:18, Claes Redestad wrote:
On 2016-06-09 14:11, Erik Joelsson wrote:
You have a point, we should avoid relying on uninitialized variables
being empty.
http://cr.openjdk.java.net/~erikj/8055735/webrev.top.02/
Thanks, looks good to me!
This looks okay to me too.
-Alan.
On 2016-06-09 14:11, Erik Joelsson wrote:
You have a point, we should avoid relying on uninitialized variables
being empty.
http://cr.openjdk.java.net/~erikj/8055735/webrev.top.02/
Thanks, looks good to me!
/Claes
/Erik
On 2016-06-09 13:06, Claes Redestad wrote:
Looks OK to me,
You have a point, we should avoid relying on uninitialized variables
being empty.
http://cr.openjdk.java.net/~erikj/8055735/webrev.top.02/
/Erik
On 2016-06-09 13:06, Claes Redestad wrote:
Looks OK to me, although I'd somehow be happier if FAIL_NO_SRC was
explicitly set to true when
Looks OK to me, although I'd somehow be happier if FAIL_NO_SRC was
explicitly set to true when JDK_FILTER isn't set.
/Claes
On 2016-06-09 12:40, Erik Joelsson wrote:
After the source code restructure, the JDK_FILTER functionality is not
working well. The first module that needs to be
This small patch adds the jmod tool itself as a dependency to the
creation of jmods. The effect of this is that changes to the jmod tool
src will trigger a rebuild of all jmods automatically.
Bug: https://bugs.openjdk.java.net/browse/JDK-8144911
Patch:
diff -r 89769a2f1511 make/CreateJmods.gmk
After the source code restructure, the JDK_FILTER functionality is not
working well. The first module that needs to be recompiled gets the
filter applied, but then the dependents also get it and the macro finds
zero files and fails the build. I have created a fix for this that makes
the build
Hello,
Generally looks good, but I do think this needs to be changed:
JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI)
The number of ../ should probably match the directory level depth of the
variable before it, at least it looks that way
On 2016-06-09 02:54, David Holmes wrote:
Hi Erik,
This seems good. Though it does seem to me that whole BUILJDK things
is rather complex!
Thanks!
I definitely agree. Every time I find an issue like this I feel like I
went about the buildjdk business the wrong way, but I haven't been
14 matches
Mail list logo
