On 2017-11-25 00:19, Martin Buchholz wrote:
Should all phony targets be listed in a .PHONY line?
Yes, that's our policy. We do that using the ALL_TARGETS variable, which
has a
.PHONY: $(ALL_TARGETS)
rule at the end.
Things can break subtly if you don't have phony targets declared as such.
/Ma
MSYS2 or Cygwin should be similar from the technical point of view IMHO. I’m
familiar with MSYS2, but not with Cygwin.
The big change as you called out is to make sure that gcc toolchain can build
successfully also for a Windows platform and produce a properly working
binaries.
BTW I don’t bel
Hi Peter,
sorry if I came over too harsh. I gave this some thoughts and now I think
getting the openjdk to build with gcc on Windows may be beneficial. Please
find more comments inline.
On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai
wrote:
> MSYS2 or Cygwin should be similar from the technical p
Just a quick reply (I haven't read the details yet, will do so and
re-reply if I find anything more to add).
It's important to differentiate two different aspects here.
1) Using msys2 instead of cygwin
2) Compiling using gcc on windows.
1 should be fairly trivial. We once supported msys, and i
On Mon, Nov 27, 2017 at 3:01 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> Just a quick reply (I haven't read the details yet, will do so and
> re-reply if I find anything more to add).
>
> It's important to differentiate two different aspects here.
>
> 1) Using msys2 instead of
On 27.11.2017 15:17, Thomas Stüfe wrote:
Also the question of who is supposed to maintain it in the long run should
be answered. We are usually quite strict in adding new platforms - I
remember the recent BSD port discussions, which I believe ended in 1) needs
a long term maintainer, preferably a
Looks good.
/Erik
On 2017-11-24 01:28, Magnus Ihse Bursie wrote:
When running individual tests using run-test, the summary section gets
hard to read. For instance: (imagine having a fixed-with font :))
TEST TOTAL PASS FAIL ERROR
jtreg:hotspot/test/gc/stress/gcbasher/TestGCBasherWithG1.j
Looks good.
/Erik
On 2017-11-24 02:14, Magnus Ihse Bursie wrote:
When running tests with `make run-test`, tests from
jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't
excluded.
Bug: https://bugs.openjdk.java.net/browse/JDK-8179554
WebRev:
http://cr.openjdk.java.net/~ihse/
Looks good.
/Erik
On 2017-11-24 02:23, Magnus Ihse Bursie wrote:
When running jtreg tests, make run-test should always run with a
fresh, clean JTwork directory in order to avoid issues with code not
being recompiled.
Bug: https://bugs.openjdk.java.net/browse/JDK-8179555
Patch inline:
diff -
Looks good.
/Erik
On 2017-11-24 02:22, Magnus Ihse Bursie wrote:
From the bug report:
"According to research by Jonathan Gibbons , JTReg now supports 256
jobs, in contrast to the older limit of 50 jobs. This limit is
enforced in the make files, and it should be updated to reflect the
new li
Looks good.
/Erik
On 2017-11-24 02:45, Magnus Ihse Bursie wrote:
With the new layout of make run-test, the test-results and
test-support directories are not removed by "make clean-test", and not
even "make clean".
Bug: https://bugs.openjdk.java.net/browse/JDK-8191856
Patch inline:
diff --gi
Magnus:
Looks good to me as well.
Tim
On 11/27/17 08:41, Erik Joelsson wrote:
Looks good.
/Erik
On 2017-11-24 02:14, Magnus Ihse Bursie wrote:
When running tests with `make run-test`, tests from
jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't
excluded.
Bug: https://bug
Magnus:
"...always run with a fresh, clean JTwork directory..."
I couldn't agree more. Looks good to me as well.
Tim
On 11/27/17 08:42, Erik Joelsson wrote:
Looks good.
/Erik
On 2017-11-24 02:23, Magnus Ihse Bursie wrote:
When running jtreg tests, make run-test should always run wit
We should save the run-test summary to a file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01
/Magnus
Magnus:
We should save the run-test summary to a file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01
Looks good.
/Tim
Looks good.
/Erik
On 2017-11-27 10:41, Magnus Ihse Bursie wrote:
We should save the run-test summary to a file.
Bug: https://bugs.openjdk.java.net/browse/JDK-8191923
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01
/Magnus
Hi,
the IntelliJ support for JDK relies on make to give the set of source
roots used for any given modules. I have noticed that the set of source
roots associated with 'jdk.internal.vm.ci' is incorrect, as it points to
src/jdk.internal.vm.ci/share/classes
while in reality it should point to a
On 2017-11-27 20:02, Erik Joelsson wrote:
Looks good.
Only it didn't. :-)
I managed to drop one (very important) line when juggling this patch
between my sandbox and the repo.
Updated WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02
/Magnus
/
Magnus:
On 2017-11-27 20:02, Erik Joelsson wrote:
Looks good.
Only it didn't. :-)
I managed to drop one (very important) line when juggling this patch
between my sandbox and the repo.
Updated WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02
Yes,
The jtreg failure handler needs to be used when running tests using the
run-test framework.
Bug: https://bugs.openjdk.java.net/browse/JDK-8191933
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-handler-in-run-test/webrev.01
/Magnus
You need a definition of the variable? Couldn't the user just be
required to define it when running tests?
Looks good.
/Erik
On 2017-11-27 11:59, Magnus Ihse Bursie wrote:
On 2017-11-27 20:02, Erik Joelsson wrote:
Looks good.
Only it didn't. :-)
I managed to drop one (very important) line
On 2017-11-27 22:52, Erik Joelsson wrote:
You need a definition of the variable? Couldn't the user just be
required to define it when running tests?
I'm not sure what you mean. The intention is to not only print the
output, but to also store it in the test-results directory. I don't
think the t
On 2017-11-27 14:19, Magnus Ihse Bursie wrote:
On 2017-11-27 22:52, Erik Joelsson wrote:
You need a definition of the variable? Couldn't the user just be
required to define it when running tests?
Sorry, I meant this as a joke but forgot to add the smiley. :)
/Erik
I'm not sure what you mean.
From the bug report:
A common scenario is adding vm arguments when running tests. While this
can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to type
for a common case. In the future, when gtest accepts vm arguments as
well, a separate, similar but yet different GTEST="VM_OPTIONS
Looks good.
/Erik
On 2017-11-27 15:11, Magnus Ihse Bursie wrote:
From the bug report:
A common scenario is adding vm arguments when running tests. While
this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to
type for a common case. In the future, when gtest accepts vm argume
This is a follow-up on JDK-8189611 that defines a new public API to
return a stream of versioned entries and to return the real name of a
JAR entry. JDK-8189611 leaves jdeps untouched because jdeps is compiled
with the boot JDK.
This patch includes:
(1) changes the build not to build jdk.jdep
Hello.
Please review the fix for jdk10. This is the second attempt to move
windows L&F from non-windows platforms. The first attempt JDK-6461834[1]
was reverted because of JDK-8184813[2].
The root cause of those issue was fixed in JDK-8075255[3], and now we
can move it again.
Bug: https://bug
Hi Mete,
A 64-bit client build, stand-alone, is not supported. There could be
more issues than just getting the build to not fail.
David
On 23/11/2017 11:32 PM, Mete Balci wrote:
Hi,
I am trying to build the client variant, but it fails with the output
below. Is this a known issue or is the
28 matches
Mail list logo
