[Dirvish] the Options hash, and a testing dilemma (2)

Keith Lofstrom keithl at kl-ic.com
Tue Feb 8 23:52:43 PST 2005


On Tue, Feb 08, 2005 at 05:25:36PM -0800, Keith Lofstrom wrote:
> 
> Those of you who have studied the Dirvish code have encountered the
> infamous $Options hash.   In the instruction flow through the "dirvish"
> routine (assembled by the INSTALL script out of dirvish.pl and
> loadconfig.pl, with the $CONFDIR prepended) it contains some anonymous
> subroutines that are called when the options --config= , --client= ,
> --branch= , and --vault= are called.  If you call these options on
> the command line in a particular order, or multiple times, the
> configuration values accumulate.
> 
> The options are first set by the $CONFDIR.conf or $CONFDIR/master.conf .
> Then the perl module GetOptions is called, which sets more options, and
> possibly loads more config files as indicated above.  Pretty squirrely.
> 
> There is a problem with this - it always assumes there is a valid
> master configuration file - and this is needed before options processing
> begins, so that we know where the banks and vaults are.  But what if
> you want to use a specialized master.conf file for testing during
> installation?  The master.conf file will either be left over from
> a previous install (not to be modified!) or will be part of this
> install, and not customized to the system.
> 
> I suggest adding an additional option, --cleanoptions . 

Instead, let's use the existing --reset option like so:  --reset=default
or maybe --reset=all , though the latter might get confused with
dirvish-runall .  

> When this
> option is encountered, we run an anonymous subroutine that cleans
> out the $Options hash (and any previous options - we restore to
> the original $Options contents.   That can be followed with a
> --config=test.conf option, which can fill in all the options that
> you might normally expect to find in master.conf, except customized
> for testing.
> 
> The interaction of $Option and loadconfig() and $GetOptions is rather
> entangled, and it will be difficult to unentangle or refactor.  In
> the best of all worlds, I would like to see GetOptions processed
> before we read any configuration files at all, but I cannot see how
> to do that without changing the existing runtime behavior.  That would
> be unacceptable.
> 
> Comments?
> 
> Keith
> 
> -- 
> Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
> KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
> Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
> _______________________________________________
> Dirvish mailing list
> Dirvish at dirvish.org
> http://www.dirvish.org/mailman/listinfo/dirvish
> 

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs


More information about the Dirvish mailing list