module-build-general — General discussion about Module::Build project

Re: [Module::Build] notes on notes

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

On 1/1/2004 11:08 PM, Uri Guttman wrote:

> 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.

Ok, I guess the extended version I just posted is unneccessary also <<:-\

But I still think it usefull addition to M::B to aid testing and automation.

Randy.

Re: [Module::Build] notes on notes

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

>>>>> "DR" == Dave Rolsky <au...@ur...> writes:

  DR> On Thu, 1 Jan 2004, Uri Guttman wrote:
  >> 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.

  DR> It's useful if someone installs Stem 0.10 and later goes to install 0.11.
  DR> That way the previous values are presented as defaults.

hmm. never thought of it that way. this would also only work if the new
install used the same perl (or shared the same perl lib tree) and the
previous one. but i will note it and write it up in the INSTALL
doc. also with the option to just use the defaults, it will make
installing new stem versions faster as well. 

  >> 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.

  DR> notes is not persistent after a "./Build clean", so it's only for "during
  DR> the build/install" data.

so that confirms my not using notes.

  >> 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?

  DR>  $build->add_to_cleanup($path_to_file);

so this will clean it up in the build tree which is good and leave it in
the installed lib dir. i will add it to the sub that makes the config
file as it has the path. i have to check if the default install command
will install a generated .pm file that is not in the manifest.

thanx,

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

Re: [Module::Build] notes on notes

[Dave R. <au...@ur...>]

On Thu, 1 Jan 2004, Uri Guttman wrote:

> 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.

It's useful if someone installs Stem 0.10 and later goes to install 0.11.
That way the previous values are presented as defaults.

> 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.

notes is not persistent after a "./Build clean", so it's only for "during
the build/install" data.

> 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?

 $build->add_to_cleanup($path_to_file);


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

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

Re: [Module::Build] notes on notes

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

On 1/1/2004 4:12 AM, Randy W. Sims wrote:

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

Here is an extended version:

Example:

?? interactive
?? no_clobber
John Doe
jd...@so...
y
?? force Hello, World!
?? # store these so we don't have to look em up again.
?? set ftp = /usr/local/bin/ncftp
?? set cc = /usr/bin/gcc
?? eof


Answer script format:

Each line represent an answer to a fixed sequence of prompts unless the 
line begins with '??' in which case it is a command or flag.

The flags are:

'interactive' => means the answers in the script are to be used as 
defaults for an interactive session instead of as an automated answer 
script.

'no_clobber' => prevents M::B from overwritting the answer file. 
Normally, in interactive mode M::B records the answers to prompts and 
then saves a new answer file so that on the next run the new answers 
will be used as the new defaults.

The commands are:

'default' => use the default specified to the prompt() or y_n() functions.

'alt <value>' => use the default specified to the prompt() or y_n() 
functions if available, other wise use <value>.

'force <value>' => in interactive mode, skip the prompt using <value> as 
the answer.

'set <key> = <value>' => stores (key, value) pairs that can be retrieved 
with the retrieve_answer() api. see below.

'#' => a comment. ignored.

The api:

store_answer(<key>, <value>) => stores the (key, value) pair to be 
written to the answer file. Can be used to store info that may otherwise 
be time consuming to gather, like a cache.

retrieve_answer(<key>) => retrieves the value stored in <key> from the 
answer file.


Regards,
Randy.

Re: [Module::Build] Beta released

[Graham B. <gb...@po...>]

On 26 Dec 2003, at 23:22, Ken Williams wrote:
>> PS: Something I've been curious about for a while, but never got 
>> around to asking: What's up with the 'INSTALL.txt' file rather than 
>> the usuall 'INSTALL' file in the M::B dist? Just curious.
>
> I did that for the sake of case-insensitive filesystems & the 'make' 
> passthrough layer.  I guess search.cpan.org doesn't pick it up with 
> .txt, though. =/
>
> If Graham's interested in adding that as a "special" file to search, 
> I'll keep it the way it is - otherwise I guess I'll move it to 
> 'INSTALL', since I think the case problem is fixed now.

I think for the sake of consistency it should be called INSTALL. If 
there is a problem in doing that, then I would consider adding the .txt 
suffix to search

Graham.

Re: [Module::Build] notes on notes

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

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

> 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? the
> 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 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. :)

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

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

Regards,
Randy.

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

Re: [Module::Build] notes on notes

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

>>>>> "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? the
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 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. :)

  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

-- 
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

Re: [Module::Build] notes on notes

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

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)?

I think Ken did this so that different actions can handle their own 
arguments. For example, the 'ppd' action takes an optional 'codebase' 
argument from the commandline. It opens the door so that action authors 
can similarly handle their own args, keeping arg handling near the code 
that uses it.

