ed I should
actually get valid results.
-DrD-
From: David DeHaven
Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
Date: June 4, 2014 16:01:29 PDT
To: build-dev build-dev
Next (hopefully last??) update:
http://cr.openjdk.java.net/~ddehaven/8043340/v3
(ignore changes
lts.
-DrD-
From: David DeHaven
Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
Date: June 4, 2014 16:01:29 PDT
To: build-dev build-dev
Next (hopefully last??) update:
http://cr.openjdk.java.net/~ddehaven/8043340/v3
(ignore changes to jdk/src/macosx/native/sun/osxap
spot/
>>>
>>> Also, is there a problem if I push these through jdk9/build instead of
>>> going through hotspot?
>>>
>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should
>>> actually get valid results.
>>>
And just FYI, I got a mostly clean JPRT run:
Four failures, a couple already tracked by the following issues:
https://bugs.openjdk.java.net/browse/INTJDK-7609054
https://bugs.openjdk.java.net/browse/JDK-8043951 (reported to jprt_admin)
This might be related to the latter as it happened only on t
>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>> $ make clean; sh ./configure; make images
>>> Broken! The current Xcode command line tools don't run gcc as gcc even if
>>> Xcode 4 is active
>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to
>>> use --wi
On 06/10/2014 02:26 PM, David DeHaven wrote:
Can I get another Review on this?
Looks good to me.
$ sudo xcode-select -switch /Applications/old/Xcode4.app
$ make clean; sh ./configure; make images
Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode
4 is active
N
Can I get another Review on this?
Also, since I don't think the servers have been updated to allow me to push
yet, I may need someone to push for me.
-DrD-
> Next (hopefully last??) update:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>
> (ignore changes to jdk/src/macosx/native/sun/osxa
Ok, thanks.
-DrD-
> At some point I mean. It's ok to not do it as part of this change.
>
> /Erik
>
> On 2014-06-09 10:06, Erik Joelsson wrote:
>> It certainly should be updated.
>>
>> /Erik
>>
>> On 2014-06-05 23:51, David DeHaven wrote:
>>> Will README-builds.html be updated as part of the
At some point I mean. It's ok to not do it as part of this change.
/Erik
On 2014-06-09 10:06, Erik Joelsson wrote:
It certainly should be updated.
/Erik
On 2014-06-05 23:51, David DeHaven wrote:
Will README-builds.html be updated as part of the compiler update? It
(will be) outdated.
I don
It certainly should be updated.
/Erik
On 2014-06-05 23:51, David DeHaven wrote:
Will README-builds.html be updated as part of the compiler update? It (will be)
outdated.
I don't think it needs to be part of this patch since I'd like to backport this
(and the other patches I've contributed re
Will README-builds.html be updated as part of the compiler update? It (will be)
outdated.
I don't think it needs to be part of this patch since I'd like to backport this
(and the other patches I've contributed recently) to 8u after it incubates for
a while.
-DrD-
>> Only thing I can think of
> Only thing I can think of now is that some of the error/warning messages do
> not start with a capital letter. Looks good and nice work!
I'll fix those before pushing.
>> I also removed using SDKROOT from the env, since we ignore the environment.
>> Only two args affect SYSROOT now, --with-
Only thing I can think of now is that some of the error/warning messages
do not start with a capital letter. Looks good and nice work!
On 2014-06-05 01:01, David DeHaven wrote:
Next (hopefully last??) update:
http://cr.openjdk.java.net/~ddehaven/8043340/v3
(ignore changes to jdk/src/macosx/nat
Next (hopefully last??) update:
http://cr.openjdk.java.net/~ddehaven/8043340/v3
(ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a
separate patch)
I also removed generated_configure.sh since those will be automatically
generated before pushing anyways and it just k
* Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still
use this in some closed makefiles. Or is the idea that we instead will
force the sdk name to 10.7? If so, then we need to still leave this in
until every user (RE) has switched properly.
>>> I moved all
>>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still
>>> use this in some closed makefiles. Or is the idea that we instead will
>>> force the sdk name to 10.7? If so, then we need to still leave this in
>>> until every user (RE) has switched properly.
>> I moved all that
On 2014-06-02 18:23, David DeHaven wrote:
* Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use
this in some closed makefiles. Or is the idea that we instead will force the
sdk name to 10.7? If so, then we need to still leave this in until every user
(RE) has switched p
On 2014-06-02 23:27, David DeHaven wrote:
Looks pretty good. A couple of questions still:
* Where is the AC_SUBST for SDKROOT?
* Could we get the "Checking for Xcode sdk name" output to only print on macosx?
Would this be OK instead?
AC_MSG_CHECKING([for sdk name])
AC_MSG_RESULT([$
> Looks pretty good. A couple of questions still:
>
> * Where is the AC_SUBST for SDKROOT?
>
> * Could we get the "Checking for Xcode sdk name" output to only print on
> macosx?
Would this be OK instead?
AC_MSG_CHECKING([for sdk name])
AC_MSG_RESULT([$SDKNAME])
Otherwise it might mak
>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use
>> this in some closed makefiles. Or is the idea that we instead will force the
>> sdk name to 10.7? If so, then we need to still leave this in until every
>> user (RE) has switched properly.
>>
>> I moved all that
On Jun 2 2014, at 09:23 , David DeHaven wrote:
> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use
> this in some closed makefiles. Or is the idea that we instead will force the
> sdk name to 10.7? If so, then we need to still leave this in until every user
> (RE) h
> Hello David,
>
> Looks pretty good. A couple of questions still:
>
> * Where is the AC_SUBST for SDKROOT?
Oops, that should've been after SDKROOT="$SYSROOT" in basics.m4.
> * Could we get the "Checking for Xcode sdk name" output to only print on
> macosx?
Can do.
> * Why remove MACOSX_V
Hello David,
Looks pretty good. A couple of questions still:
* Where is the AC_SUBST for SDKROOT?
* Could we get the "Checking for Xcode sdk name" output to only print on
macosx?
* Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still
use this in some closed makefiles. Or i
> Here's the latest patch set:
> http://cr.openjdk.java.net/~ddehaven/8043340/v2/
Just FYI, I ran a build only job on JPRT and it passed:
Build Stats:14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not
started
-DrD-
This is now a combined fix for:
https://bugs.openjdk.java.net/browse/JDK-8043591
https://bugs.openjdk.java.net/browse/JDK-8043340
Since a picture is worth 10,000 words (build systems are 10x as complicated as
anything else in life) here's an ASCII flow chart showing the SYSROOT logic I
have no
25 matches
Mail list logo
