Re: [Module::Build] notes on notes

[Uri G. <ur...@st...>]

>>>>> "RWS" == Randy W Sims <Ra...@Th...> writes:


  RWS> I don't know if I'm completely understanding what your talking about,
  RWS> but I went ahead and wrote some code. =) The attached patch for M::B
  RWS> provides support for answer scripts. It was extremely easy to
  RWS> implement thanks to M::B's great architecture. Currently, it will
  RWS> create an answer script from the answers to prompt() and y_n()
  RWS> queries, store the answers in 'Build.ans' (configurable). The next run
  RWS> will use those answers as defaults. You can also edit the answer file,
  RWS> taking out the '?? interactive' line (lines begin with '??' for flags
  RWS> or '?? #' for comments), so that the prompts are answered
  RWS> non-interactively which means you can easily automate testing of
  RWS> multiple configs.

ok, i see the communication problem here. let me take a step back.

dave wrote a first pass for the stem install and took the config params
answers and wrote them out to the Stem::InstallConfig module. i don't
have any reason currently to use those config values in any stem
application but i am sure someone will one day so that is fine with
me. but dave also read in that config file in Build.PL to use as a
persistant set of default config values. also since he used the 'args'
feature, command line args could override the default values. now dave's
motives (as well and his morals and dna) for this are suspect. i don't
see any need for persistant config params in this install as stem will
probably not be reinstalled (often) from the same tarball. it doesn't
have build variations like some other modules do.

so the story is that is has persistant config params but it doesn't need
them and i will keep them anyway since it seems kinda cool. :)

now, there are several ways to to this and notes is one of them. but
since we already write out the config params to that stem module,
loading that is very easy and i will prolly stay with it.

side question: since that config module is generated at build/install
time it should be deleted with realclean. but it won't be seen that way
by the default realclean action. do i need to write my own realclean
action, delete that config file and then call SUPER::ACTION_real_clean?
it isn't hard but is there a standard way to add things to realclean?

  RWS> The obvious extension to this would be to provide for storing
  RWS> answers to non-interactive queries. For example, if you write a
  RWS> Build.PL that does a lot of probing, you might want to store the
  RWS> results of the first probe in order to save time on subsequent
  RWS> runs. But I'll let you play with this and see what Ken thinks
  RWS> before I do anymore.

well, as i said i didn't need this for non-interactive queries. but i
will add a command line arg like 'no_questions' or 'use_defaults' which
will force build to use the default values and not prompt for anything. 

my current code does this as a wrapper to prompt:

sub query_valuex {

	my( $self, $query, $key ) = @_ ;

	my $default = $build->{args}{$key} ;
	$default = $defaults{ $key } unless defined $default ;

	my $val = $self->prompt( $query, $default ) ;

#	$self->notes( $key, $val ) ;
	$defaults{ $key } = $val ;

}

so you can see that it keeps the result from the query and it will store
that in the stem config module (maybe it should store that in the object
and not in a file lexical). 

side question: notes has a simple interface but i am not sure if it is
easy to use in this case. i could store each param in its own key in
notes. but what if a value in notes needs to be a hash ref? then you
have to access it, update it and set the ref back into notes. also there
is no way to set all the notes in one call (when you want to build up
your own notes hash and just assign it) as there is a way to get the
entire ref in one call. this may be why i skip the notes interface as i
am not sure what i will want to store/access there. i have the
persistance via the config module and can mung the config/defaults hash
directly.

<snip of code>

so i won't be testing this as i don't really need it for this right
now. but i can see users wanting it for multiple installations and
similar situations. also i sometimes wish i could crank out the code
like i used to. :)

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org