JDK-8025705

[Keith McGuigan]

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).

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.reinhold at oracle.com> wrote:

> 2014/4/22 21:23 -0700, kmcguigan at 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
>



-- 

[image: twitter-icon-large.png]

Keith McGuigan

@kamggg

kmcguigan at twitter.com