> the second question is how do we punish that scalawag dave for using an
> undocumented feature and leading me down that evil path?

I leave dave's punishment to your imagination (sorry dave), but I 
suspect you opened yourself to similar punishment when you *chose* to 
act without RTFM. ;-)

> 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.

I think the primary value in doing the interactive stuff up front is 
that if you have to debug other parts of the build process, you will not 
have to keep answering the prompts. Additionally, it might be beneficial 
later if, say the interactive functions were instrumented to allow for 
scripts to supply answers to the interactive queries, so that debugging 
multiple configs could be automated. I imagine if everyone put the 
interactive stuff up front, this would be easier to implement.

> finally, in looking at y_n:
> 
>   my $answer;
>   while (1) {
>     $answer = $self->prompt(@_);
>     return 1 if $answer =~ /^y/i;
>     return 0 if $answer =~ /^n/i;
>     print "Please answer 'y' or 'n'.\n";
>   }
> 
> any reason why the assignment to $answer isn't my'ed instead of doing it
> before the loop?
> 
> inquiring minds want to know,
> 
> uri
> 

I'm guessing evolution, but Ken may have ulterior motives :-)

Regards,
Randy.

[Module::Build] notes on notes

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

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)?

the second question is how do we punish that scalawag dave for using an
undocumented feature and leading me down that evil path?

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.

finally, in looking at y_n:

  my $answer;
  while (1) {
    $answer = $self->prompt(@_);
    return 1 if $answer =~ /^y/i;
    return 0 if $answer =~ /^n/i;
    print "Please answer 'y' or 'n'.\n";
  }

any reason why the assignment to $answer isn't my'ed instead of doing it
before the loop?

inquiring minds want to know,

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

Re: [Module::Build] [PATCH] Write minimal META.yml unless -e YAML.pm

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

On 12/30/2003 1:37 AM, Randy W. Sims wrote:
> I'm not sure this patch is clean or complete (I'm up past my bedtime), 
> but I thought I'd post for comments. This patch:
> 

Looking at this again, I see I missed the return in 
_write_minimal_metadata() which should be something like

return ++$self->{wrote_metadata};

That function could be named something better, maybe 
_write_degenerate_metadata().

Maybe a better patch would refactor all the dist stuff into a module, 
say M::B::Distribution, that would be responsible for collecting and 
deducing info about the dist, producing tarballs, etc. And the metadata 
stuff could be collected in M::B::Distribution::Metadata which would 
handle gathering metadata for generation of META.yml and PPD files, and 
would later likely become a proxy or interface to the metadata module 
you mentioned.

I'll hold on that for now; I've been procrastinating on another little 
problem I said I'd look into.

Regards,
Randy.

Re: [Module::Build] args attribute in new

[Ken W. <ke...@ma...>]

On Tuesday, December 30, 2003, at 12:22  AM, Uri Guttman wrote:

>>>>>> "DR" == Dave Rolsky <au...@ur...> writes:
>
>   DR> On Tue, 30 Dec 2003, Uri Guttman wrote:
>   DR> Ken, should this all be done via the notes() stuff?
>>>
>>> which is what?
>
>   DR> Documented (*cough*).
>
> well, how would i know?

How would you know something is documented?  Oh, I don't know ... BY 
LOOKING AT THE DOCS, MAYBE?

In any case, yeah, when you just want to pass info from one place to 
another in your build process, notes() is the way to do it.

  -Ken

Re: [Module::Build] args attribute in new

[Jim C. <jc...@di...>]

Uri Guttman wrote:

>>>>>>"DR" == Dave Rolsky <au...@ur...> writes:
>>>>>>            
>>>>>>
>
>  DR> On Tue, 30 Dec 2003, Uri Guttman wrote:
>  DR> Ken, should this all be done via the notes() stuff?
>  >> 
>  >> which is what?
>
>  DR> Documented (*cough*).
>
>well, how would i know? the args in new isn't documented. you can't
>expect me to rtfm all the time!
>
>uri
>
>  
>
Scorekeeper, please note that Uri took his mulligan, and doesnt get a 
new one til next year ;-)

[Module::Build] [PATCH] Write minimal META.yml unless -e YAML.pm

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

I'm not sure this patch is clean or complete (I'm up past my bedtime), 
but I thought I'd post for comments. This patch:

  - Adapts the 'author' parameter to accept either a string or anonymous 
array of strings for multiple authors.

  - Initialize dist_author and dist_abstract like dist_(name|version).

  - Adds authored_by field to F<META.yml> and adapts PPMMaker.pm to 
write multiple AUTHOR tags if appropriate in PPD files (which is allowed 
by the PPD spec).

  - Adds abstract field to the F<META.yml> file.

  - If YAML.pm is not installed, print a warning and generate a minimal 
META.yml file.


