Improving the management and accessibility of the handling of JDK variants

[David Holmes]

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.
-------

On 23/11/2013 12:16 AM, Dave Pointon wrote:
> Hi Magnus et al ,
>
> On Thu, 2013-11-21 at 16:30 +0000, Dave Pointon wrote:
> <snip>
>> In the process of attempting to describe the changes I'm playing with,
>> I've realized that I've made a coupla wrong assumptions and completely
>> inflexible and thus inappropriate, design decisions. I'll post further
>> once I believe I have a more generally applicable/useful model to
>> impart ...
>>
>> Rgds,
>
> ... further to the above, I have a more general question which is: what,
> if anything, is the general view on dynamically generated and included
> autoconf m4 scripts - by way of explanation ... I have, thus far, been
> toying with adding a new general variant handling/management
> script (jdk-variants.m4) which sinclude's a variant specific handling/
> management script (jdk-variants-list.m4) as generated by an extended
> checked-in configure script - currently generated in common/autoconf,
> but intended for the output directory.
>
> Each allowed/accepted variant is defined/declared as a sub-directory of
> an optional configurable root directory (by default, this is posited as
> common/autoconf/jdk-variants).
>
> If the root directory doesn't exist or is empty, then a warning will be
> generated and the default build variant will be as now i.e. normal.
> Otherwise, i.e. if the root directory is non-empty, then each
> sub-directory defines the name of an accepted/allowed build variant.
>
> Each build variant directory may contain zero, or more, of the
> following ...
> . Executable pre-configure script(s) (preconf*) - script(s) to be
>    run, in sorted order, before the generated-configure.sh script is
>    run.
> . build specific autoconf script(s) - which are included into the
>    autoconf run by the dynamically generated script.
> . Executable post-configure script(s) (postconf*) - script(s) to be
>    run, in sorted order, after the generated-configure.sh script has
>    been run.
>
>
> I'm sure that there'll be comments, which I welcome and
> indeed, anticipate :-)
>
> 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
>