On Sun, 22 Jul 2001, Michael G Schwern wrote:

>  On Sat, Jul 21, 2001 at 06:42:23PM -0000, perl@[...].org wrote:
>  > Maybe have an option or a prompt that asks if this version is being
>  > installed on the same system Configure is running on, and then it
>  > should see if perl is already installed, and if it is, use Config.pm
>  > for default values whereever they exist in Config.pm.
>  
>  Ya know, that's a great idea!  I have no idea how feasible it is, but
>  its a great idea!

You can try it right now with

	perl -MConfig -e 'print Config::config_sh();' >  config.sh
	sh Configure [whatever options you like]

You'll find that it's not a very good idea.  I just tried it (using
5.6.1's config.sh to try building 5.7.2) and got:

	make test
	[ . . . ]
	Failed 32 test scripts out of 357, 91.04% okay.

The biggest problems I saw right away were:

    1.  The list of extensions to build is wrong since the old
	config.sh didn't know about all the new extensions.

    2.  The version-specific directory names were wrong.
	(As a side effect, the list of previous versions to include
	was also wrong.)

Another way of looking at this is that most users probably want the
defaults for most answers, but do have some site-specific "Policy" choices
that they wish to make.  Perl comes with a Policy_sh.SH file designed for
just such uses.  See

	=head2 Site-wide Policy settings

in the INSTALL file for further details.

The only thing missing is an easier way to carry your Policy.sh file
around between versions.  Currently you have to keep a copy of your old
Policy.sh file around somewhere between perl builds.  That's obviously
less than ideal for those that don't build perl often.

For most Policy.sh uses, you can probably get by with the following right
now:
	perl -MConfig -e 'print Config::config_sh();' >  config.sh
	sh Policy_sh.SH
	rm config.sh
	sh Configure [whatever options you like]

If people truly find that useful, then perhaps it would be worthwhile to
add a sub Policy() {} to Config.pm to simplify this a tad.

The original poster didn't specify which Configure choices needed to be
overridden, but my guess is that if any wants to pursue this further, I
think the Policy.sh angle is probably the best direction to pursue.

-- 
    Andy Dougherty		doughera@[...].edu
    Dept. of Physics
    Lafayette College, Easton PA 18042