Regards,
Randy.

Re: [Module::Build] args attribute in new

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

>>>>> "DR" == Dave Rolsky <au...@ur...> writes:

  DR> On Tue, 30 Dec 2003, Uri Guttman wrote:
  DR> Ken, should this all be done via the notes() stuff?
  >> 
  >> which is what?

  DR> Documented (*cough*).

well, how would i know? the args in new isn't documented. you can't
expect me to rtfm all the time!

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

Re: [Module::Build] args attribute in new

[Dave R. <au...@ur...>]

On Tue, 30 Dec 2003, Uri Guttman wrote:

>   DR> Ken, should this all be done via the notes() stuff?
>
> which is what?

Documented (*cough*).


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module::Build] args attribute in new

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

>>>>> "DR" == Dave Rolsky <au...@ur...> writes:

  DR> On Tue, 30 Dec 2003, Uri Guttman wrote:
  >> this behavior. so is it a doc bug or an undocumented feature? now dave
  >> is the one that did this originally and i want to keep the use of this
  >> ghost feature. will it stay in the code? if so, it should be
  >> documented. i know, patches welcome. but i am not even sure it is a real
  >> feature. and it would take all of two lines to document it. and i would
  >> rename (or support both names like requires/prereq) it to default_args
  >> as that is what it really is. the hash contains the default values for
  >> the 'args' hash but they can be overridden by command line args.

  DR> Heh, I just noticed I do this in Alzabo's Build.PL as well.

so you are guilty of multiple counts of using undocumented
features. what is the normal punishement for such crimes against
development?

  DR> Ken, should this all be done via the notes() stuff?

which is what?

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

Re: [Module::Build] args attribute in new

[Dave R. <au...@ur...>]

On Tue, 30 Dec 2003, Uri Guttman wrote:

> this behavior. so is it a doc bug or an undocumented feature? now dave
> is the one that did this originally and i want to keep the use of this
> ghost feature. will it stay in the code? if so, it should be
> documented. i know, patches welcome. but i am not even sure it is a real
> feature. and it would take all of two lines to document it. and i would
> rename (or support both names like requires/prereq) it to default_args
> as that is what it really is. the hash contains the default values for
> the 'args' hash but they can be overridden by command line args.

Heh, I just noticed I do this in Alzabo's Build.PL as well.

Ken, should this all be done via the notes() stuff?


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

[Module::Build] args attribute in new

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

i have been in the midst of converting the install for stem to
module::build. dave rolsky first did some work on this and i am finally
going to finish it. i have some nice stuff working and some of you might
be interested in it (a file grep with file patterns matching manifest
lines, tests run in the order in manifest, a manifest grep, user query
subs, etc.) and maybe some of them could be integrated into build.

my question here is about the args attribute in the new constructor. the
docs state that $self->{'args'} will have the parsed out command line
arguments. but dave also passed in a hash ref to the 'args' attribute
in the call to new. after checking the source i see that that hash will
be used to set args before the command line stuff is parsed so it is in
effect a set of default args. but i can't find any docs that describe
this behavior. so is it a doc bug or an undocumented feature? now dave
is the one that did this originally and i want to keep the use of this
ghost feature. will it stay in the code? if so, it should be
documented. i know, patches welcome. but i am not even sure it is a real
feature. and it would take all of two lines to document it. and i would
rename (or support both names like requires/prereq) it to default_args
as that is what it really is. the hash contains the default values for
the 'args' hash but they can be overridden by command line args.

Module::Build: 0.21

thanx,

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

Re: [Module::Build] Beta released

[Ken W. <ke...@ma...>]

On Thursday, December 25, 2003, at 09:20  PM, Randy W. Sims wrote:
>
> All tests successful on MSWin32 & cygwin.

Excellent.

> This was in Ilya Zakharevich's original patch; I was just pointing out 
> that it didn't make it into CVS. Attribution should go to Ilya.

Okay, done.

> PS: Something I've been curious about for a while, but never got 
> around to asking: What's up with the 'INSTALL.txt' file rather than 
> the usuall 'INSTALL' file in the M::B dist? Just curious.

I did that for the sake of case-insensitive filesystems & the 'make' 
passthrough layer.  I guess search.cpan.org doesn't pick it up with 
.txt, though. =/

If Graham's interested in adding that as a "special" file to search, 
I'll keep it the way it is - otherwise I guess I'll move it to 
'INSTALL', since I think the case problem is fixed now.

  -Ken

Re: [Module::Build] Beta released

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

On 12/24/2003 1:05 AM, Ken Williams wrote:

> Hey,
> 
> I'm really supposed to be wrapping presents and so on, but I just 
> couldn't help releasing another beta of Module::Build.  Merry Christmas! =)
> 
> Your secret solstice santa,
> 
>  -Ken
> 

