Hi Keith,
Okay ... so you don't set OPENJDK and thus from the make logic
perspective you are implicitly ORACLE_JDK. So first question: why don't
you set OPENJDK and then add blocks guarded by MY_JDK (or whatever) for
your custom stuff?
Second, the way to get a disjunction is to use the text
On 4/22/2014 6:12 PM, Vladimir Kozlov wrote:
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next asser
On 4/22/14 4:42 PM, Alejandro E Murillo wrote:
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next assert message is not consistent with previous messa
On 4/21/2014 1:18 PM, Vladimir Kozlov wrote:
Hi Alejandro,
I don't think we need to rename make/hotspot_version file. It is still
used to set JVM's version string and not JDK's version.
Next should be 2014 (I think David pointed it too but there is no new
webrev): HOTSPOT_VM_COPYRIGHT=Cop
The comments at the end of the webrev could be improved as well at some
point.
You can barely see the code for all the dust and spiders. I think it
talks about
"large 32 bits machines" but surely that can't be right... :-)
1200 #release version of core packages
1201
1202 # The rel-cor
Nice to see this improved.
Mike
On Apr 22 2014, at 06:29 , Erik Joelsson wrote:
> (reposting with correct subject)
>
> On 2014-04-22 15:28, Erik Joelsson wrote:
>> I recently had to work with make/Javadoc.gmk and felt that it needed some
>> attention. This patch makes it behave correctly for
Hi Erik,
On 4/22/14 2:58 AM, Erik Joelsson wrote:
> The build is trying to run rmic using the newly built jdk. It seems
> there is a problem with the zip.dll that you just built. Are you able
> to run
> C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java
> at all?
No - because
On Apr 22 2014, at 01:21 , Erik Joelsson wrote:
> Hello Mike,
>
> This will probably work fine. Perhaps a note on the formatting of the new
> argument is needed? From what I can tell it needs to always start with "-a".
The specialization could theoretically start with an -o but you are right
(adding javadoc-dev)
On 2014-04-22 15:29, Erik Joelsson wrote:
(reposting with correct subject)
On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed
some attention. This patch makes it behave correctly for incremental
builds and reduce
Hi Erik:
(reposting with correct subject)
On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed
some attention. This patch makes it behave correctly for incremental
builds and reduces the log output on the default log level to much
mor
(reposting with correct subject)
On 2014-04-22 15:28, Erik Joelsson wrote:
I recently had to work with make/Javadoc.gmk and felt that it needed
some attention. This patch makes it behave correctly for incremental
builds and reduces the log output on the default log level to much
more manageabl
I recently had to work with make/Javadoc.gmk and felt that it needed
some attention. This patch makes it behave correctly for incremental
builds and reduces the log output on the default log level to much more
manageable levels.
I realize that we should probably rewrite this even more to reduc
Hi David,
Most of the problem resides in jdk/make, in the following files:
make/CompileDemos.gmk
make/CompileJavaClasses.gmk
make/CopyFiles.gmk
make/CopyIntoClasses.gmk
make/CreateSecurityJars.gmk
make/gensrc/GensrcIcons.gmk
make/Images.gmk
make/lib/Awt2dLibraries.gmk
Biggest offender is problem
Hi Keith,
Sorry I have very limited cycles right now, and just had a 4 day Easter
break with anther long weekend ahead :)
You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat
tangential to your issue.
The existence checks I suggested would be a check for whatever
file/directory
On 22/04/2014 1:25 PM, Pete Brunet wrote:
On 4/21/14 9:30 PM, David Holmes wrote:
On 19/04/2014 5:25 AM, Pete Brunet wrote:
Success. I found this post from Arun Gupta:
https://blogs.oracle.com/arungupta/entry/build_open_jdk_7_on
which specifies this
make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_J
Voting for Build Group Lead Tim Bell [1] is now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Simple Majority, this is
sufficient to approve the new Group Lead. The OpenJDK Lead will
ask the Governing Board to ratify this nomination.
Erik Joelsson (on behalf of Magnus
> On 22 Apr 2014, at 09:10, Erik Joelsson wrote:
>
> Seems to work for me too. Nice speedup! Looks good to me.
+1. Thanks for doing these improvements Mike.
-Chris.
>
> /Erik
>
>> On 2014-04-19 01:21, Mike Duigou wrote:
>> Hello all;
>>
>> This is an improvement to hgforest to increase it
I ran the patch on OS X and it worked there too. Thanks!
You mention “status code from subprocesses” which got me thinking of a problem
I frequently run into when I have some uncommitted changes in one of the repos:
...
.: searching for changes
Hello Mike,
This will probably work fine. Perhaps a note on the formatting of the
new argument is needed? From what I can tell it needs to always start
with "-a".
I can't help but think that there might be a need for named caches at
some point if this is introduced, but I will add that if I
Looks good.
/Erik
On 2014-04-19 02:23, Mike Duigou wrote:
Hello all;
This is a very simple patch which causes the already calculated MEMORY_SIZE
variable to be emitted into the spec.gmk where it can be used by make scripts.
Generally this will be to provide a different calculation of the numb
Seems to work for me too. Nice speedup! Looks good to me.
/Erik
On 2014-04-19 01:21, Mike Duigou wrote:
Hello all;
This is an improvement to hgforest to increase it's concurrency behaviour.
Currently hgforest.sh limits the rate at which it starts new sub-processes
because it wants to limit t
The build is trying to run rmic using the newly built jdk. It seems
there is a problem with the zip.dll that you just built. Are you able to
run
C:/Users/Pete/JDK7u/jdk7-clone/jdk7/build/windows-i586-fastdebug/bin/java at
all?
/Erik
On 2014-04-18 23:56, Pete Brunet wrote:
p.s. The ALT_BOOTD
That didn't help much unfortunately. I'm suspecting something strange in
your environment. Could you try applying this patch and post then post
the contents of full-vs-env.txt?
diff -r 9d88779ac71e common/autoconf/toolchain_windows.m4
--- a/common/autoconf/toolchain_windows.m4 Mon Apr 21
23 matches
Mail list logo
