Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 12/31/2003 4:42 AM, Uri Guttman wrote:

>>>>>>"RWS" == Randy W Sims <Ra...@Th...> writes:
> 
> 
>   RWS> On 12/31/2003 2:31 AM, Uri Guttman wrote:
>   >> ok, i rtfm'ed and see what the notes method does. so my first question
>   >> is why does new even handle a passed in args attribute (especially as it
>   >> is not documented nor meant to be used)?
> 
>   RWS> I think Ken did this so that different actions can handle their own
>   RWS> arguments. For example, the 'ppd' action takes an optional 'codebase'
>   RWS> argument from the commandline. It opens the door so that action
>   RWS> authors can similarly handle their own args, keeping arg handling near
>   RWS> the code that uses it.
> 
> i think you may have misunderstood my question. the new constructor
> handles an 'args' attribute passed into it but that is not documented
> and is what dave used to set defaults. look at this code:
> 
> sub new {
>   my $self = shift()->_construct(@_);
> 
>   $self->cull_args(@ARGV);
> 
> 
> sub _construct {
>   my ($package, %input) = @_;
> 
>   my $args   = delete $input{args}   || {};
> 
> <snip>
> 
>   my $self = bless {
> 		    args => {%$args},
> 
> 
> anything passed with 'args' in new is stored in the object and then
> command line args can override those values. so the 'args' passed to new
> are effectively defaults for the command line. this is actually more
> like what i want than just notes (though i could get the command line
> args before i set notes and use those).
> 
> also that args => {%$args} does a useless extra copy AFAICT. it doesn't
> check that args is actually a hash ref either so if you pass something
> else in (still undocumented), it will die.
>   >> on a related note (sic), i have been looking at prompt and y_n. i had
>   >> written very similar subs in my soon to be deleted stem install script
>   >> and i had transplanted them to my build stuff. so i will replace them
>   >> with build's method (almost a drop in replacement). my prompts can ber
>   >> very long (using here docs of course) since i sometime describe the
>   >> queries in detail. now, i noticed that the example does the config
>   >> queries in Build.PL and stores the results in notes in the build
>   >> object. i was doing the queries in the install action. is there a reason
>   >> to do it one way or another? the only time i seem to need those values
>   >> is in the install action. also dave wrote something that writes out
>   >> those values into a stem module. if i need them in test script or
>   >> whatever, i could just use that module.
> 
>   RWS> I think the primary value in doing the interactive stuff up front is
>   RWS> that if you have to debug other parts of the build process, you will
>   RWS> not have to keep answering the prompts. Additionally, it might be
>   RWS> beneficial later if, say the interactive functions were instrumented
>   RWS> to allow for scripts to supply answers to the interactive queries, so
>   RWS> that debugging multiple configs could be automated. I imagine if
>   RWS> everyone put the interactive stuff up front, this would be easier to
>   RWS> implement.
> 
> good answer about the up front stuff. i have been hitting a lot of
> returns to get to the parts i am testing. the interactive stuff could be
> done for the install phase just as well as the Build.PL phase IMO.
> so i will move the question stuff to Build.PL and use the build prompt
> and y_n instead of my own. it will actually clean up the code some as it
> splits the query stuff from the install and action stuff.
> 
> another thing i mentioned that dave did was to write out the args to a
> stem config file. he also read it back in in Build.PL and passed it to
> the default args hash. so it was sorta like a persistant set of config
> args if you rebuilt Build. would the notes stuff be persistant at that
> level too? or are notes only persistant after Build.PL is run?

I believe notes are persisted when Build.PL is first run and persist 
until the 'realclean' action is invoked.

> feature dave seemed to want was to use the past install config values as
> the new defaults for the query phase. how would this be done with notes?

I don't think it can be done with notes. I think this is pretty much the 
same thing I was talking about before when I refered to being able to 
script the interactive stuff by supplying an answer file. It would work 
sort of like configure. When you answer interactive queries, the answers 
are stored in an answer file for later reuse to create the exact same 
config. Or you write (or generate) an answer file to automate the config 
process. This feature is not currently explicitly provided by M::B, 
although I think it a very desirable one. Is this what you are talking 
about? If so, it would be best to add this feature to M::B than to try 
and work around M::B to get the results you want or to reproduce the 
functionality in multiple distributions.

> i think they are written to the _build dir stuff but are they read in
> when Build.PL is run?  and if so, can i get at them before i do the
> queries? i will experiment and study the code to see what i can do but
> if you can answer it now, it will save me from having to do more
> dispicable rtfming. :)

As above, notes are created in the _build dir at the time Build.PL is 
run and are thus only available afterwards. I.e. they are available when 
actions are invoked.

>   RWS> I'm guessing evolution, but Ken may have ulterior motives :-)
> 
> i just do code review whenever i look at code. like i spotted the bogus
> args copy above. :)
> 
> thanx,
> 
> uri