# from Dave Rolsky # on Friday 13 April 2007 10:27 am: >Yeah, I haven't gotten that far, but it's certainly possible in the >design. My idea was that a test set could have a custom config file of >some sort.
Aside: I've just recently started a "Comprehensive Perl Developer Kit", which is primarily a way to automate common developer tasks by using config files containing series of directives. If your 'svn up' support and other aspects were configured as pre_smoke directives in a config, that might make it more easily adaptable than if the code has to be subclassed to do something different. CPDK is still very half-baked, but perhaps you can get some mileage out of the CPDK::Config scheme of inheritable machine/user+project config files. That, and the svn config. (Hmm, maybe half of CPDK::Publish is really CPDK::Action or something more generic.) The config scheme looks like the following link. I think you can extrapolate most of the plan from that. The other thing I'm planning is something to do with traits specified via the config (e.g. "$action => ModuleName::ContainingIt" or "$action => Mod::Name::method_name()") to give the option of extending with code to allow for plugins when there isn't a ready-made action that does what you want. http://scratchcomputing.com/svn/CPDK/trunk/demos/trial01/.perl_developer.yml My dream (or delusion) is that a standardized, overridable config data structure could enable multiple tools to cooperate and reuse the same code/data for related tasks. Building and testing are pretty closely related, especially when you start involving version control, automating tasks across multiple codebases, etc. --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
