Hi Matthew,
This code has in fact already been changed:
changeset: 895:067355edfbf8
user:vinnie
date:Wed Oct 30 17:31:01 2013 +
summary: 8027567: JDK 8 build failure: the correct version of GNU
make is being rejected
diff -r d832f6171acd -r 067355edfbf8 common/autoco
On 1/11/2013 3:24 AM, mark.reinh...@oracle.com wrote:
2013/10/31 2:41 -0700, kellyoh...@gmail.com:
With build logic, it is relatively easy to build before and after and
verify the exact same resulting bits.
The risk is that we have a number of different build environments and we
would need to
Magnus indicated in another thread earlier today that ccache doesn't do
anything on windows since we use the microsoft compilers.
--disable-ccache or uninstall it.
I filed an RFE to disable ccache on windows.
Mike
On Oct 31 2013, at 15:50 , Bradford Wetmore wrote:
> P.S. This version of cca
P.S. This version of ccache was added two days ago.
Brad
On 10/31/2013 3:42 PM, Bradford Wetmore wrote:
I just rebuilt my CYGWIN, and got ccache 3.1.9-2, which enables ccache
in the new build environment. fixpath.exe does not play well with it.
Please see:
https://bugs.openjdk.java.net/bro
I just rebuilt my CYGWIN, and got ccache 3.1.9-2, which enables ccache
in the new build environment. fixpath.exe does not play well with it.
Please see:
https://bugs.openjdk.java.net/browse/JDK-8027683
JDK-8027683: New version of CYGWIN includes ccache 3.1.9-2, breaks the
windows build.
Th
On 10/31/2013 04:41 PM, Kelly O'Hair wrote:
With build logic, it is relatively easy to build before and after and verify
the exact same resulting bits.
So the risk is considerably less than in other areas of software development.
There might be more risk leaving it in, where the wrong build log
On 10/31/2013 01:18 PM, Erik Joelsson wrote:
While the change is correct, ccache usage on Solaris is pointless in my
experience. Are you actually seeing performance gains by using it? I
When I originally got ccache hooked up I didn't see much ( if any )
improvement, but put this down to the c
2013/10/31 2:41 -0700, kellyoh...@gmail.com:
> With build logic, it is relatively easy to build before and after and
> verify the exact same resulting bits.
>
> So the risk is considerably less than in other areas of software
> development. There might be more risk leaving it in, where the wrong
With build logic, it is relatively easy to build before and after and verify
the exact same resulting bits.
So the risk is considerably less than in other areas of software development.
There might be more risk leaving it in, where the wrong build logic gets
changed to fix an issue,
or the old b
I agree completely with the sentiment here, but the conversation with
Magnus seemed to be headed in the direction of weighing up the risk of
doing this so late in the jdk8 game. I am just looking for a clear
understanding of the benefits of doing this now, rather than early in 9,
or an 8 Update
On Oct 31, 2013, at 7:49 AM, Alan Bateman wrote:
> On 31/10/2013 14:38, Chris Hegarty wrote:
>> What are we gaining by removing this in jdk8? Does it make sense to do it as
>> one of the first pushes to 9?
> The old build is currently a tax, and a tax that will continue into the 8
> updates unt
On 31/10/2013 14:38, Chris Hegarty wrote:
What are we gaining by removing this in jdk8? Does it make sense to do
it as one of the first pushes to 9?
The old build is currently a tax, and a tax that will continue into the
8 updates until the old build is removed or disabled. It's a real shame
th
What are we gaining by removing this in jdk8? Does it make sense to do
it as one of the first pushes to 9?
-Chris.
On 10/31/2013 02:17 PM, Magnus Ihse Bursie wrote:
On 2013-10-31 13:28, Alan Bateman wrote:
On 31/10/2013 07:36, Magnus Ihse Bursie wrote:
I'm not sure there is a definite plan
On 2013-10-31 13:28, Alan Bateman wrote:
On 31/10/2013 07:36, Magnus Ihse Bursie wrote:
I'm not sure there is a definite plan for this. Personally, I'd
prefer to have this fixed in JDK8, but I'm also aware that the timing
is not ideal. Unfortunately, some groups were still using the old
buil
While the change is correct, ccache usage on Solaris is pointless in my
experience. Are you actually seeing performance gains by using it? I
investigated this quite thoroghly a while back and concluded that ccache
and sun studio just didn't go together. I think I could make ccache work
with sun
Erik,
I have a build of ccache 3.1.9 on my Solaris box, but it is not being
used by the build as it thinks it is not greater than 3.1.4.
The suggested changes (below) are in line with the grep/regular
expression used in the GNU make version check you and Vinnie were
discussing yesterday. Add
On 31/10/2013 07:36, Magnus Ihse Bursie wrote:
I'm not sure there is a definite plan for this. Personally, I'd prefer
to have this fixed in JDK8, but I'm also aware that the timing is not
ideal. Unfortunately, some groups were still using the old build
system until very recently, so we have b
Hello,
The bug Magnus linked is tracking that work, and I'm happy to let them
(the perf team afaik) handle it. I was more interested in removing them
than updating them anyway, but it seems they still serve a purpose in
some cases.
/Erik
On 2013-10-31 00:18, Mike Duigou wrote:
Hi Erik;
It
On 2013-10-31 00:18, Mike Duigou wrote:
Hi Erik;
It doesn't look like your updated classlists were pushed and I note that 'HashMap$Entry'
has been renamed to 'HashMap$Node'. Are there plans to update the classlists before Java
8 is finalized? This does seem like something where "mostly right"
On 2013-10-30 16:01, Alan Bateman wrote:
I remember Kelly calling for hazard pay for anyone deleting code and
triple pay for anyone deleting Makefile code.
Boy am I going to be rich! :-)
At a high level the plan looks reasonable. Aside from build tools then
what else are you expecting to l
On 2013-10-31 03:20, David Holmes wrote:
On 31/10/2013 1:01 AM, Alan Bateman wrote:
So is the plan to do all of this in jdk8 before RDP2?
I think this is better targeted to 9 and 8u20. Any subtle mistakes are
unlikely to show up until promoted builds are done by RE. This is not
a P1-P3 issu
21 matches
Mail list logo
