On Wed, Apr 23, 2014 at 8:51 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> 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 the open-source
makefiles.
I see no short-term fix for this beyond what I suggested, as an
alternate to putting in the ORACLEJDK variable. But you would have
to maintain that change in your private repo - I see no way around that.
So let me get this clear then. There is Oracle code in the makefiles.
That code interferes with creating an alternate distribution based
upon OpenJDK using the "alternative source" mechanism. These things we
agree upon, yes?
What you telling me is that you will prevent me from adding a harmless
macro to the OpenJDK makefiles that will simply identify the Oracle
closed, proprietary code so that I (and anyone who is not Oracle or it's
licensees) can skip over those parts of the makefile. And instead your
solution is that I need to do all of this in a private repository and
maintain this code myself, going forward forever, until Oracle gets
around to removing the proprietary code from the makefiles (code that
has been present for 7+ years and doesn't look to be going anywhere).
All so that you can avoid seeing a macro that won't do you any harm or
add to your burden in any way.
Do I have this all correct? is this how cooperative, open development
occurs in OpenJDK? Oracle gets to use features to make a custom
distribution, but no one else can? This hardly seems fair.
--
- Keith
Given that:
ifndef OPENJDK
actually, implicitly means
ifdef ORACLEJDK
then all non-Oracle builds must presently declare themselves to be
OPENJDK implementations. To which they can add specific customizations.
My goal here is to have the public OpenJDK makefiles be in a
state such
that custom distribution code can be added (in make/closed,
src/closed,
or some such alternative location) without having to perform
surgery on
the Makefiles and maintain the private changes. The mechanism is
already in place,it's just some leftover OracleJDK that hasn't
made it
out of the open makefiles yet. If we could just cordon that off
somehow, then anyone could make a custom distribution by augmenting
OpenJDK with 'closed' style repositories -- without having to
maintain
private, unrelated edits to jdk Makefiles.
You simply need to leave OPENJDK set to true to achieve that
cordoning off.
Even if we move all OracleJDK specific stuff out of the open
makefiles a completely clean separation may not be possible:
- the customization hooks can not be everywhere and different
customizations may have different requirements
- if there are chunks of OpenJDK code (ie code currently part of
both OpenJDK and Oracle JDK) that are not wanted in your custom
build then you will still need to maintain private makefile changes
to exclude them. To fix this will need additional "modularization"
of the build with feature-selection (though not in a way that would
violate the platform specifications).
David
-----
On Wed, Apr 23, 2014 at 12:10 AM, David Holmes
<david.hol...@oracle.com <mailto:david.hol...@oracle.com>
<mailto:david.holmes@oracle.__com
<mailto:david.hol...@oracle.com>>> wrote:
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>
<mailto:david.holmes@oracle.__com <mailto:david.hol...@oracle.com>>
<mailto:david.holmes@oracle.
<mailto:david.holmes@oracle.>____com
<mailto:david.holmes@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>>
<mailto:mark.reinhold@oracle.
<mailto:mark.reinhold@oracle.>____com
<mailto:mark.reinhold@oracle.__com
<mailto:mark.reinh...@oracle.com>>>
<mailto:mark.reinhold@oracle
<mailto:mark.reinhold@oracle>.
<mailto:mark.reinhold@oracle
<mailto:mark.reinhold@oracle>.>______com
<mailto:mark.reinhold@oracle.
<mailto:mark.reinhold@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>>
<mailto:david.holmes@oracle.
<mailto:david.holmes@oracle.>____com
<mailto:david.holmes@oracle.__com
<mailto:david.hol...@oracle.com>>>
<mailto:david.holmes@oracle
<mailto:david.holmes@oracle>.
<mailto:david.holmes@oracle
<mailto:david.holmes@oracle>.>______com
<mailto:david.holmes@oracle.
<mailto:david.holmes@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
