es
To: Keith McGuigan , mark.reinh...@oracle.com
Cc: build-dev
Subject: Re: JDK-8025705
Message-ID: <535f3010.5070...@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Keith,
As requested via email I'm responding on your response to Mark.
On 25/04/2014 8:10 AM, Keith
m
Cc: build-dev
Subject: Re: JDK-8025705
Message-ID: <535f3010.5070...@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Keith,
As requested via email I'm responding on your response to Mark.
On 25/04/2014 8:10 AM, Keith McGuigan wrote:
> Hi Mark,
>
&g
Hi Keith,
As requested via email I'm responding on your response to Mark.
On 25/04/2014 8:10 AM, Keith McGuigan wrote:
Hi Mark,
Well first off, the existence of src/closed triggers OPENJDK to be
unset, so even having such directories (or subrepos) present turns on
all the logic that looks for
Keith,
Given
ifndef OPENJDK
currently really means
ifdef ORACLEJDK
all I'm saying is that you should be setting OPENJDK=true to exclude
much of the ORACLEJDK stuff - which is what you wanted. Don't let the
default value for it be set based on whether src/closed is found - force
it to true!
On 04/25/2014 08:48 AM, Erik Joelsson wrote:
> Yes, it's bad if we "pollute" OpenJDK makefiles with references to
> Oracle, but the damage really is already done since we already have all
> this Oracle specific stuff in them, just hidden under a "not-open"
> label. I think we should indeed make
I've been following this discussion for a while now and more and more I
agree with Keith. The current situation where "ifndef OPENJDK"
essentially means OracleJDK really is broken. This is something I and
Magnus have noted several times but not yet had time to fokus on fixing.
Mostly becuase th
Hi Mark,
Well first off, the existence of src/closed triggers OPENJDK to be unset,
so even having such directories (or subrepos) present turns on all the
logic that looks for files in src/closed which probably don't exist in a
non-Oracle distribution. So having an ORACLEJDK test instead around th
2014/4/22 21:23 -0700, kmcgui...@twitter.com:
> Yes, I did consider using some ifeq tricks like that -- but they are rather
> ugly and unreadable and have the same problem that you want to avoid:
> adding distribution-specific code into the open-source makefiles.
>
> My goal here is to have the pu
On Wed, Apr 23, 2014 at 8:51 PM, David Holmes wrote:
> On 23/04/2014 9:23 PM, Keith McGuigan wrote:
>
>> Yes, I did consider using some ifeq tricks like that -- but they are
>> rather ugly and unreadable and have the same problem that you want to
>> avoid: adding distribution-specific code into th
On 23/04/2014 9:23 PM, Keith McGuigan wrote:
Yes, I did consider using some ifeq tricks like that -- but they are
rather ugly and unreadable and have the same problem that you want to
avoid: adding distribution-specific code into the open-source makefiles.
I see no short-term fix for this beyon
Yes, I did consider using some ifeq tricks like that -- but they are rather
ugly and unreadable and have the same problem that you want to avoid:
adding distribution-specific code into the open-source makefiles.
My goal here is to have the public OpenJDK makefiles be in a state such
that custom di
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
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
Hi Mark, et al.,
The sad reality of the situation is that there is indeed Oracle-specific
code in the OpenJDK makefiles, and this code interferes with our
customization of the JDK. Adding temporary signposts to allow us (and
others) to avoid this code will not make things worse. It doesn't have
2014/4/16 14:52 -0700, david.hol...@oracle.com:
> src/closed is Oracle's "custom source" location (hotspot calls it
> alt_src). If we never saw src/closed in the makefiles, only
> CUSTOM_SRC_DIR, and guarded with an existence test for a specific
> directory/file, then that should address your pr
On Thu, Apr 17, 2014 at 12:52 AM, David Holmes wrote:
> Hi Keith,
>
> src/closed is Oracle's "custom source" location (hotspot calls it
> alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR,
> and guarded with an existence test for a specific directory/file, then that
> shou
Hi Erik,
Sorry I posted this to the wrong list.
I agree that using CUSTOM_SRC_DIR, configured via 'configure', is a good
idea (Dave's #1). I'm not so sure that file existence checks are the best
idea, though, for the reasons Erik points out -- change a filename and all
of sudden things just stop
(moving discussion to build-dev since this isn't directly part of the
makefile rewrite project)
Hello Keith,
I certainly feel your pain in dealing with this, it's currently a mess.
I'm not as opposed to the "ORACLEJDK" variable as David is, but I'm also
not sure it will correctly express thin
19 matches
Mail list logo
