On Thu, Apr 17, 2014 at 12:52 AM, David Holmes <david.hol...@oracle.com>wrote:
> Hi Keith, > > 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. > Though parameterizing the custom src dir would be nice, it's disjoint from the problem that I'm trying to solve (unless I'm misunderstanding you). The specific existence tests would do it, but that seems a rather slapdash solution. > 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. > Perfect is the enemy of good. A suboptimal solution here would still provide immediate benefits to third-party distributions. If there's some way we can take a step in this direction in the short-term, that would be great, especially since it make take a while to fix this permanently. > I see 68 uses of src/closed across 14 files in the JDK repo. That seems > tractable. > Oh sure, it's tractable to make these changes -- what I was pointing out is that as of now (and until this is fixed), a non-OpenJDK, non-Oracle distribution needs to make private changes to work around this, and maintain those changes going forward, which is at the very least, unsavory. > I think there are three things to be done here: > > 1. Replace all uses of src/closed with CUSTOM_SRC_DIR (similar to > CUSTOM_MAKE_DIR) which in turn is set via configure > 2. Guard all uses of CUSTOM_SRC_DIR in open makefiles with an existence > check > An existence check for the particular file that is being used? > 3. Move all uses of CUSTOM_SRC_DIR to our closed makefiles > > Steps 1 and 2 can happen now. Step 3 is long term goal. > > --- > > The other problem I see with the OPENJDK, ORACLE_JDK, OTHER_JDK approach > is that you actually have to deal with the permutations. Something > currently flagged for OPENJDK really means !ORACLE_JDK - or does it? It > actually depends on what sources a given licensee has. Even for your custom > build you might want some OPENJDK items and not others. I'm not sure there > is a general solution, but using OPENJDK in combination with CUSTOM_SRC_DIR > is, I think, more flexible than trying to define discrete variables that > represent build "targets". > >> >> I guess I still don't see what benefit using CUSTOM_SRC_DIR does other than move the literal "src/closed" (and "make/closed") out of the makefiles and into configure. Wouldn't the existence of custom code still negate OPENJDK? Maybe I misunderstand what OPENJDK means -- I've been thinking of it as meaning that the build is a pure open build with no extra custom code. -- - Keith
