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 there hasn't been any urgent need for it (no external
party has expressed enough interest in utilizing the features we have
for including extra source), until now.
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 it explicit rather than pretending
it's not there.
I can confirm to anyone that isn't intimately familiar with the
makefiles that the difference in maintenance for an external party would
potentially be much less if we made the suggested changes.
On 2014-04-25 00:10, 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 files in src/closed which probably don't exist in a
non-Oracle distribution. So having an ORACLEJDK test instead around that
code means we can control it with a single switch somewhere in a top-level
Makefile (maybe even a makefile in make/closed). This would let us use the
src/closed mechanism and at the same time unset ORACLEJDK (OPENJDK would
also be unset).
If we need to have a private modification to futz with ORACLEJDK (to turn
it off), that's not so bad -- it'd be just in one place so maintenance
would be easier. But it's possible that we can put this logic in a
make/closed file that gets conditionally included, in which case we
wouldn't even have to worry about that.
As to how to get custom code compiled, I think we have a couple options to
try. In hotspot the code is just magically picked up and treated as if it
were sitting in the non-closed directory, augmenting or overriding the open
sources (depending on the filename). If we could do something like that in
the jdk makefiles, that would be ideal (IMO). But it may not be feasible
to do this -- I'd have to investigate. Another, probably more realistic
alternative is to add a couple generic hooks (as few as possible) in the
open source to make/closed makefiles which may or may not exist depending
on which distribution you are building. Something like:
-include make/closed/custom.gmk
somewhere in a top-level Makefile which would include custom makefile if it
exists, and silently skip over it if it is not there. It would be up to
the customizer to provide that file and have it include whatever is needed
in order to build the custom code. For example, I could put "ORACLEJDK="
in there perhaps to turn off the Oracle extensions in the Makefile, as well
as adding whatever other logic I need. Oracle's version of
make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and that's it (for
now, once the artifacts are removed from the Makefiles you wouldn't need
ORACLEJDK at all).
We have some of those hooks in JDK makefiles already. In jdk8 we just
had "-include" but in jdk9 we made it a bit more fancy with a macro that
the closed implementor has to provide an implementation for (to give
more freedome on the closed directory layout). It's not uniformly added
everywhere yet but the pattern is established and if an open makefile is
missing "$(eval $(call IncludeCustomExtension, , Main.gmk))", feel free
to add it.
There is also some support for adding extra source directories. See
ADD_SRC macro in spec.gmk.in and JavaCompilation.gmk. This is currently
not used and might need some tweaking, but would be nice to see expanded
upon.
/Erik
My vision of this is that I'd like to get to the point where OpenJDK
makefiles work fine as is, but will automatically pick up new logic and new
code from make/closed and src/closed if those directories exist (and
contain the "hook" files). This gives custom code a nice place on the side
where to live, with fewer worries about having to merge whenever anything
in OpenJDK changes. Of course it wouldn't solve all the problems, but it
would be a very nice start.
On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinh...@oracle.com> wrote:
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 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.
I'm confused.
Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
this help you? In those cases where you want an open Makefile to refer
to code in Twitter's internal src/closed directory aren't you still
going to have to create and maintain your own patches to the open
Makefile?
Just trying to understand the problem here ...
- Mark
