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 functions eg
(untested but you should get the gist):
// OR
ifeq (true, findstring( $(OPENJDK) $(MYJDK), true)
// not-OR
ifneq (true, findstring( $(OPENJDK) $(MYJDK), true)
It's not as trivial as || etc but not too horrendously ugly :)
Does this help?
David
On 22/04/2014 11:10 PM, Keith McGuigan wrote:
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 CopyFiles.gmk (but CreateSecurityJars.gmk
has a bit too). Basically in each situation where there's a "ifndef
OPENJDK", it encloses a block of code that access something in
src/closed or make/closed.
I did initially try to set a new variable in our build in an attempt to
replace these areas with something like:
ifndef OPENJDK && ifndef PRIVATEJDK
... but there's apparently no convenient way of doing that in makefiles
(conjunctions and disjunctions at the preprocessing level aren't
available -- and the workarounds are rather goofy). Duplicating the
OPENJDK only code quickly became unreasonable too -- a few of the code
blocks are one-liners, but there's a bunch that are much more involved
clauses.
On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
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 is enough to indicate the "feature" is present.
Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
introducing a third variation doesn't really fit.
Can you give a concrete example of something that highlights this
problem for you and how your proposal addresses it? I may get a
better sense of things with specifics rather than trying to
generalize - because I don't see a general solution without a lot of
refactoring.
Thanks,
David
On 22/04/2014 2:42 PM, Keith McGuigan wrote:
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
to be a distribution name -- we call it whatever you like:
TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to
latch onto
to deactivate that code when it is not needed. This would provide
immediate relief to customizing distributors and give Oracle
engineers
time to phase that code into closed makefiles (at which time the
signposts can be removed completely).
Taking all this code out wholesale instead would be great, and
this is
something I am totally willing to tackle and put the effort in
on if I
was in a position to do so. Unfortunately, since this is not fully
open-source, I can't do the refactoring needed to move this code
into
the closed directories. And I though I could easily strip the
code from
OpenJDK, this would totally muck with Oracle distribution so any
patch I
would submit would surely be immediately rejected.
Considering that the code is question has been in OpenJDK for
about 8
years now, I think it's safe to assume that it's not a high priority
item for Oracle engineers to get this fixed. Which is totally
fine, IMO
-- it's very much a tenant of open source development that he
who has
the itch ought to be the one to scratch it, and different
entities are
expected to have different sets of priorities. No doubt I'm
probably
the first one to complain about this :)
Unfortunately, I'm also in the unfortunate position of having an
itch
(and willing fingernails), but an inability to scratch it.
So, where do we go from here and how can I help in this effort? I
really do want to help, as this is an immediate problem for me and I
can't afford to wait years for it to get fixed. I still think that
signposts are a very reasonable compromise given that:
(1) It is something that can be done independently and doesn't
require
Oracle engineering resources (other than reviews and shepherding)
(2) It does not interfere with efforts to move closed code out of
OpenJDK makefiles
(3) it can be done quickly
(4) It does not avoid the Makefile-checking for existence of
required
files/directories (which reduces build-brittleness)
Mark/Dave, if I can't convince you that we should take this
path, can
you please suggest an alternative design? I'm not picky -- if
we can
come up with something else that works then let's do it and I'll
start
on it right away.
--
- Keith (itchy)
On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinh...@oracle.com
<mailto:mark.reinh...@oracle.com>
<mailto:mark.reinhold@oracle.__com
<mailto:mark.reinh...@oracle.com>>> wrote:
2014/4/16 14:52 -0700, david.hol...@oracle.com
<mailto:david.hol...@oracle.com>
<mailto:david.holmes@oracle.__com
<mailto: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 problem.
That would
be a
> first step in moving things to the custom makefiles
where they
belong.
>
> I'm opposed to the ORACLEJDK variable because I want to
maintain the
> pressure to get this fixed properly. If we hack around
it then it
will
> never get cleaned up.
I think it's wrong, in principle, for OpenJDK source code
to contain
identifiers naming specific vendors of JDK implementations.
We're not
quite there at the moment, but let's please not add any more.
- Mark
