When removing --with-dxsdk, we forgot about backwards compatibility.
When removing configure options, we need to leave them along as noops
for a time to allow for users of the configure API time to change.
http://cr.openjdk.java.net/~erikj/8024815/webrev.root.01/
/Erik
Build change looks ok.
/Erik
On 2013-09-17 13:07, Weijun Wang wrote:
Webrev updated to version 02 at
http://cr.openjdk.java.net/~weijun/8011402/webrev.02/
Changes since webrev.01:
1. Makefiles:
- new build logic outside ifndef OPENJDK
- Add a sed check to make sure open and close
On Sep 18, 2013, at 2:06 AM, Erik Joelsson erik.joels...@oracle.com wrote:
When removing --with-dxsdk, we forgot about backwards compatibility. When
removing configure options, we need to leave them along as noops for a time
to allow for users of the configure API time to change.
On 2013-09-18 11:06, Erik Joelsson wrote:
When removing --with-dxsdk, we forgot about backwards compatibility.
When removing configure options, we need to leave them along as noops
for a time to allow for users of the configure API time to change.
On 2013-09-17 20:01, Jungwoo Ha wrote:
Can you tell me what is the expected layout of devkit?
I'll put things together and will try.
--with-devkit=/foo is a shorthand for
--with-tools-dir=/foo/bin --with-sys-root=/foo/host_alias/libc
or
--with-tools-dir=/foo/bin
On 2013-09-16 17:20, Volker Simonis wrote:
Hi,
could you please review the following webrev which contains the changes
needed in the 'jdk' repository in order to build the OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
All in all, it looks good!
My only nitpick is
This looks much better, thanks!
/Erik
On 2013-09-18 11:43, Magnus Ihse Bursie wrote:
On 2013-09-18 11:06, Erik Joelsson wrote:
When removing --with-dxsdk, we forgot about backwards compatibility.
When removing configure options, we need to leave them along as noops
for a time to allow for
On 09/17/2013 07:07 AM, Weijun Wang wrote:
Webrev updated to version 02 at
http://cr.openjdk.java.net/~weijun/8011402/webrev.02/
Changes since webrev.01:
1. Makefiles:
- new build logic outside ifndef OPENJDK
- Add a sed check to make sure open and close list use same algorithm
2.
Changeset: 9286a6e61291
Author:ihse
Date: 2013-09-18 13:49 +0200
URL: http://hg.openjdk.java.net/jdk8/build/rev/9286a6e61291
8024849: Don't remove upper case letters from username when setting
USER_RELEASE_SUFFIX
Reviewed-by: erikj
! common/autoconf/basics_windows.m4
!
If a machine has 4 cores and 8 threads will the jdk8 build run faster
than one with 4 cores and 4 threads? If so would it be a 2x decrease in
build time? Would the build explicitly take advantage of the
hyper-threading or would any increase in performance be a side effect?
If a machine has 4 cores and 8 threads will the jdk8 build run faster
than one with 4 cores and 4 threads? If so would it be a 2x decrease in
build time? Would the build explicitly take advantage of the
hyper-threading or would any increase in performance be a side effect?
My understanding
On 19/09/2013 7:43 AM, Pete Brunet wrote:
If a machine has 4 cores and 8 threads will the jdk8 build run faster
than one with 4 cores and 4 threads?
All depends on where the bottlenecks are. Given a build is pretty much
I/O bound I wouldn't expect much difference.
If so would it be a 2x
I like it too!
David
On 18/09/2013 8:22 PM, Erik Joelsson wrote:
This looks much better, thanks!
/Erik
On 2013-09-18 11:43, Magnus Ihse Bursie wrote:
On 2013-09-18 11:06, Erik Joelsson wrote:
When removing --with-dxsdk, we forgot about backwards compatibility.
When removing configure
Thanks. I am thinking of buying a new 4 core laptop later this year so
was curious to know if the 8 thread hyperthreading would help that much
over the 4 cores without hyperthreading. Actually I don't think there
will be a non-hyperthreading option. I put in an SSD last week and now
I'm compute
14 matches
Mail list logo
