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.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 > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcgui...@twitter.com
