Improving the management and accessibility of the handling of JDK variants

[Dave Pointon]

Hi David ,

On Mon, 2013-11-25 at 12:07 +1000, David Holmes wrote:

> Hi Dave,
> 
> This all seems very complex and I'm unclear exactly what it would do or 
> why it would be needed (at this level of flexibility). Our own use of 
> the variant mechanism doesn't require this level of ability. Note your 
> subdirectory of variants needs to allow for some variants being defined 
> elsewhere.
> 
> What exactly is your "variant"? Does the variant itself belong in the 
> OpenJDK, or just the infrastructure that allows that variant to be built?
> 
> David H.
> -------
> 

<snip>

I believe that this piece of work belongs in the infrastructure in as
much as I'm merely ( :-) ) attempting to adapt the IBM JDK build and
all the accompanying niceties, more into line with the OpenJDK
approach such that the additional effort necessary to run the IBM
variant of the OpenJDK build is minimised, if not removed entirely; To
which end there are currently 2 difficulties/opportunities that
I (think I am) addressing with the output variant handling, to whit ...

. Running a build using the IBM J9 JVM as the boot JDK
. Removal of files unwanted in/by the IBM build - because they are
  provided by the IBM boot JVM and cause problems

My experiments thus far are intended to be as flexible as possible
in order to provide future usability.

As to the alternate location, I only originally considered allowing the
specification of an alternate build variant root directory, but my current
implementation could be extended to allow alternate root directory
specification on a per-build-variant basis.


Rgds ,

-- 
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count
the cost and before we we judge rightly of our strength to go thro'
with it - Robinson Crusoe