kmcguigan at twitter.com
Thu Apr 17 14:06:12 UTC 2014
On Thu, Apr 17, 2014 at 12:52 AM, David Holmes <david.holmes at 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
> 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
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
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.
More information about the build-dev