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