All tests successful on MSWin32 & cygwin.

> 
> 0.21_02  Tue Dec 23 17:05:11 CST 2003
> 
[...]
>  - Changed the manpage separator on OS/2 to '.'. [Randy Sims]

This was in Ilya Zakharevich's original patch; I was just pointing out 
that it didn't make it into CVS. Attribution should go to Ilya.

Merry Christmas,
Randy.

PS: Something I've been curious about for a while, but never got around 
to asking: What's up with the 'INSTALL.txt' file rather than the usuall 
'INSTALL' file in the M::B dist? Just curious.

[Module::Build] Beta released

[Ken W. <ke...@ma...>]

Hey,

I'm really supposed to be wrapping presents and so on, but I just 
couldn't help releasing another beta of Module::Build.  Merry 
Christmas! =)

Your secret solstice santa,

  -Ken


0.21_02  Tue Dec 23 17:05:11 CST 2003

  - During testing, if YAML.pm isn't installed, then we won't try
    making a tarball with Archive::Tar either, since this would invoke
    YAML to create the META.yml file.

  - Fixed a problem with chmod() being called incorrectly on MacOS
    (i.e. MacPerl, not Mac OS X).  [Spotted by Paul Sanford Toney]

  - Fixed a problem with the --config flag not being treated properly
    (essentially ignored) on the command line for 'perl Build.PL' or
    'Build <action>'. [Spotted by Jakub Bogusz]

  - Added a new config() method to get at the Build object's notion of
    the %Config hash.

  - Test::Harness is starting to contend for the Most Crotchety Module
    Award.  Work around a few of its nits when setting harness
    switches. [Spotted by Diab Jerius]

  - Changed the manpage separator on OS/2 to '.'. [Randy Sims]

  - Now the Build script will die() if we're run from the wrong
    directory, rather than trying to chdir() to the right directory and
    do its work there.  See
    https://rt.cpan.org/Ticket/Display.html?id=4039 . [Chris Dolan]

  - On OS/2, disable C compilation, since apparently it isn't working
    there. [Reported by Ilya Zakharevich]

  - Inserted a comment into auto-generated Makefile.PLs saying it was
    auto-generated. [Randy Sims]

  - Fixed some annoying behavior in generated passthrough Makefile.PLs
    when the user chose not to install Module::Build, or if
    installation failed. [Reported by Ilya Zakharevich and Richard
    Clamp]

  - Moved the documentation for 'codebase' to the section where it's
    relevant. [Randy Sims, Glenn Linderman]

  - Made the 'name', 'abstract', 'author', and 'version' properties
    required when building a PPD file. [Spotted by Randy Sims, Dave
    Rolsky, & Glenn Linderman]

Re: [Module::Build] test_recommends ??

[Jim C. <jc...@di...>]

Randy W. Sims wrote:

> On 12/22/2003 11:25 AM, Jim Cromie wrote:
>
>>
>> MB already has these:
>>
>> requires
>> recommends
>> test_requires
>
>
> You mean 'build_requires'? 


oops - yes.

>> any thoughts ?
>
>
> I'm not sure if this is justifiable. Tests can check for the presence 
> of a module and emit a SKIPPED message if not found. I just don't 
> think most people will install extra modules just to run tests unless 
> there is a compelling problem. Note: I'm not saying whether this is 
> right or wrong; just that it is likely the case. 


Heh, I would - but then my disk is always > 90% full.  
Certainly recommends could be used for both kinds of recommendations,
unless theres subtleties that Ive not yet encountered.

>
>
> Ken has already commented that thier are already a large number of 
> parameters defined for M::B. I imagine it will take a good argument to 
> convince him to accept more.


1. cuz build_recommends is just an alias for recommends ?
2. to foreclose dumb emails like this :-O

hey - I didnt say theyre 'good' args..

>
> Regards,
> Randy.
>
>
thx.

Re: [Module::Build] test_recommends ??

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

On 12/22/2003 11:25 AM, Jim Cromie wrote:

> 
> MB already has these:
> 
> requires
> recommends
> test_requires

You mean 'build_requires'?

> test_recommends  seems a natural for things like Test::Warn, 
> Test::Benchmark, etc..
> 
> I imagine there are CPAN, CPANPLUS, issues, and maybe indexing ones too.
> 
> any thoughts ?

I'm not sure if this is justifiable. Tests can check for the presence of 
a module and emit a SKIPPED message if not found. I just don't think 
most people will install extra modules just to run tests unless there is 
a compelling problem. Note: I'm not saying whether this is right or 
wrong; just that it is likely the case.

Ken has already commented that thier are already a large number of 
parameters defined for M::B. I imagine it will take a good argument to 
convince him to accept more.

Regards,
Randy.