Improving the management and accessibility of the handling of JDK variants

[Dave Pointon]

Hi all ,

Whilst investigating the building of the IBM variant of the JDK, I very
quickly realized that not all build variant build configurations will be
identical e.g. the IBM variant requires such things as the
removal/addition of files from/to the local repo, variant specific
compiler &/or linker flags etc.

On further reflection, I became convinced that the  handling of any such
build variants should be as flexible/scalable (and thus useful :-) as
possible. Ergo, any implementation should provide significant benefits
by way of a reduction in effort required in order to support further
variants.

Initial code inspections and experiments suggest that the most scalable
means of introducing the ability to build the IBM variant of the JDK,
might be achieved thro' the use of the --with-jdk-variant configure
option, or an extension of it. Moreover, the implementation should take
the form of being able to cater for local draft &/or branch specific,
variants whilst, at the same time, minimising any interference with the
day-to-day pull's and pushes from the parent repo.

At the highest level, my thoughts and indeed experiments, were/are along
the lines of ...
. Adding a configure option, -with-jdk-variant-base-dir, that specifies
a base directory (default - <repo-root>/common/autoconf/jdk-variants) in
which would be located a sub-directory for each variant.
. Adding jdk-variants.m4 to contain variant validation and processing
macros
. Updating jdk-options.m4 to utilise the new option validation macro


That's about as far as I've got ... as yet, so any & all thoughts WRT
this toe-in-the-water, slightly more convoluted, exercise are most
welcome ...

TIA & 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